With a subscription you own access, nothing more: stop paying and the capability, your prompts and the workflows built around it all go. With a custom build, ownership is whatever the contract says, so read it. Our standard is co-ownership: you own the system, can see inside it, and can switch any part off.
What do you actually own with a subscription?
Access. That's the honest answer, and it's the whole answer. A subscription buys you the right to use someone else's system while you keep paying, on terms the vendor writes and can change. The software isn't yours, the model isn't yours, and in most cases the useful things your team creates inside it, the prompts, the templates, the tuned workflows, aren't practically yours either, because they only work inside the tool.
None of that makes subscriptions bad. Renting is the right call for generic jobs, as we've argued in our guide to build versus buy. The problem is renting without noticing. Zylo's 2026 SaaS Management Index found 46% of software applications go underutilised or unused: that's vendor research on large, mostly US organisations, but the direction of travel is familiar to anyone who has audited their own subscriptions. Businesses are very good at paying for software and much worse at owning anything by the end of it.
What can you own with a custom build?
With a custom build you can own the whole thing: the code, the prompts, the data flows, the documentation, the design decisions. Whether you actually do depends on the contract, because some builders keep the interesting parts on their own platform and sell you a project that is really a subscription with a setup fee.
Our standard is co-ownership, and it's specific: the client owns what we build, can look inside any part of it, can run it in their own cloud, and can switch any component off without asking us. The payroll checking system we shipped works exactly this way: it runs in the client's own cloud, keeps a full audit trail, and the client owns it. If we disappeared tomorrow, their system would keep checking payslips on Monday.
That isn't generosity, it's the point of building. A system you own outright is an asset on your side of the table. A system you rent is a line in someone else's revenue forecast.
What happens when you stop paying?
It depends entirely on which route you took, and this is where the two routes stop resembling each other.
- Subscription: access ends, usually within days. You may get a data export window: check what format the export arrives in, because a pile of JSON files is not the same as your workflows. Everything your team built inside the tool stops working, and the muscle memory they built around it becomes a cost of switching.
- Custom build you own: the system keeps running, because it's yours and it lives in your infrastructure. What stops is support: new features, fixes, updates. You can bring those in-house, hire another firm, or come back later. The asset survives the relationship.
- Custom build on the builder's platform: the worst of both. You paid project money, but the system runs on their servers under their licence, so when you stop paying it goes dark like any subscription. If a builder's proposal is vague about this, that vagueness is the answer.
What about your data?
Your data is the part of the question that can't wait until you cancel, because it's flowing from day one. With a subscription, everything the tool touches lives in the vendor's cloud under the vendor's privacy policy, and that policy can change with notice. Whether your content is used to train the vendor's models varies by product and by plan tier, and the honest answer is in their terms, not their homepage.
A well-built custom system removes most of the question. Ours are designed so the data stays in your systems, nothing is sold on, and nothing is used to train any model outside your business. UK GDPR stops being a recurring worry and becomes a design input: you can point at where every record lives and who can touch it. If you handle candidate or client data, we've gone deeper on this in AI and candidate data under UK GDPR.
What should you check in any contract?
Five questions settle ownership before you sign, whichever route you're taking. Put them to the vendor or builder in writing and keep the answers.
- Who owns the code, prompts and configuration once the final invoice is paid? "You do" should appear in the contract, not the sales call.
- Where does the system run, and can you move it? Your own cloud, or theirs? If theirs, what does migration cost and who does it?
- What exactly can you take with you if you leave, and in what format? A working system, usable exports, or a goodbye email.
- Can your data be used to train anything outside your business? Get the answer in writing, including for sub-processors.
- What happens to support, fixes and security updates if you part ways? Owning a system nobody will maintain is a slower version of losing it.
If a supplier is relaxed about answering all five, you're probably in good hands. If any answer starts with "in practice, that never comes up", it comes up.
Sources
Figures and claims in this guide draw on our own delivery work and the sources below. We only publish numbers we can stand behind.
- Zylo, SaaS Management Index (2026 edition, figures updated 2 April 2026), accessed 8 July 2026: zylo.com/blog/unused-software-cut-costs. Vendor research, based on Zylo's largely US enterprise customer base.
- AI Nativ.es delivery experience, 2026: the payroll checking build described is a real client project, told without names until we have written permission to use them.