Boundry started with a question we could not shake: why does using a modern software tool so often mean agreeing to send customer data overseas?
Every software team wants the same useful building blocks. Send an email. Deliver an SMS. Keep a customer conversation moving. Trigger the next step when something happens. Connect one system to another without rebuilding the plumbing every time. These are ordinary workflows, but the data inside them often is not. A password reset contains identity data. An appointment reminder can reveal a care relationship. A support conversation can contain the exact information a customer expected to remain close to home.
We love what global software has made possible. A small team can use an API built by specialists and ship something in an afternoon that once took months. But somewhere along the way, global became the only option. Many otherwise excellent providers offer no regional path at all. Others put storage in a chosen region while queues, logs, event history, account systems, or operational access remain somewhere else.
The strange part is how normal this has become. Companies are asked to choose between the polished product and the regional answer. They can ask customers to accept offshore processing, or they can assemble cloud primitives themselves and become the operator of an email, messaging, or automation platform they never wanted to build. That feels completely backwards.
We made global the default. Then we made customers justify wanting their data kept nearby.
You often do not discover the problem when you choose the provider. You discover it much later, during an enterprise security review, a health-sector procurement process, or a government questionnaire. A small infrastructure decision made years ago suddenly blocks the deal in front of the whole company. The engineers now have to replace something that works, under pressure, because the regional option was never there in the first place.
We are building the product we wish those teams already had. Choose a region once, then use the everyday tools your product needs inside it: email, SMS, customer conversations, document processing, and Zapier-like automations that connect events to actions. Processing, transient state, application storage, and operational records should have one clear home. You should not need a forensic investigation to explain where the work happened.
That is the larger idea behind Boundry. It is also larger than what we can honestly say is live today. SMS, conversations, document processing, and regional automation are the direction. We are starting with transactional email because almost every product needs it, it regularly carries sensitive context, and it is one of the first offshore paths a security reviewer finds.
Boundry Email begins with a simple rule. A project gets one permanent region. Its credentials remain scoped to that project and region. The dashboard asks the control plane for a short-lived project session, then calls the regional API directly. The control plane does not forward message content.
The honest boundary matters as much as the regional infrastructure. Boundry runs project message operations and configured application storage in the selected regional plane. Public requests transit Cloudflare, Clerk handles account identity centrally, and recipient mailbox providers are outside Boundry's boundary after delivery.
We say those exceptions plainly because regional should not become another vague marketing word. A useful boundary is one an engineer can explain, a security reviewer can test, and a customer can make a decision from. If part of the path sits outside it, that belongs in the answer too.
Sydney is the only live Boundry region today. It is region 01: the first proof that this model can be concrete, useful, and pleasant to build with. Future regions remain roadmap-only until the infrastructure exists and the evidence is ready to publish.
We do not think choosing a region should mean choosing worse software. We do not think keeping customer data nearby should require a special pleading exercise. And we do not think every product team should have to rebuild the same infrastructure just to give a customer a straight answer.
Modern workflows should be available everywhere, without customer data having to go everywhere too.
That is why we are building Boundry. We are starting with email, in Sydney, and proving the idea one real workflow at a time. Then we will keep going until regional is no longer the awkward exception. It is simply how the product works.