For years, building internal software instead of buying SaaS was usually a bad idea. Coding agents have moved that boundary.
July 2026 · Juho KoskelaFor most companies, “build versus buy” stopped being an interesting question years ago.
If somebody already sold a competent CRM, scheduling system, support desk, CMS, analytics tool, whatever, you bought it. Custom software meant tying up scarce and expensive engineers to recreate something a vendor could amortize across thousands of customers, while maintaining it basically forever.
That logic is still sound. The numbers underneath it are not.
Coding agents are now attacking the expensive part of bespoke software: ordinary engineering work. Not just producing the PoC – adding tests, tracing bugs, writing migrations, updating APIs, adding features end-to-end, addressing review feedback, and all the other endless small jobs that turn “we built a usable tool” into “we own a tool.”
“Bespoke software has become rational for a much larger class of problems than it was five years ago.”
I’m not arguing SaaS is dead, far from it, actually. I’m arguing that the old build-or-buy spreadsheet deserves some new numbers.
The interesting change is not how many lines of code one engineer can produce.
It is the size of the problem that can justify having software built specifically for it.
A mid-size sales team rarely needs “a CRM.” It might need companies, contacts, deals and activities wrapped around one particular sales process.
It does not need a workflow builder capable of representing every possible sales organization on the planet. It just needs its workflow.
The same applies elsewhere.
You do not need to recreate Calendly – you might need Outlook calendars, round-robin assignment, three scheduling rules and notifications.
You do not need an enterprise automation platform – you might need a queue, some database tables and four integrations.
Historically, even these narrow systems came with a fairly high fixed cost. Someone had to design them, implement them, test them and continue caring about them six months later. That pushed companies toward configurable general-purpose products even when they were awkward fits.
Coding agents lower that fixed cost.
The useful pattern is quite the opposite:
buy the commodity layers, own the logic that is specific to you.
Use Microsoft 365 for email and calendars. Use a managed database. Use Stripe for payments. Use an identity provider for authentication.
But if the scheduling rules, customer model or billing workflow are peculiar to your business, owning that thin layer starts looking much less unreasonable.
Commercial software has to work for many customers. Eventually, that requirement becomes visible in the product.
A CRM needs custom fields, custom objects, pipeline configuration, workflow automation, extensions, dashboards, APIs and probably a lobotomized AI assistant. A scheduling platform accumulates routing rules, teams, forms, workflows and increasingly elaborate calendar logic.
None of this is irrational per se; the vendor literally cannot build a separate product for every customer.
But the customer pays for that generality twice: with money and complexity.
A particularly damning case is the feature that satisfies the checklist without satisfying the workflow.
Imagine a CRM that advertises Microsoft 365 calendar integration, but puts its activities in a separate calendar inside Outlook. Technically, the integration exists.
With one caveat: the salesperson now has two calendars.
If they have twenty or thirty CRM activities on a busy day, that stops being an inconvenient implementation.
“The vendor has solved the generic problem. You still have to solve your specific one.”
This is where bespoke software has an unfair advantage: it is allowed to assume things.
An organization has one sales process. One set of calendar rules. One data model. A known set of edge cases that actually matter.
What would be an unacceptable hard-coded assumption in commercial software can be the entire point of internal software.
The usual cost comparison cheats a little.
A 30 €-per-seat SaaS product looks cheap next to engineering salaries. At 20 users, it probably is.
At 200 users, it costs 72 000 € per year. At 1 000 users, 360 000 €.
That may still be excellent value. Vendor scale is still real, and some products would be absurd to reproduce internally. Looking at you, Salesforce…
Consider the modern version though: a narrowly scoped internal system that might previously have demanded several engineers can increasingly be built and owned by one technically strong person supervising agents alongside other work.
Take a very rough example. Suppose implementation takes three weeks of fairly focused effort, followed by a week of post-launch bug duty, and ongoing maintenance averages five hours per month.
At roughly 5000 € per month for a Finnish software engineer, plus employer costs and overhead, you’re somewhere around 4000-5000 € in engineering cost to get the system into production and 200–300 € per month to maintain it.
Those numbers are intentionally approximate. The interesting property is that they barely depend on seat count.
On top of that, the subscription rarely means engineering cost went to zero.
Someone configures the product. Someone migrates data into it. Someone maintains integrations around it. Someone works around the parts that do not fit your use case.
So the actual choice often looks less like:
buy software vs. build software
and more like:
rent a generalized application and build the missing pieces around it vs. own a narrow application and rent the commodity pieces underneath it
AI changes it because the second option no longer necessarily implies dedicating a team to CRUD screens and routine maintenance.
Generating software has been getting cheaper for years – that alone would not move the boundary very far.
A proof of concept is cheap. Long-term ownership is annoyingly expensive.
The more interesting thing about current coding agents is how many of the boring tasks they can do when production exists:
These are not glamorous demonstrations of modern artificial intelligence; rather, they are exactly the work that makes a small bespoke system expensive over its lifetime.
If agents compress that maintenance burden as well as initial implementation, the economics change much more substantially than modern vibe-coding demos suggest.
There is an obvious trap here: if creating internal software becomes cheap enough, companies will create far too much of it.
We already know how this story goes – cheap spreadsheets gave us spreadsheet jungles, no-code platforms gave us undocumented workflows that one person understands.
AI can produce the same mess at industrial speed.
The fact that an agent can implement something does not mean the thing should exist.
More importantly to me, AI lowers the cost of writing software without reducing the cost of being wrong.
A broken authorization feature can still leak customer data. A bad billing calculation still loses money. A race condition is no less corrupting because an agent built it.
Which is why the human part of software development does not disappear as implementation gets cheaper – it moves.
I care much less about personally writing or even reviewing every handler or migration than I do about the places where errors have nonlinear consequences:
Agents can do enormous amounts of work around those boundaries, but they should not own the consequences.
That distinction matters especially for internal software. The historical danger was never only that it cost too much to build.
It was that somebody built it, left, and five years later the company depended on a mysterious application nobody wanted to touch.
Cheap implementation does not fix bad ownership.
There are plenty of systems I have no interest in owning.
I do not want to operate an email service.
I do not want to build a payment processor.
I do not want to write an identity provider.
Vendor scale matters enormously. Mature products have years of edge cases, security work, and operational knowledge embedded in them.
Bespoke software makes the most sense when a few things are true at once:
The important part is not whether something can be built.
It is whether owning the project’s complexity is worth what you gain by owning the application-specific logic.
I still buy far more software than I would ever want to build.
But I no longer simply accept “there is already a service for that” as the end of the discussion.
Consider the progression: managed infrastructure reduced the operational floor. APIs made commodity capabilities composable. Coding agents are reducing both implementation and maintenance cost.
Meanwhile, SaaS has continued moving in the other direction: larger platforms, broader abstractions, more per-seat pricing, and increasingly complicated attempts to serve every possible customer from one product.
There is a point where adapting your organization to somebody else’s abstraction becomes more expensive than owning a smaller one.
Five years ago, building a narrow internal application instead of buying a mature SaaS product often looked irresponsible.
Increasingly, the irresponsible choice may be paying indefinitely for a generalized abstraction when the software you actually need is small enough to own.