Offshore Isn't the Risk. An Unclear Brief Is.

Buyers in the UK, Australia and New Zealand still treat "offshore" as the main hazard. The builds that fail usually fail earlier: a vague brief, floating scope, and no way to know what "done" means. Here is how to write the brief, stage the money, and still own the code.

Symentic Team

26 Sept 20268 min read

Most buying conversations about custom software still open on geography.

"Are you local?" "Where is the team?" "Is this offshore?"

Those are fair questions. They are not the questions that decide whether the project works.

We are a UK company. Engineering for Symentic sits with a team that is not all in Canterbury. We build for clients in the UK, and we are deliberately expanding how we talk to buyers in Australia and New Zealand — same English-language working day overlap for AU/NZ mornings, same rule on ownership, same refusal to start without a written scope. If "offshore" were the fatal variable, we would not still be shipping.

What kills projects is quieter: a brief that never got concrete, a scope that floats every week, and a contract that never defined what "done" looks like. Distance makes that worse. It does not create it.

Here is the version that works whether your partner is in the next city or ten time zones away.

What "offshore" is actually being asked

When a founder in Manchester, Melbourne or Auckland says they are nervous about offshore, they usually mean one of four things:

Will anyone understand our business?
Will we be able to talk when something breaks?
Will we own the code when this is over?
Will the price we were quoted survive contact with reality?

Those are the right fears. None of them is solved by a London postcode on the invoice. A local studio with a mushy brief will burn the same money — sometimes faster, because meetings feel productive.

Flip it: a remote team with a sharp brief, fixed milestones, and an assignment clause that actually transfers IP is a lower-risk arrangement than a nearby agency still "figuring out requirements" in week six.

Geography is a logistics problem. Ambiguity is a product problem.

The brief most people send (and why it fails)

A typical first email looks like this:

We need an app / portal / platform for our business. Something like X. Mobile would be good. Can you send a quote?

There is nothing wrong with starting there. There is everything wrong with pricing from there.

That message does not say:

who the users are
what they do in a normal week
which systems already hold the truth (spreadsheets, Xero, MYOB, Shopify, a legacy SQL box)
what "success" looks like in 90 days
what is explicitly out of scope for version one

Without those, every supplier invents a different product. The cheap quote assumed a thin CRUD app. The expensive quote assumed SSO, audit logs, and three integrations. You think you compared prices. You compared two different products.

That is why nobody honest can price your software from a blog post — and why "ballpark on the call" is usually theatre.

The one-page brief that changes the conversation

You do not need a 40-page requirements pack. You need a page that a senior engineer can read once and argue with.

1. Who uses it, and what job are they doing?

Name roles, not "users".
"Warehouse supervisor closing the day" beats "admin dashboard".
"Franchise owner checking yesterday's orders" beats "reporting module".

If you cannot name three concrete jobs, you do not have a product yet. You have a wish.

2. What is the source of truth today?

List the real systems:

Spreadsheets (how many, who owns them)
Accounting (Xero / QuickBooks / MYOB — especially common for AU/NZ SMEs)
Payments, CRM, email, inventory, booking tools

Custom software almost never starts on a blank planet. It starts by replacing or wrapping something people already trust on Fridays.

3. What must version one do — and what must it not do?

Write two lists. The second list is more important.

Version one ships when the first list works in production. Everything on the second list is a later conversation, not a silent expectation.

If you skip the "not" list, scope creep is not a surprise. It is the plan.

4. What does "done" look like in a sentence you could show a non-technical co-founder?

Examples that work:

"A UK ops lead can create a job, assign a tech, and see status without opening WhatsApp."
"An Australian store manager can close the day and see cash + card + online in one total."
"A NZ franchisee can invite staff and set permissions without emailing us."

Examples that do not:

"Modern, scalable platform"
"AI-powered insights"
"Better UX"

5. Constraints that are actually constraints

Budget band, go-live date, compliance (GDPR / UK GDPR, Australian Privacy Act, NZ Privacy Act), who hosts, who owns accounts, who holds production credentials.

If the answer is "we'll figure hosting later", you have already decided someone else's personal AWS account will become a problem.

Fixed scope is not rigidity. It is honesty.

People hear "fixed scope" and imagine they can never change their mind. That is not what it means.

It means: we agree what version one is, we price that, and changes become written change requests — not a vibe that slowly eats the margin and the timeline.

A usable fixed-scope pack usually contains:

Artefact	What it prevents
Written scope (in / out)	Two different products sharing one quote
Milestone list with demoable outputs	Paying for "progress" you cannot run
Acceptance criteria per milestone	Arguments about whether something is finished
IP assignment on creation / payment	Paying for code you still do not own
Hosting and account ownership list	Lock-in by accident

If a supplier will not write those down, the timezone is the least interesting fact about them.

We work fixed scope or retainer. Fixed scope is for a defined first version. Retainer is for ongoing change after the system is real. Mixing them without saying so is how both sides feel cheated.

Stage the money so distance cannot hurt you

Cross-border or not, payment shape is your real protection.

Small milestones. Each one leaves you with something that runs.

A deposit against a slide deck is a gift. A deposit against a repository you own, with a staging environment you can open, is a project.

A practical pattern for a 6–12 week focused build:

Discovery locked to a short paid spike — outputs: brief refined, architecture sketch, risk list, fixed quote for build.
Build in 2–3 week slices — each slice demoable; each invoice tied to acceptance.
Hand-back rehearsal before final payment — repo history, second machine setup, credentials inventory, data export. We wrote the ownership version of this drill here; run it whether the team is in Birmingham or Bengaluru.

If someone wants 50% upfront for "team allocation" and cannot show running software for six weeks, geography did not create that risk. Commercial structure did.

Overlap hours beat "we're local"

For UK buyers, a partner with reliable UK afternoon coverage is enough for most decisions.

For Australia and New Zealand, the useful question is not "are you in Sydney". It is: do we share a daily window where decisions can land the same day?

AEST/AEDT sits roughly five to six hours ahead of India Standard Time, and New Zealand a little further. A team that starts early can cover AU/NZ mornings. That is a working arrangement. A "local" agency that only answers after three chases is not.

Ask for:

the overlapping hours, in writing
who attends the weekly decision call (names, not a generic "account manager")
how production incidents are raised after hours

You are buying response shape, not a pin on a map.

What still matters legally (UK, AU, NZ)

Distance does not cancel law. It makes the paperwork more important.

Who owns the code? Paying the invoice is not enough in most places. You need a signed written assignment. Details and the hand-back drill: You paid for it. In most countries, that doesn't mean you own it.
Which entity invoices you? Brand vs legal entity vs bank account — understand it before the deposit.
Whose privacy law follows your users? UK GDPR / GDPR follow people in those regimes; Australia and New Zealand have their own privacy acts. Ask where data sits and who the sub-processors are.
Can you leave? If you cannot export your data and rebuild elsewhere, you did not buy software. You rented a hostage situation. Same exit test we use when every supplier looks the same.

For UK-incorporated suppliers you can still do the Companies House / filing pass. For everyone else, the brief + ownership + hand-back tests travel further than any register.

A short scorecard before you sign

Signal	Prefer	Walk carefully
Brief	They push you to sharpen in / out lists	They quote from a one-line email
Price	Fixed for a defined v1, change requests written	"We'll see as we go" with a round number
Delivery	Demoable milestones, repo in your org	Zip files, screenshots, no staging URL
Ownership	Assignment clause + subcontractor coverage	"You own it" with no mechanism
Access	Named overlap hours for your timezone	"We'll be available" with no window
Exit	Hand-back rehearsal on the plan	Resistance to a 25% rehearsal

Notice timezone is one row. Brief quality is the rest of the table.

The short version

"Offshore" is a label. It is not a diagnosis.

Projects fail when nobody can point at version one, when acceptance is a feeling, and when ownership is a slogan. They succeed when the brief is sharp, the milestones run, the money follows demos, and the code is yours in writing.

That is true in Canterbury, Sydney, Auckland, or anywhere the engineers happen to sit.

Run this on us. Send the one-page brief — roles, source of truth, in/out list, done-sentence, constraints. We will tell you whether it is buildable as a fixed-scope first version, what we would cut, and what a 6–12 week shape looks like. If you already have quotes from other teams, send those too; we will read the scope and IP clauses whether or not we bid. See what we've built, or tell us what you're trying to do.