Skip to content
All updates
Notes·

Why we keep data onshore by default

A short note on why every Pinchy build defaults to Australian-region infrastructure — and the rare cases where we'd tell a client otherwise.

Pinchy Inc lobster-claw logo mounted on a Sydney studio wall

Every Pinchy system ships onto Australian-region infrastructure by default. That's servers, databases, voice transcripts, the lot.

It's not a compliance theatre move — it's because most small business owners we work with don't have the time or inclination to interrogate where their customer data is sitting, and offshore-by-default has become the industry's quiet shortcut for cost savings.

We'd only move something offshore after a direct conversation about why, and what the trade-off buys. Usually it doesn't.

What "onshore" actually means in practice

When we say onshore, we mean the specifics. Databases run in AWS Sydney (ap-southeast-2) or equivalent Australian regions. Voice call recordings and transcripts are processed and stored in AU. Backups stay in AU. Logs and analytics stay in AU. The only data that ever leaves the country is the prompt sent to a foreign model provider — and even there, we route through providers with documented zero-retention contracts so the prompt is processed and discarded, not stored.

If a client genuinely needs full sovereignty — defence-adjacent work, healthcare records, certain legal categories — we have a path for that too, using on-shore-hosted open-weight models. We just don't quote it as the default, because for the vast majority of small businesses the residency-in-AU build is the right balance of capability and cost.

Why the industry quietly defaults to offshore

The honest answer is that US-region infrastructure is cheaper, the docs are better, and most SaaS tooling assumes you're in us-east-1 unless you fight it. So when a vendor is racing to ship the cheapest possible version of an integration, the default region wins. The customer rarely asks, and the contract rarely says.

We've seen plenty of "Australian" AI vendors whose customer data — including call recordings of actual Australian customers — sits in Virginia or Oregon. That's not illegal. It is, however, something the business owner should be making an informed decision about, not inheriting by accident.

Where it matters for your business

For most small businesses the practical difference is three things. First, latency: a voice agent answering a Sydney customer's call from a Sydney region is measurably faster than one routing through Singapore or the US, and faster matters when a caller is deciding whether you sound like a real business. Second, privacy posture: when you can tell a customer "your details are stored in Australia", that's a real answer, not marketing. Third, the day a piece of legislation tightens — and the Privacy Act amendments coming through Parliament are moving in that direction — you don't need to scramble to migrate. You're already where you need to be.

The rare cases we'd say otherwise

We won't pretend onshore is always the right call. If a client needs a feature that only exists in a US-region model, or wants a specific tool that hasn't shipped in AU yet, we'll say so. We'll lay out the trade-off, document the data path, and let the client decide with their eyes open. That conversation has happened maybe four times in two years. Every other build has been onshore by default — because that's what the customer would have asked for if they'd known to ask.

The bottom line

Onshore-by-default doesn't cost us much. It costs the client a small premium on infrastructure that's already a rounding error against the value the system delivers. And it means we never have to send a client an awkward email explaining that their customer data has been somewhere they didn't expect. That's worth the few extra dollars a month.

Todd, Sydney

Want to chat about your business?