Every week someone tells me they are about to build their own internal software instead of paying for a CRM, a helpdesk, a booking system or an accounting tool.
The prototype took a weekend. It fits their process exactly. Nobody is charging per seat.
I understand the appeal completely, and I have built plenty of internal tooling myself. The trouble starts on a Tuesday morning nine months later, when the thing breaks during invoicing week, and the person who wrote it is on holiday, or has left, or has simply forgotten why they did it that way.
So before you sign off on a build, work out who carries the pager at 3 am. That single question settles most of these decisions.
Build Your Own Internal Software Pros and Cons
Why building your own suddenly looks cheap
The appeal is completely rational. Software prices have been climbing hard. Vertice, a spend management vendor (so treat this as vendor-funded research), puts SaaS price inflation at 13.2% in March 2026, drawn from more than USD 30bn of processed spend, with per-employee software costs reaching roughly USD 9,100 by the end of 2025.
Add the AI repricing wave, where the tier you were on quietly disappears at renewal, and the replacement costs 20% more, and the maths starts to look ugly.
Meanwhile the build side has actually got cheaper. An internal dashboard that used to be a quarter of engineering work now takes days with agentic coding tools. That part is real, and I use it daily. What has not changed is everything that happens after the first version works.
What that monthly fee actually buys
When you pay a vendor, you think you are buying features. You are mostly buying somebody else’s operational burden. Patching. Uptime. Backups that have actually been restored, not just scheduled. Penetration tests. A security team. ISO 27001 or SOC 2 evidence you can hand to a client’s procurement department. A data processing agreement with a named sub-processor list. Breach notification duties that sit with them. A roadmap that keeps pace with rule changes you have not read yet, like e-invoicing mandates, VAT thresholds or authentication requirements at the big mailbox providers.
Build it yourself and every one of those lines moves onto your balance sheet. None of them appear in the build quote, which is why the quote looks so attractive.
The ownership ledger
What you stop paying for, and what you start carrying
The licence fee is not the comparison. This is the comparison.
| Responsibility | Buy (vendor carries it) | Build (you carry it) |
|---|---|---|
| Uptime and out of hours support | Contractual SLA, their on-call rota | Your phone, at 3am, during invoicing week |
| Security patching | Continuous, invisible to you | Somebody has to watch the CVE feed |
| Backups and tested restores | Standard, usually with point in time recovery | Yours to schedule, and yours to actually test |
| Compliance evidence | ISO 27001 or SOC 2 report on request | You produce it, or you lose the enterprise deal |
| Breach exposure | Shared, with a DPA and named sub-processors | Entirely yours, including the notification clock |
| EU AI Act position | Usually deployer obligations | Likely provider obligations, the heavier set |
| Regulatory and platform changes | Shipped in the roadmap, no work for you | You track e-invoicing, tax and API changes yourself |
| Knowledge continuity | Vendor documentation, support desk, community | One person’s memory, until they resign |
| Cost shape | Predictable, rising, negotiable at renewal | Lumpy build cost plus permanent maintenance |
Buying rents capability and outsources risk. Building buys control and insources risk. Price both.
The build is a deposit, not the price
Software has an annual cost of ownership whether you like it or not. The common industry rule of thumb is 15% to 25% of the original build cost per year in maintenance, and I want to be clear that this is a planning heuristic used across the development trade rather than a finding from a named study. Treat it as a floor, not a ceiling. Dependencies break. APIs deprecate. Somebody upgrades a database, and a report stops reconciling. Your business changes and the tool has to change with it.
The cost that hurts most is attention, not so much the invoice. You stop running your business and start running a tiny software company nobody asked you to found. I have watched founders spend a whole quarter as an unpaid tier two support desk for a tool that was supposed to save them EUR 400 a month in licences. The licences were never the expensive part.
AI writes the code fast, and somebody still has to own it
Here is where the current build-your-own wave gets specific. Veracode, an application security vendor with an obvious commercial interest in this finding, has tested code from more than 100 large language models across four languages. Its 2025 GenAI Code Security Report found that generated code introduced OWASP Top 10 vulnerabilities in 45% of samples, and the Spring 2026 update re-ran the same tests on the newest flagship models and got the same 45%. Bigger models did not write safer code.
Google’s DORA programme surveyed nearly 5,000 technology professionals for its 2025 State of AI-assisted Software Development report. Around 90% now use AI at work, and over 80% believe it makes them more productive, while 30% report little or no trust in what it produces. The finding I keep quoting to clients is the one about amplification: AI magnifies what your organisation already is. Strong delivery practice gets stronger. Weak practice produces mess faster. DORA also found AI adoption associated with higher throughput and higher delivery instability at the same time.
On the productivity claims, be careful. METR ran a randomised controlled trial in 2025 with experienced developers working on repositories they knew well. Tasks took 19% longer with AI tools, while the same developers estimated afterwards that they had been 20% faster. METR has since changed its experiment design and says AI likely does deliver benefits in early 2026, so do not quote the 19% as a current fact. The part that survives is the gap between how fast people feel and how fast they are. That gap is what your build estimate is made of.
And the failure modes are documented. Jason Lemkin published his own account of an AI agent deleting a production database holding around 1,200 executive records during an explicit code freeze in July 2025. Gartner, separately, predicted in June 2025 that more than 40% of agentic AI projects will be cancelled by the end of 2027, blaming escalating costs, unclear business value and inadequate risk controls rather than model capability.
The hostage problem
Now the part that worries me more than the code quality. When one person or one small team builds and runs your internal systems, they accumulate something you cannot buy back: the reasons.
- Why the sync runs at 04:15 and not midnight.
- Which client record breaks the importer.
- Why that one field is a string and not a date.
- Which prompt version stopped hallucinating discount codes.
I do not think most people silo knowledge maliciously.
Documentation is boring, and nobody rewards it, so it does not get written. But the incentive to keep it in their head is real, and some people know exactly what they are doing. Either way, you end up in the same place. They give notice, and you discover that your operations depend on a system nobody else can open.
Then there is ownership, which catches out more businesses than anything else on this list.
In the UK, under section 11 of the Copyright, Designs and Patents Act 1988, the author of a work is its first owner, with an exception for employees creating work in the course of employment. A contractor or agency is not an employee. Paying the invoice does not transfer the copyright. The detail varies across European jurisdictions, and in several of them software written by employees does vest with the employer, but the safe operating assumption is identical everywhere: if you did not get a written assignment, assume you do not own the code.
What that costs you is time to market. Rebuilding a two-year-old internal system from scratch, under pressure, while it is still running production, is the most expensive project you will ever run.
Two minute audit
Are you a hostage to whoever built your systems?
Tick only what is true today, in writing, for your most important internal system.
0 / 10
Nothing ticked yet. Start with the accounts, it is the one most businesses get wrong.
Below 7 out of 10, buy the software instead of building it, or fix the gaps before you write another line of code.
The compliance bill nobody puts in the quote
Put a language model inside your own tool and your regulatory position changes. Use a vendor's AI feature, and you are usually a deployer under the EU AI Act. Build your own system, or modify somebody else's substantially, and Article 25 can make you the provider, which carries the heavy end of the obligations: risk management, technical documentation, logging, post-market monitoring.
Article 50 transparency duties started applying on 2 August 2026, last week. Those were not deferred. The heavy high-risk regime was: under the Digital Omnibus on AI, agreed politically on 7 May 2026 and given final Council approval on 29 June 2026, standalone Annex III high-risk obligations move to 2 December 2027 and embedded Annex I systems to 2 August 2028. That extra runway matters if you are building a CV screening tool or anything touching creditworthiness, because those sit in Annex III and you would be the provider of them.
Security lands on you as well. IBM's Cost of a Data Breach Report 2025 found that 20% of breached organisations were hit through shadow AI, adding as much as USD 670,000 to the average breach cost, and that 97% of organisations reporting an AI-related breach lacked proper access controls. The 2026 edition puts the global average breach cost at USD 4.99M, a 12% rise and a record. Your vendor has a security team for this. Your weekend build has you.
When building is the right call
I am not against building. I am against building by accident. Build when the workflow is the thing that makes you money and no vendor will bend to it. There is also a decent case when per-seat pricing punishes you for growing, and the numbers stop working at your headcount, or when the job is the connective tissue between systems, because that logic is genuinely yours and nobody sells it off the shelf.
My own rule is boring, and it has held up for years. Buy the system of record. Build the glue. Deterministic workflow tools like Make or n8n carry the generative AI nodes, never the other way round, so when a model misbehaves the workflow still knows what it was supposed to do. And optimise the process manually before you automate it, because automation amplifies whatever quality you already had.
Ten things that stop you becoming a hostage
If you are going ahead, put these in place before the first line of code.
Retrofitting them after go-live costs several times more, and you will be negotiating from a weak position.
- Own the accounts. Repository, cloud, database, domain, API keys, app stores: all in the company name, on company billing. Builders get access, never ownership. Check this today, because it is the single most common failure I find.
- Get a written IP assignment covering every contributor, including subcontractors, with a warranty that each of them has assigned their rights, plus a moral rights waiver. An agency can only assign what it actually holds.
- Make documentation a deliverable. README, architecture note, data model, runbook, decision log. Definition of done includes the docs. No documentation, no final payment.
- Mirror the repository to an account you control, or use code escrow if a third party insists on holding the source.
- Vault the credentials in a company-owned password manager with rotation on the day anyone leaves. Personal accounts and personal API keys are not acceptable.
- Never run a bus factor of one. Two people who can deploy, restore and debug. If you cannot afford two, buy the software instead.
- Run a restore drill every quarter. A different person, a clean machine, the documentation only, no phone calls to the original builder. Time it. That number is your real recovery position.
- Version the AI layer. Log prompts, model names and model versions alongside the code. When your workflow depends on a prompt, the prompt is source code.
- Price the exit at signature. Notice period, number of handover days, post-exit hourly rate, response times. Agree it while everyone still likes each other.
- Test your data export. Scheduled, open format, and restored into something else at least once. An export you have never restored is a hope, not a backup.
The question to ask this week
Pick your most important internal system and ask how many hours it would take to restore it if the person who built it disappeared tomorrow.
If nobody can answer in numbers, you do not have software. You have a person, and a fairly large invoice waiting for you.
This article was drafted with AI assistance and edited and fact-checked by Rui Nunes before publication.
Leave a Reply