Built to fit, not bent around: why bespoke software gets adopted
Watch a procurement team use a large purchasing suite for a morning and you will see two systems at work. One is on the main screen, with its approval chains and dropdowns. The other lives in a spreadsheet on the second monitor, where someone keeps the supplier notes, the real lead times and the list of vendors who always invoice twice. The suite is the system of record. The spreadsheet is the system of work.
Every organisation that has bought a big piece of software has some version of this. And most rollout plans treat the second monitor as a training problem. People weren't taught properly, so they cling to their spreadsheets; teach them better and the spreadsheet goes away.
It rarely does. The spreadsheet exists because the software asked people to work in a way the work doesn't go.
Resistance is usually a fitting problem
When a tool fails to take hold, the post-mortem tends to blame people. They are change-averse, attached to old ways, the champions didn't champion. Some of that is true; people are messy, and we have written plenty about how. But when you sit with the people who refused a tool, you usually find a perfectly sensible reason under the reluctance.
A support agent who keeps a private document of canned replies isn't sabotaging the helpdesk. The helpdesk's macros take six clicks and lose the formatting. A field engineer who phones the office instead of updating the job app isn't a dinosaur. The app needs a signal he doesn't have in half the basements he works in. Resistance, looked at closely, is often a detailed bug report delivered through behaviour instead of a ticket.
Bought software is built, by design, for the vendor's average customer. That is its strength: proven, maintained by someone else, cheaper per seat than anything you could write. It is also why it pinches. Your business is not the average of a vendor's customers. The places where you differ are exactly where your people have learned to do something clever, and those are the places a standard product flattens.
People adopt what they recognise
The best predictor of whether a new tool gets used is whether people recognise their own work in it. Not a tidied-up version of their work, not the version in the process manual, but the actual sequence of things they do, in the order they do them, including the odd exception they handle every Thursday.
Bespoke software can manage this because it is built after someone has watched the work. Before a line of code, someone sits with an account manager and notices that she checks the customer's payment history before every quote, from a different system. So the quote screen shows payment history. That is the whole trick. She opens the new tool and finds the thing she always looks for already there. There is nothing to resist, because nothing has been taken away.
Compare the usual alternative. The same account manager is told the new CRM "has everything she needs", spends a fortnight hunting for payment history, finds it three menus deep, and drifts back to her old method. Nobody would call that a failure of the CRM. It does what it says on the box. It just doesn't do what she does.
Recognising is not the same as copying, though. Some of what people do every day is a scar from the old software: the double entry, the manual check that exists only because the old system dropped records. Building those faithfully would be fit to the wrong thing. The skill is telling the judgement apart from the workaround, keeping the first and quietly deleting the second. People rarely mourn a workaround. They notice very fast when their judgement has been designed out.
Fit removes the argument instead of winning it
Most change management is an argument. You persuade, train, incentivise, measure logins and escalate. It is tiring for everyone, and it tends to produce compliance rather than conviction: people log in because a dashboard is watching, then keep the real work somewhere else.
Software that fits skips much of that argument. When a tool matches how people already work and takes away a chore they disliked, the case for it is made on the first morning. You don't have to convince a recruiter that she wants interview feedback gathered from the panel automatically instead of chasing four people by email. She has wanted that for years. You only have to build it so it collects feedback the way her panels actually give it, which is late, in fragments, and sometimes by voice note.
There is a quieter bonus. The IKEA effect describes how people value things more when they had a hand in making them. Software built with the team, its screens shaped by their walkthroughs and complaints, inherits some of that. People defend tools they helped design. They report bugs instead of working around them, and they explain the tool to new starters with a faint note of ownership.
Why fit got cheaper
For a long time the honest answer to "should we build our own?" was "only if you're very large or very unusual." Building was slow and expensive, and maintaining it was worse. Buying was the sensible default, and the price of buying was a certain amount of bending.
AI-assisted development has moved that line, as we argued in the end of "buy, don't build". Small, well-scoped tools that once needed a team for a quarter can now be shipped by a small team in weeks. That doesn't make every build wise. It does mean the cost of fit has fallen faster than the cost of misfit, and misfit was always dearer than it looked, because it is paid in workarounds, re-keying and second monitors rather than on an invoice anyone reads.
The calculation also changes over time. A bought product drifts away from you as your business changes, because its roadmap follows the vendor's whole customer base. A bespoke tool can follow you, because the people who change it are a conversation away rather than a support ticket away.
Start where the bending is worst
None of this is an argument for ripping out what you have. Big rewrites fail for good reasons, and the commodity parts of a business, the ledger and payroll among them, are usually best left on standard products. Being identical to everyone else there is a feature.
The useful move is narrower. Find the places where your people bend furthest around the software: the exports, the side spreadsheets, the handovers between departments that happen by email. A small bespoke tool in one of those gaps gets adopted with almost no effort, because it replaces a workaround people already resent. That is where our Built to Fit programme starts, with a stage called Edges that builds only where the suite never reached, reading from it but not yet writing to it, so nothing can break while the team gets used to software that fits.
From there it grows in steps. Edge tools become layers where the daily work happens; later, and only where it earns its keep, a core module retires. Each step works because the one before it was adopted, and it was adopted because it fit.
If you want a quick way to find your first candidate, walk the floor and count second monitors. Wherever a spreadsheet sits open next to the official system, someone has already designed the software you should build. They just did it in cells.
