Where your data actually lives
In the United States.
That is the whole answer, and it is worth stating before anything else because it is the constraint most likely to end the conversation. Anyone selling you engineering work who is vague about this is either not thinking about it or hoping you will not ask.
The systems we build for you run on infrastructure we operate, and the sub-processors behind this site and our own client operations are US-hosted: Supabase for databases, Vercel for hosting and serverless functions, Resend for transactional email, and Google Calendar where a booking integration is in scope. Our privacy notice names them and describes what each one holds.
For a system we build for you, the hosting decision is yours and it is part of scoping. If your requirement is that the application and its database sit in a UK or EU region, that is a normal thing to specify and it changes the infrastructure plan, not the engineering. What it cannot change on its own is where we process data in the course of doing the work — support access, logs, and anything you send us during discovery.
The transfer basis, stated honestly
Under UK GDPR, sending personal data to the US requires a lawful transfer mechanism. The specific instrument is agreed as part of the engagement contract, alongside a data processing agreement, and it is a conversation to have during scoping rather than a box already ticked.
We would rather say that than claim a signed instrument we do not have on file for you specifically. If your data protection officer wants the transfer terms settled before a discovery call, ask — that is a reasonable sequence and it avoids doing scoping work that procurement later blocks.
What usually makes this easier than it sounds
Most of what an engagement touches is not special-category data and often is not personal data at all: order histories, inventory movements, scheduling patterns, system logs, document templates. Where personal data is genuinely in scope, the practical answer is usually to reduce it rather than to argue about it — pseudonymise before it leaves your systems, keep identifiers on your side of the boundary, and give the thing we build a narrower view than a human operator has.
That is an engineering decision made early, and it is cheaper than the alternative. Retrofitting data minimisation into a system that was designed to slurp everything is one of the more expensive things you can ask for.
Contracting and currency
Engagements are quoted and invoiced in US dollars, wherever the client is. There is no GBP price list, and we do not hold a rate in sterling that drifts against the market.
The practical consequence is that you carry the FX movement between quote and payment. For a fixed-fee phase agreed in March and invoiced in May, the dollar amount is the dollar amount; what it costs you in sterling depends on the rate on the day your bank settles it. On a five-figure engagement that is a real number and worth putting in your budget assumptions rather than discovering at invoice time.
We mention it because being surprised by it is a bad way to start a working relationship, not because it is unusual — it is how most US firms invoice international clients.
Pricing depends on integration access, data readiness, security and transfer requirements, evaluation coverage, migration, and support. Scope, price, deliverables, intellectual-property terms, and third-party fees are documented for the specific engagement. Contracting is under Colorado law.
Hours, and what “remote-first” actually means at seven hours
Our day starts at 09:00 Mountain Time, which is 16:00 in London for most of the year. The overlap is the UK afternoon: roughly 16:00 to 18:00 GMT, a little wider under British Summer Time.
That is a real constraint and it shapes delivery rather than being a footnote to it:
- Standups are yours, not ours. A daily sync at 16:30 your time lands mid-morning for us. That works indefinitely and is where most UK engagements settle.
- Written-first by default. Decisions land in writing so your morning is not blocked waiting for a US working day to begin. This is a discipline we would want anyway; the timezone just makes skipping it expensive.
- Overnight turnaround cuts both ways. Something raised at 17:00 UK is picked up during our afternoon and is usually waiting for you at 09:00. For review cycles that is faster than a co-located team, not slower.
Calls are booked in your own timezone at /book — the picker shows real availability converted to wherever you are, so there is no mental arithmetic and no 03:00 mistakes.
What we do not claim
We have not opened a London office, we do not have a UK data centre, and we are not going to tell you that the Atlantic is irrelevant. It is a seven-hour gap and a jurisdictional boundary, and both are manageable when they are planned around and irritating when they are not.
Our delivery process maps the operation with the people responsible for it, then documents the plan and ownership boundaries before a build begins. If the data-protection answer above is workable for you, the remaining commercial and technical terms can be scoped explicitly.