There is a point in the life of almost every growing business where the software that used to work quietly starts to become a full-time management problem. Nobody announces it. It happens gradually: a spreadsheet to handle the exception the CRM can't manage, a shared inbox that tracks things the system should be tracking, a manual export every Monday morning because the two platforms can't talk to each other.
These workarounds are rarely seen as a software problem. They are seen as a process problem, a staffing problem, or simply the way things are done here. But when the workaround becomes the workflow, it is usually a sign that the underlying system stopped fitting the business some time ago.
What "off the shelf" is designed for
Packaged software is built for the median business in a given category. A standard CRM suits a standard sales process. A standard project management tool suits a standard project structure. That is not a criticism — it is what makes packaged software commercially viable and quick to deploy.
The problem is that specialist businesses are not median businesses. A construction contractor managing multi-stage projects with subcontractor compliance requirements does not have a standard project structure. A manufacturer tracking component batches across several production lines does not have a standard inventory problem. When you force a specific operational reality into a generic system, something has to give — and it is usually your staff's time.
Five signs you have outgrown a packaged solution
1. Your team maintains a parallel system
If people are keeping a spreadsheet alongside the official system — to track the things the system can't track, to present data in a format the system can't produce, or simply because it's faster — the official system is not doing its job.
2. Onboarding new staff means teaching the workarounds
When training a new employee involves explaining not just how the software works but why you do certain things outside of it, you have embedded the workaround into your operations. That knowledge is now a dependency, not a habit.
3. You are hitting licence ceilings or artificial limits
Many SaaS products charge per seat, per transaction, per API call, or per storage band. When those limits start to bite — and they are usually designed to bite at the point where you are growing fastest — you are paying for the privilege of outgrowing the system.
4. You cannot get the reports you actually need
Reporting is often the first place a mismatch shows up. If the data is theoretically in the system but getting it out requires an export, manual reformatting, and a pivot table, the system is not serving the decision-making needs of the business.
5. Integrations are fragile or missing
Most modern packaged software integrates with other popular software — but not necessarily with your other software. When connections are maintained through Zapier automations or manual CSV transfers, they are fragile. When they break, someone notices too late.
The moment to consider bespoke
The right moment to consider a bespoke system is not when the current one has completely broken down. By then the cost of switching has become enormous and the pain of staying has become normalised. The right moment is when the cumulative overhead of maintaining workarounds starts to outweigh the disruption of changing approach.
That calculation looks different for every business. For some, it happens when headcount crosses a threshold and the manual processes that worked for a team of six cannot scale to twenty. For others, it happens when a contract is won that the current systems genuinely cannot support. For others still, it is a quiet recognition that the business has become operationally dependent on a supplier it cannot influence.
What bespoke software is not
Bespoke software is not a vanity project or a statement that your business is too good for off-the-shelf products. It is a practical decision made when the specific requirements of an operation cannot be met efficiently by a general-purpose product — and when the long-term cost of the mismatch exceeds the cost of building the right thing.
It is also not a permanent commitment to building everything from scratch. Many of the best bespoke systems integrate sensibly with packaged products where those products genuinely work. The goal is operational fit, not ideological purity.
Starting the conversation
The most useful starting point is not a list of features you want. It is an honest description of the process that is currently broken, the data you are not getting, and the decisions you are not able to make quickly enough. From that, a good development partner can help you work out whether bespoke is the right answer — and what a proportionate version of it looks like.
If any of the signs above are familiar, it may be worth having that conversation before the workarounds become any more entrenched.