Custom Software Development

Software built around the way your business actually operates.

Off-the-shelf software asks your business to change shape. Sometimes that trade is worth making. When it is not — when the process is the thing you are good at — the software should be built around the process instead.

What we start from

The real process, workarounds included. Every workaround is a requirement somebody has already written for you, in the most reliable format there is.

Why operational software fails

Most internal systems fail for the same reason: they model an idealised process rather than the real one. The version in the requirements document is the version nobody follows, so the software is fought from the first week and abandoned by the second quarter.

We start from the actual sequence — including the spreadsheet on someone's desktop that quietly holds state nothing else knows about — and build something people do not have to work around.

The data model is the decision

Screens are cheap to change. The data model is not. Getting the entities, their relationships and their history right is what decides whether a system absorbs the next three things you ask of it or has to be rewritten to accept them.

That is why the model is settled before the interface, and why we push back on features that would force the wrong shape into it — even attractive ones.

API and system integration

Very little operational software stands alone. It has to read from and write to accounting, CRM, payroll, warehousing or whatever else holds the truth for its part of the business.

Integration is where the hidden cost lives: rate limits, partial failures, and two systems that disagree about the same record. We write the conflict rules down rather than leaving them to whoever notices first, make the sync observable, and make every transfer safe to re-run.

In practice

Most operational software fails because it models an idealised process rather than the real one. We start from what people actually do — including the workarounds — and build something they don't have to fight.

What a build includes

  • Process mapping
  • Data modelling
  • Role-based access
  • Migration from spreadsheets
  • Handover documentation
Our position

What you own at the end

Ownership is a deliverable, not a sentiment.

  • The code and its history

    Yours, in your repository. You can take it to another team without asking us for anything, and without a conversation about it.

  • The infrastructure and credentials

    It runs in your accounts. We do not hold a system hostage through hosting we control.

  • Documentation for the next engineer

    Written for whoever inherits the system, not for whoever approves the invoice. Those are different documents.

Outgrown the spreadsheets?

Describe the process and where it breaks. We will tell you what the system looks like and what it would take.