Skip to content
← blog

Your accounts, not ours

We build on the Gmail, Calendar, HubSpot and Xero you already pay for. Why there is no migration, and who owns what when we leave.

Twill Studio3 min read

There is a version of this business where we put a platform in the middle. The client’s data moves into our system, the agent runs on our infrastructure, and every month they pay for the privilege of their own workflow. It is a better business model. It is a worse deal for the client, and it is not what we do.

We build on the accounts the business already has.

No migration

A small business’s tools are not chosen; they accumulate. The calendar is Google because the phone is Android. The books are Xero because the accountant said so. The CRM is HubSpot because the free tier was enough four years ago and now there are two thousand contacts in it. Half the real state of the business lives in a spreadsheet with a name like jobs 2026 FINAL.

That stack is not elegant and it does not need to be. It works, everyone knows where things are, and the cost of moving it is not the export — it is the six weeks where nobody can find anything. Every migration project we have watched from the outside spent its entire budget re-learning what the old system already did.

So the agent goes to the tools. It reads the calendar the owner already looks at. It writes the deal into the HubSpot pipeline the team already checks. It drafts the invoice in Xero, in the format the accountant already accepts. Nothing new to open in the morning.

The practical effect is that the agent is useful on day one and reversible on any day after. If it stopped tomorrow, the business would still have its calendar, its contacts and its books, exactly where they were.

How the connection actually works

We connect through each vendor’s own API, on the client’s own account, with credentials the client holds.

  • Their tenancy. The Google Workspace, HubSpot portal and Xero organisation are theirs. We are granted access; we are not the account owner.
  • Scoped access. Each integration gets the narrowest permission set that does the job — calendar events but not the whole Drive, one HubSpot pipeline rather than every object, invoices in Xero rather than payroll.
  • A named service identity. The agent acts as itself, not as the owner. Actions in the log say the agent did them, which is what makes the audit trail worth anything.
  • Revocable in one click. The client can pull our access from their own admin console without calling us. We tell them where that button is during handover, on purpose.

Where an API doesn’t exist or doesn’t cover the case, we say so and we don’t paper over it with brittle scraping. Sometimes the honest answer is that a step stays manual and the agent just prepares it.

What we hold, and for how long

The agent needs some state of its own: the workflow definition, the stop conditions, the run log, and whatever short-lived context a conversation needs while it is happening. That is the smallest surface we could design and still have something reviewable.

We do not build a second copy of the customer database. There is no shadow CRM accumulating in our infrastructure that becomes a reason you can’t leave. The system of record stays the system of record.

Credentials live in the client’s secret store or ours, encrypted, and are rotated on handover. Nothing is shared between clients — no pooled accounts, no shared workspace, no cross-tenant anything.

Who owns what at the end

On the last day of an engagement the client gets the repository, the workflow definitions, the prompts, the runbook, and the vault of decision notes. In their name, in their accounts, in formats that open without us.

They own the integrations because they always did. They own the code and the specifications because we wrote them into their repo. They can hire someone else to change it, or change it themselves, or leave it alone — it will keep running either way, because it runs on infrastructure they control.

We keep no per-seat fee and no lock on the door. If they come back it should be because the next thing is worth building, not because leaving is expensive.

The trade-off, stated plainly

Building on someone else’s stack is harder than owning the whole thing. You inherit rate limits, awkward data models, and a field somebody renamed in 2023. We spend real engineering time on that.

We think it is the right trade. The alternative asks a business with two vans and one office day a week to bet its operations on a studio’s continued existence. Nobody should have to make that bet to answer their phone properly.

We build the agent. You keep running the business.

Tell us what eats your week. We’ll tell you what an agent can take off it.

usually replies same day