What happens if we disappear? Nothing.

01Who owns the code

You do, outright, on final payment, and there are no licence fees behind it. Not per seat, not per year, not ever. Change it, extend it, hand it to another firm, or sell the business with it. None of that needs our permission.

Here's the other half, stated plainly rather than left in the contract. We keep the right to reuse the general-purpose modules we write, the building blocks that have nothing to do with your business, in our own code library and in other builds. Your system, your business logic, your data, your content and your configuration are yours alone, and they never turn up anywhere else. That's also what keeps a build affordable, because you're not paying us to write an audit log or a payment integration from scratch.

*Final agreement and terms defined in the services agreement between parties.

02Where it lives

In your code repository, your cloud account and your database, billed to you directly by the providers. We work in them because you've given us access, and you can take that access away whenever you like.

That goes for automations and connections as well as full builds. They run in accounts you own, on credentials you control, and nothing we set up lives in an account of ours.

03What you get at handover

• The running system, in your account
• All of the source code, with the full history behind it
• The infrastructure written down as code, so it can be rebuilt from scratch
• A written map of how the pieces fit together
• Runbooks for the things that need doing: deploys, backups, restores, access changes
• A recorded walkthrough for whoever looks after it next

None of that is assembled at the end as a leaving present. It's written as the system is built, which is the only way it ends up true.

04How the work is documented

Every firm says its work is documented. The question worth asking is whether a company you've never met could read it and take over on a Monday, and that comes down to three things: who holds the repository, whether the history is intact, and whether the writing sits beside the code or in somebody's drive folder.

The repository is created in your organization, so it's yours from the first commit rather than transferred at the end. You get every change, who made it, when, and why it was made. Nothing gets flattened into a single delivery drop, because a system with no history is one nobody can safely change.

05What it costs to run

Owning software isn't free. You pay the hosting provider every month, and you'll want someone keeping it healthy. The honest comparison isn't build against subscription. It's build plus hosting plus upkeep against subscription, and we put both sides in front of you before you decide.

We don't publish a hosting figure here, because it depends on what gets built and how much of the business runs through it. You get your number twice before you commit: at scoping, and again in the scope of work, next to the build price and the support agreement.

06Ongoing support and improvement

Most clients keep us on after launch, on a fixed monthly agreement. We scope it during the initial project scoping, so the number is on the table before the build starts rather than after launch, when you're least able to judge it. Typical agreements run $250 to $3,000 a month. It can be less or more, depending on how complex the solution is, how much of the business runs through it, and how much improvement you want each month.

It covers keeping the software healthy and a set amount of incremental improvement, because a system people actually use never stops changing. End it whenever it stops earning its place, on 90 days' notice, and you keep the software, the repository and the documentation either way. There's no exit fee and nothing to buy back.

• Security patches and dependency updates on a set cadence
• Monitoring, backups, and restores that get tested rather than assumed
• Fixes, with response times written into the agreement
• Hosting help, and a regular look at what it's costing you
• A set amount of development time each month for improvements you choose
• Documentation and runbooks kept current with every change
• Questions answered for your team, including whoever joins it next

07What happens if we vanish

Nothing stops. The system runs in your account, not ours. Because it's documented and built on standard, widely used tools rather than anything proprietary to us, another firm can read the repository and carry on.

And what they read won't be out of date. Every time the code changes, AI updates the documents that change affects, and an engineer checks the update before it's merged. Documentation usually drifts from the software within months of launch. Here it keeps pace, so whoever opens the repository next finds a description of the system that's actually running, not the one that launched.

08What happens if you want to leave

You leave. There's no exit fee, no data held back and no migration project, because you already have everything. There's no scramble to write things up on the way out, either: the documentation has been kept current with every change, so it's as ready the day you give notice as it will ever be. We'll hand over whatever access the next team needs, and we'll talk to them if that helps.

09When you shouldn't build custom

Plenty of software is worth renting. If a tool fits your business, costs little and does its job, keep it. Email, accounting, payroll and certified systems like an EHR are nearly always better rented. Custom starts to make sense when a tool is priced per person and your team keeps growing, when you use a fraction of what you pay for, or when the workarounds cost more than the subscription.

If the review finds that what you have is fine, that's what it will say.