Packaged software is designed for the average company in a category. That is a strength: it is cheaper, better tested, and supported by someone whose entire job is keeping it working. It becomes a problem when the way you win work, price it or deliver it is precisely the part that does not fit the average, and staff spend their week bending the tool around the business instead of the other way round.
Recognising the gap
- People maintain parallel spreadsheets because the system cannot hold the real process.
- Two or three tools each keep a different version of the same customer or product record.
- A role exists chiefly to move data between applications that ought to exchange it themselves.
- Staff describe routine work with phrases like 'then we do it the awkward way'.
- Reports have to be assembled by hand before anyone can make a decision from them.
One or two of those signs are survivable, and every growing business has at least one. When several appear together, the organisation is paying a coordination tax every week, and it rarely shows up as a line item anywhere. The useful question is not whether the workaround exists, but whether it is costing more attention than the difference it protects.
Custom does not mean building everything
The strongest programmes buy commodity capabilities and build only what differentiates. Accounting, payroll, email, identity and payment processing are solved problems, with regulatory weight and decades of hardening behind them. Your quoting logic, scheduling rules, quality checks or customer portal probably are not solved problems, and those are the parts where a tailored tool changes what the business can do.
That usually makes custom software smaller than people expect: a focused application that owns one workflow properly and integrates with the systems of record around it, rather than a monolith intended to replace them. Smaller scope also means shorter feedback loops, and feedback is what turns a first version into something people trust with real work.
Design around the work, not the org chart
Software specified from a management summary alone tends to encode assumptions nobody has tested. Observing people doing the job, in their own environment, surfaces the exceptions that decide whether a system is usable: the rush order, the partial shipment, the customer who is always invoiced differently, the check that must happen before anything ships. Those exceptions are the requirements, even when no document mentions them.
Model the domain in plain language first. If you cannot name the entities, their states and the transitions between them, the code will not clarify it for you. When that model is shared by the people doing the work and the people building the system, change requests get cheaper, because everyone is arguing about the same picture instead of describing the same problem in three vocabularies.
Costs that get forgotten
- Ongoing hosting, monitoring and dependency updates, which continue for as long as the software is used.
- Security patching and access reviews, especially once the application touches customer or payment data.
- Training, documentation and onboarding, repeated every time a new person joins the team.
- Code ownership: who can change it in two years if the original team has moved on.
- Deliberate decommissioning, because every system left running eventually becomes a liability.
Planning for those costs up front turns a build into an asset with a lifespan rather than a surprise with an invoice attached. A short written plan covering ownership, environment access, dependencies and support expectations is worth more than an extra feature, because it determines whether the software is still maintainable when the people who commissioned it have moved to other problems.
Build the parts that make you different, and buy the parts that make you the same as everyone else.
Start with the workflow that costs the most attention and has the clearest boundaries. Ship something small that people use daily, prove the reduction in manual handling, and extend from evidence rather than enthusiasm. Software that grows from a working loop tends to survive contact with a real business; software specified in one enormous document usually does not.
