The software that stayed on the shelf.
Every organisation has a wish list of software that never got built: too expensive, too slow or too risky, so it became a package. Those sums were made with pre-AI numbers. Time to make them again. If the package still wins, we will say so.
AI made building software cheaper. It did not make it safer, and that is where the real work is.
Every build-or-buy decision weighs two things: cost and risk. Everyone is talking about cost. It has genuinely moved, enough that a system you once shelved as too big is worth a fresh look. Risk has not moved at all. Business software still fails in the same ways it did in 2006, and an AI agent writing at machine speed simply produces more of it, with the same weak spots.
So the line between “we’ll buy something” and “we’ll build our own” has moved, and hardly anyone has redrawn it. Keeping the risk under control is the part you hire us for.
What got cheaper. And what did not.
It is worth being specific here, because the difference decides whether building is now a good idea or just a cheaper way to fail.
- The groundwork (endpoints, validation, mappers, forms): the CRUD around the interesting part.
- The second and third screens that resemble the first.
- Tests, and therefore the confidence to change something later.
- Migrations, import scripts, and the adapters between systems that will keep speaking different languages.
- Deciding what the thing actually is. No model knows your business rules are contradictory.
- The data model, which outlives every rewrite and every framework you will pick.
- Knowing which failure modes matter here. Being wrong is expensive in different ways in rail and in healthcare.
- Whether anyone will use it. Still a common way software fails.
If a project only makes sense because the easy part got cheaper, it never made sense in the first place.
The comparison that usually stops at year one.
A licence is easy to compare and a build is hard, so the comparison usually stops where the licence is cheapest. Here is the whole table, including the row that argues against us.
| A standard package | Your own | |
|---|---|---|
| Year one | Licence, implementation partner, integration, data migration. Largely known in advance, which is why it feels safe. | Build cost, mostly people. Known once the scope is written, which is the whole reason the Factory Sprint exists. |
| Year five | The licence is still running and has grown with your headcount. What you built on top came with its own bill. | No licence. You pay for the changes you ask for, and for keeping it alive. That is a real bill, not zero. |
| Fit | You change how you work to match the software. Sometimes that is an upgrade; often it is a quiet tax on every person, every day. | The software matches the way you already decided is right. If that way is not actually better, this is a waste of money. |
| The part that does not fit | Customisation you maintain forever, in someone else's extension model, that you hold your breath over at every upgrade. | It is just code, in the same repository, behind the same tests as the rest. |
| A change you want next quarter | A request in a roadmap you do not control, competing with every other customer's request. | A sprint in a roadmap you do control. The constraint becomes your own capacity, which is at least yours to change. |
| Getting out | A migration project, on their export format, on their timeline. | You already have the source, and because it is built on our open-source foundation, leaving is a decision, not a negotiation. |
| Who decides what it does next | The vendor, guided by their largest customers and their own strategy. That is reasonable, but their priorities follow their whole customer base, not you. | You. That is only an advantage if someone in your organisation wants the job. |
| Risk, honestly | Proven software, unproven fit. Thousands of companies run it; that says little about whether it fits yours. | Proven fit, software you have to keep proving. That is the trade, and it is the reason our gates and our guarantee are on this site at all. |
The worksheet. The table above as a sheet to fill in with your own licence figures. Ask for it through the form, or just give us a call.
Three cases where building won- HealthcarePameijer A digital workplace for care workers who are mostly on the road: one dashboard, on every device, with the client file and the other systems in one view.
- ParkingP1 A webshop for on-street parking permits that handles every municipality’s own rules and exceptions, and now serves a growing number of municipalities.
- IndustryBadotherm Basecal and Thermocal, calculation tools for pressure and temperature meters in the chemical industry: mathematics and software in one, and now indispensable to the company.
Four things that were too expensive to build, and are worth it now.
These are the situations we hear about most often in first conversations.
The spreadsheet a department runs on
A whole department, one workbook with macros, one person who understands it and is going to retire. It always seemed too small to justify a project. Now it isn’t, and the risk of leaving it alone has been growing the whole time.
Tell us about yours 02The customer-facing half of a package
Keep the package for what it is good at. Build the part your customers actually see, where being generic costs you the relationship and the vendor will not let you change the screen.
Tell us about yours 03The layer between two systems that stay separate
After an acquisition, or after years of drifting apart. Integration work used to be the least rewarding thing to pay for. It has become far cheaper, and it is what makes the rest usable.
Tell us about yours 04The product you keep talking about
Costed once, shelved, and still priced at pre-AI rates in your head. The market moved and so did the price. Worth recalculating.
Tell us about yours“So should we build our own ERP?” Usually one part of it.
It is the first question people ask, because that is where the biggest invoice is. It is also where we usually talk you out of it, and here is why.
Rarely
The general ledger, the tax rules, the statutory reporting, the payroll. The rules change every year and somebody else is paid full-time to follow them. Building that yourself means hiring the people who track legislation, forever. Buy it, and be glad it is boring.
Often
Planning, the shop floor, the field app, the customer portal, the reports it will not give you, the workflow four departments have built a shadow process around. Keep the ledger. Build the layer your people work in all day. That is a project with a beginning and an end, and it is where nearly all the pain actually is.
Custom software, and when a package wins.
In these four cases we will advise you to buy, and we say so in the first conversation, even if it costs us the work.
That conversation is short.
Skip the study. Start with one working slice.
A feasibility study tells you what someone expects. Six weeks of building tells you what is true here: in your repository, on your pipeline, against your data, with your product owner deciding whether the scope was met.
Show us what stayed on the shelf.
The project that was shelved on cost and risk. Tell us what it was and roughly when you last priced it, and you get an honest answer about whether the numbers have moved far enough.
A first conversation with an engineer, no obligation