Skip to content

Ownership and security

It runs in your cloud, behind your own security

Not on our servers and not under our licence. Your data stays inside the cloud account you already own, govern and audit, under the same perimeter, the same keys and the same access controls you apply to everything else. Nothing here asks you to make an exception to your own security policy.

Infrastructure defined as code and deployed into an account the client owns

Why this is different

Your data never becomes ours to hold.

An integration platform runs your data on its infrastructure, under its licence, and you pay for that every month. A few will run part of it inside your own network, but in most of them there is still a licence that can lapse, or a piece they control sitting outside your account. That works well right up until you want to leave, change the commercial terms, or ask what happens if the vendor stops trading. We build it inside your own cloud account instead.

A hosted integration platform

  • Your order data lives in their tenancy, or under their licence
  • Leaving means rebuilding every flow somewhere else
  • Per-message pricing that grows as your business does
  • If the vendor changes direction, so do you

Built in your cloud account

  • Nothing passes through infrastructure we own
  • Every flow is infrastructure code in your repository
  • You pay the provider directly, at cost, and can see every line of it
  • If you replace us, it keeps running while you do

That last point is deliberate, and it is the honest answer to the fair question about a small firm: what happens if we are not here. The work is documented, the infrastructure is code, and the account is yours. You are never one relationship away from your orders stopping.

How it is built

The parts you cannot see are the ones that decide whether it lasts

Anything can be made to look finished. These are the decisions taken on every build, whether or not anyone asks — because they are expensive to add later and invisible until they are needed.

  • Security decided at the start, not bolted on

    Zero trust: nothing is treated as safe because it sits inside the network. Every request proves who it is and what it is allowed to do, on its own merits.

  • Who can do what, written down

    Role-based access control from the first day, so permissions follow the job rather than accumulating quietly over years. Joiners and leavers are a process, not a scramble.

  • Encrypted on the wire and on the disk

    Data is encrypted in transit and at rest, with keys held in the cloud provider’s key manager rather than pasted into a configuration file somebody can read.

  • Every change leaves a trace

    Audit trails, application logs and metrics collected from day one, with monitoring and alerts on the handful of things that genuinely warrant waking someone.

  • Built for the load it will really see

    Performance targets are agreed before the build and measured against, rather than discovered by your customers on the busiest day of the year.

  • Room to grow without starting again

    More people, more locations or more data should be a configuration change. Designs that only work at today’s size are the most common reason for a rebuild in year three.

  • Backups that have actually been restored

    A backup nobody has restored is a hope. Recovery is rehearsed, and how much you could lose and how long it would take are written down before you need them.

  • Every account in your name

    The cloud account, the repository and the partner credentials registered to your business, with the credentials handed over. Nothing is held on your behalf, so leaving costs you nothing but notice.

TOGAF

Architecture that follows a framework, not a habit

Work is structured with TOGAF 10 — the enterprise architecture method large organisations run their transformations on — applied at the size of your business rather than in its full ceremonial form. It is why the questions asked in week one are the useful ones.

AWS

Built and run on AWS, in Australian regions

Applications, storage, databases and networking on AWS, following the Well-Architected Framework and deployed as code so an environment can be rebuilt rather than repaired. Deployed in Sydney by default, in your account, so your data stays in the country.

What actually gets deployed

Six things go into your account. You can see all of them.

No black box, no agent phoning home, no part of this that only we can look at. Everything below is standard managed cloud infrastructure, defined in code that lives in your repository — which is what makes the ownership claim checkable rather than reassuring. The ownership argument rests on the account being yours, not on whose cloud it is.

Ways in

  • Managed SFTP endpoint, one login per partner
  • HTTPS endpoints for webhooks and APIs
  • Scheduled pollers for systems with no push

The spine

  • An event bus and a queue per flow
  • Orchestration with retry, backoff and timeout as configuration
  • Dead-letter handling on every step, with nothing silently dropped

Meaning

  • Declarative field mapping, stored as configuration per partner
  • A thin canonical model — order, shipment, product, invoice
  • Validation rules that reject before your customer does

Memory

  • Every message archived exactly as received
  • Idempotency keys, so a replay cannot double-post
  • Search by your own order number, not by our internal id

Care

  • Secrets held in a managed store, never in code
  • A key of your own for encryption at rest
  • Alerting tied to your trading hours

Proof

  • Infrastructure defined as code in your repository
  • Every deployment reproducible from that code
  • An audit trail of what ran, when, and what it did

Your order data is never used to train anything, by us or by anyone else, and no copy of it leaves your account to be analysed or benchmarked. It never becomes ours to hold. Where a vendor’s network carries your transactions, what happens to that data is a question worth asking; here it does not arise. Three things are deliberately absent: a licensed runtime of ours, a per-message meter, and any component you would have to keep paying for to keep your own orders moving.

Leaving

The part most vendors will not put in writing

A small firm asking you to run your order flow through it invites a fair question: what happens if we are not there. Hand-waving that question is worse than answering it, so here is the answer, and it is structural rather than a promise.

You already hold everything

The cloud account is yours and always was. The infrastructure code is in your repository. The mapping configuration is data in your own database, not a proprietary format on our server.

Nothing stops when we do

There is no licence to lapse, no call-home, no key that expires. If we vanished tonight, your orders would keep flowing tomorrow morning.

Thirty days, not a negotiation

Support is month to month. Notice is thirty days. There is no exit fee, no data-extraction charge and no final invoice for handing back something you already own.

A handover that is written before you need it

Runbooks, partner contacts, credentials inventory and known quirks are maintained from day one as part of the monthly fee — not assembled resentfully at the end.

This is written down because it is the objection we expect and the one we would rather you raised on the first call than the third.

Ask what it would take to leave

It is a reasonable question to ask before you commit, and the answer is the same whether you ask it now or in three years.