Skip to content
Brain Matrix
Book a call

Problem 02 — Poor fit

Your software no longer fits how the business actually works

When the tool dictates the process instead of supporting it, you pay for the mismatch every day — in workarounds, in reconciliation, and in the things you have stopped trying to do. We build systems shaped around your operation, and we will tell you when buying is the better answer.

Symptoms we hear

  • A critical process lives in a spreadsheet nobody may touch
  • Your team maintains workarounds for the software
  • Two systems disagree and a human reconciles them
  • You have been told your requirement is not possible

The problem

The problem, stated plainly

There is a version of this that is nobody's fault: you chose good software for the business you were, and you are now a different business. The product has not got worse. The fit has.

The tell is not usually a complaint about the software. It is the quiet accumulation of workarounds around it — the parallel spreadsheet, the naming convention that encodes something the system cannot store, the weekly export that exists because two systems disagree. Each one is individually reasonable. Together they are a system nobody designed and nobody owns.

  • A critical process lives in a spreadsheet nobody is allowed to touch
  • Your team maintains workarounds for the software
  • Two systems disagree and a person reconciles them
  • You have been told your requirement is not possible
  • Reporting requires exports and manual joining
  • New hires need weeks to learn the unwritten rules

Root cause

Why this happens

Understanding why a problem exists is what separates a solution from a workaround.

  1. 01

    You outgrew the assumptions, not the software

    Every product encodes assumptions about how its users work. Those assumptions were true for you once. Growth, a new market or a new model quietly invalidates them, and the product cannot tell you that has happened.

  2. 02

    The workarounds hid the problem

    Competent teams route around limitations, which is exactly why the limitation never surfaces as a decision. The cost is real but distributed, so it never appears on a single budget line where anyone would notice it.

  3. 03

    Configuration ran out before requirements did

    Most products are flexible up to a point and then rigid. Once you are extending through custom fields, hidden columns and conventions, you have already built a bespoke system — just without design, documentation or tests.

  4. 04

    Nobody wants to own a replacement

    Replacing a working-but-poor-fit system is a large, unglamorous, risky project. It is easier to defer, and deferring is usually rational right up until the point it is clearly not.

Possible solutions

The options actually available

Custom software is one of five answers here, and it is not the most common one. It is worth being explicit about the alternatives before committing.

Reconfigure what you have

When it fits

The product can do it, and nobody has had the time or knowledge to make it.

What to watch

This is genuinely the cheapest answer when it is available. It is also the one people skip because it feels insufficiently decisive.

Replace with a better-fitting product

When it fits

Standard processes where a more suitable product exists, and migration is tractable.

What to watch

Migration cost and data export terms. Check what leaving looks like before you sign the next contract, because the answer at renewal will be worse.

A thin custom layer over existing systems

When it fits

The systems of record are fine; the workflow, orchestration and interface are the problem.

What to watch

Layers that stop being thin. Review the decision annually — some layers earn the right to become the system, and others should have been folded back in.

Custom software for the differentiating part only

When it fits

One process is genuinely where you beat competitors, and the rest is standard.

What to watch

Scope creep into the standard parts. The discipline is in keeping the custom footprint small deliberately.

A full custom system

When it fits

Unusual workflows, wide integration surface, meaningful scale, and funded ownership.

What to watch

Ownership cost. Budget 15 to 25 per cent of the build per year, or you are creating the legacy problem you will pay someone to fix later.

Our approach

How we approach it

Custom software fails for predictable reasons. Most of them are decided in the first three weeks.

  1. 01

    Watch the work before specifying it

    We sit with the people doing the process, including the parts they do not think are worth mentioning. The undocumented exception handled by one person is usually the requirement that decides the data model.

  2. 02

    Argue about the data model early

    Nearly every expensive change in a young system is a data model change discovered late. A week of disagreement about entities, ownership and permissions before anything is built is the highest-return week in the project.

  3. 03

    Integrate rather than absorb

    Systems that work should keep working. We define explicit integration contracts so a vendor's change cannot silently break you, and so the custom footprint stays as small as the problem allows.

  4. 04

    Ship a usable slice early

    One real user group, doing real work, within weeks. Feedback from use is worth more than feedback from demos, and it arrives early enough to still be actionable.

  5. 05

    Hand it over properly

    Documentation, tests, runbooks and a named internal owner. We would rather build something your team can run than something that requires us indefinitely.

Technical capability

What we actually build with

Listed so a technical evaluator can judge us on specifics rather than adjectives.

Application engineering

  • Web applications and internal tools
  • Domain modelling and business rules
  • Role-based access and permissions
  • Reporting and operational dashboards
  • Document generation and workflow

Data & architecture

  • Relational data modelling
  • Event sourcing where it earns its cost
  • Migration from spreadsheets and legacy stores
  • Reconciliation and data quality tooling
  • Search and reporting stores

Integration

  • ERP, CRM and finance system integration
  • Payment and billing platforms
  • Third-party APIs and webhooks
  • Adapters for closed systems
  • Scheduled and file-based exchange

Delivery & operations

  • Automated testing and CI
  • Infrastructure as code
  • Observability and alerting
  • Backup, recovery and audit
  • Documentation and handover

Qualification

Whether this is for you

We would rather lose a project than take one that should not exist.

This works well when

  • A process that is genuinely specific to how you operate
  • Willingness to fund ownership after launch
  • An internal decision-maker who can settle disagreements
  • A first user group who will actually use an early release

We are the wrong choice when

  • A requirement that an existing product already meets
  • No budget beyond the initial build
  • A specification written without watching the work
  • A deadline that only allows building it once, quickly

Relevant work

What this looks like in practice

Travel & hospitality2025Anonymised

A partner network that provisions itself

Partner growth was limited by how fast one person could configure a partner.

Onboarding each new partner meant a week of manual configuration: pages, pricing, tracking links and commission rules. We replaced it with a generator, and made commission calculation something the business could audit rather than trust.

  • PHP
  • WordPress
  • REST APIs
  • Airtable
  • SFTP deployment

Brain Matrix Labs — free tool

Should you build custom software?

Seven questions, a recommendation, and the case against it.

Open the tool

Questions

What clients ask us

How do we know custom is the right answer?

Three questions decide most cases: is the process a differentiator, how many systems must it work with, and can you fund ownership. Our build-versus-buy tool walks through all seven questions we would ask, gives a recommendation, and states the strongest argument against it. Roughly half its outcomes recommend buying.

Who owns the code?

You do — the code, the infrastructure, the accounts and the documentation. We do not retain licence over what we build for you, and we do not host it in a way that makes leaving difficult. If we were the wrong choice, we would rather you were able to act on that.

What happens if we want to bring it in-house later?

That is a normal and healthy outcome, and we plan for it. Conventional stacks, tests, documentation and runbooks exist so that a competent engineer can pick the system up. We have no interest in being a dependency you cannot remove.

Can you work with our existing team?

Yes, and it is often the better arrangement. We can lead the architecture and hard parts while your team builds alongside, which transfers knowledge as the work happens rather than in a handover document at the end.

How do you keep the scope from expanding?

By writing down what is explicitly not in the first phase, and by shipping something usable early enough that priorities get tested against reality. Scope grows fastest on projects where nothing is in users' hands yet, because every idea still sounds equally important.

What does it cost to keep running?

As a planning figure, 15 to 25 per cent of the original build per year covers hosting, dependency and security updates, support and small changes. We would rather discuss that number before a build than after one.

Further reading

On this topic

Technology Strategy4 min read

How to choose a software development partner

Portfolios and day rates tell you almost nothing. Six questions that reveal how a partner actually works, the answers worth trusting, and the four engagement shapes with their honest failure modes.

Custom Software5 min read

Custom software vs SaaS: the three questions that actually decide it

Most build-versus-buy debates argue about features. Features are the least predictive input. Here are the three questions that decide the answer in practice, and the arithmetic most teams leave out.

Solutions

Other problems we solve

Next step

Let's talk about what's holding your business back.

A 45-minute conversation with a senior engineer. We will look at your situation, say what we would do, and tell you if the answer is not software. No pitch deck, no pressure.

Book a strategy callExplore the Labs tools