Powering up
Futurise Solutions

Home

About

Portfolio

Pricing

Blog

Contact

Europe

Software development for European businesses

Engaging a supplier outside the EEA is a data-protection decision before it is a procurement one. We publish the transfer mechanism we rely on, where your data will physically live, and which EU AI Act obligations reach what you are building — before you ask for any of it.

Send us your scope

Data protection

What it takes to engage a supplier outside the EEA

Five things that are true regardless of which supplier you choose. Every instrument named here is public record and dated, so you can check it rather than take our word for it.

GDPR applies to us because of where your users are, not where we are

Regulation (EU) 2016/679 has applied since 25 May 2018, and Article 3 extends it to processing the personal data of people in the Union regardless of where the processor sits. Being outside the EEA does not place a supplier outside the regulation; it changes which mechanism makes the transfer lawful. We work on that basis from the first call rather than discovering it at contract stage.

Transfers out of the EEA run on Standard Contractual Clauses

India has no European Commission adequacy decision, so a transfer to an Indian delivery team relies on Article 46 safeguards — in practice the 2021 Standard Contractual Clauses, together with the transfer impact assessment the CJEU required in Schrems II (Case C-311/18, 16 July 2020). This is the specific mechanism, named, before you ask for it. A supplier who cannot tell you which Article 46 route they rely on has not thought about it.

Data residency is an architectural decision, not a hosting preference

Keeping personal data physically inside the EEA is usually the cleanest answer, and it is decided in week one or retrofitted expensively later. In practice it means selecting EU regions at the infrastructure layer, checking that every managed service in the stack — database, queue, object store, logging, error tracking, analytics — offers an EU region, and knowing which of your third-party processors quietly do not.

The EU AI Act now has dates attached

Regulation (EU) 2024/1689 entered into force on 1 August 2024. Its prohibitions on unacceptable-risk practices have applied since 2 February 2025, and obligations for general-purpose AI models since 2 August 2025, with the bulk of high-risk obligations following on 2 August 2026. For anyone commissioning an AI feature aimed at European users, the practical question is no longer whether the Act applies but which risk tier the system falls into — and that determination changes the build.

A processor's obligations are written into the contract, not assumed

Article 28 requires a written processing agreement covering subject matter, duration, purpose, categories of data, sub-processor authorisation and deletion at the end of the engagement. We expect to sign yours rather than offer our own as a formality, and we expect to be named as processor with our sub-processors disclosed. Breach notification under Article 33 runs to 72 hours, which is a build requirement as much as a legal one: it means logging and alerting have to make detection possible inside that window.

Straight answers

What we claim, and what we do not

We hold no European entity and make no claim of local presence. Stating that plainly is cheaper for both of us than discovering it during your vendor review.

What we do not claim

  • We hold no European entity, no European office and no European staff. Futurise Solutions is registered in Wellington, New Zealand, and our delivery team is in Udaipur, India. That is a corporate fact you can check, and it is stated before you ask.

  • The engagements named on our portfolio are in the UAE, the United States and India. Not every engagement is public — client confidentiality decides what we may attribute, and we do not publish work we have not been cleared to name. So read the portfolio as what we can show you, not as the whole record.

  • We are not the right supplier for a contract that requires an EU-established legal entity, or for public-sector procurement with an EEA-establishment condition. Where that is the requirement we will say so on the first call rather than after it.

What is genuinely true

  • The transfer mechanism, the sub-processor list and the data-residency design are settled in writing before the build starts, not requested from us during your vendor review.

  • We already build to a comparable regime. New Zealand's Privacy Act 2020 and the UAE's PDPL both impose cross-border transfer duties, and the engineering habits they demand — deciding where data lives, what is logged and for how long, whether a person's record can be exported or erased without a one-off script — are the same habits GDPR needs.

  • You contract with a New Zealand company. New Zealand holds a European Commission adequacy decision, in force since 2013 and retained following the Commission's 2024 review, which makes the contracting entity itself a jurisdiction the Commission has already assessed.

Where a European supplier is the better answer

  • Work that needs people in the room on a recurring basis, or a delivery team inside your own timezone for daily ceremonies.

  • Contracts requiring an EU-established supplier for regulatory, procurement or insurance reasons.

  • Projects whose main risk is organisational rather than technical, where progress depends on someone chasing a stakeholder in person.

How we work

Decided in week one, not retrofitted

Where data lives, what is logged, and which risk tier an AI feature falls into — settled before the architecture is set.

Where this matters most

Builds where European rules change the architecture

Four kinds of project where the regulatory position is a design input rather than a compliance form filled in at the end.

AI features aimed at European users

The design question is which EU AI Act risk tier a system falls into, and it changes the build. Transparency duties for systems people interact with, logging and human-oversight requirements where a use case is high-risk, and — for anything touching biometric categorisation or social scoring — a prohibition rather than a control. Deciding this before the architecture is set is far cheaper than discovering it during a compliance review.

SaaS platforms processing personal data

Multi-tenant products carry the harder version of every GDPR obligation: erasure that has to work per-tenant without breaking referential integrity, export in a portable format under Article 20, retention that differs by customer contract, and audit logging that can evidence lawful basis. These are schema decisions, which is why they belong in week one.

E-commerce and payments

Strong Customer Authentication under PSD2 has been enforced across the EEA since 31 December 2020 and in the UK since 14 March 2022, so European checkout flows carry authentication requirements many non-European builds simply omit. Add EU VAT and OSS reporting at the boundary, and multi-currency handling that does not round incorrectly.

Internal tooling and integrations

The common European build is not greenfield — it is software that has to sit alongside an existing ERP, ledger or CRM rather than replace it, and the integration is usually where the project is won or lost. Sub-processor disclosure matters here too: every SaaS the integration touches becomes part of your processing record.

Engagement

How a European engagement actually runs

Timezone stated as arithmetic rather than as a promise, because the arithmetic is something you can check.

1

A working overlap that is real, not nominal

Indian Standard Time runs 4.5 hours ahead of Central European Time in winter and 3.5 ahead during CEST. A 09:00 start in Udaipur is 04:30 in Berlin, and 17:30 in Udaipur is 13:00 in Berlin — so the European morning and the Indian afternoon overlap by roughly half a working day, every day, without anyone keeping unusual hours. For the UK the overlap is an hour wider.

2

Scoping calls in your working day

Booked in European business hours. The output is a written understanding of scope, not a sales pitch, and we sign your NDA before reviewing anything confidential.

3

Fixed scope, quoted in euros or pounds

You are quoted and invoiced in your own currency, so the figure you approve is the figure that reaches your accounts. Scope is fixed before work starts: if our estimate is wrong, absorbing it is our problem rather than a variation to bill.

4

A named engineer, not an account manager

Questions during delivery go to the person writing the code. Every enquiry gets an answer inside one business day.

What we build

Six disciplines, one team

Web Development

App Development

UI/UX Design

Blockchain Development

AI & ML Solutions

Digital Marketing

Other markets

New ZealandUnited StatesCanadaAustraliaUnited Arab EmiratesPortfolioHow we price

Europe FAQ

Questions from European buyers.

What European enquirers ask before a first call — including the one whose honest answer sends them to a different supplier.

Yes. GDPR applies based on whose personal data is processed, not where the supplier sits, so the question is which safeguard makes the transfer lawful rather than whether the arrangement is permitted. New Zealand holds a European Commission adequacy decision, in force since 2013 and retained after the Commission's 2024 review, so transfers to the New Zealand contracting entity rest on that. Because our delivery team is in India, which has no adequacy decision, the onward transfer relies on the 2021 Standard Contractual Clauses together with a transfer impact assessment. Both mechanisms are documented before a build starts.

Building for European users?

Let's scope it properly

Send us the scope, or book a call in your working hours. We sign your NDA before reviewing anything confidential, and if you need an EU-established supplier we will tell you on the first call.

business@futurisesolutions.com