Custom software

Software built around the business, not the other way around

Off-the-shelf software works until your business stops behaving like everybody else's. At that point the compromises start costing more than the licence, and the workflow quietly reshapes itself around the limitations of the tool. That is usually the moment to build.

Talk about the problem See what we've built

StrategizeBuildAutomateRun

The short answer

When should a company build custom software?

When the workflow is genuinely specific to the business and no product matches it without heavy adaptation; when people are maintaining spreadsheets alongside the system of record; or when the process is a competitive advantage worth protecting rather than standardising. If none of those hold, buying is usually cheaper and faster.

How it works

Software should follow the workflow

The workflow should not be redesigned to satisfy the limitations of the software. That happens more often than anyone admits — a process gets bent to fit a product, staff invent a spreadsheet to hold the difference, and two years later nobody can explain why the business works the way it does.

Illustrative. We build the layer the product cannot hold — not a replacement for the parts it handles well.

Capabilities

What this covers

Ten things, each of which exists because it removes a specific piece of risk or repeated work.

Custom business applications

Systems built for one operation: its rules, its exceptions, its approvals, its reporting.

Customer and partner portals

Self-service for the things customers currently phone or email about — orders, documents, account state, requests.

CRM systems

When the pipeline does not look like a standard sales funnel and the off-the-shelf CRM keeps losing the parts that matter.

ERP workflows

The operational layer around an ERP: the approvals, the exceptions and the reporting the core product was never going to cover.

Ecommerce platforms

Commerce with real operational complexity behind it — collection windows, stock across locations, account pricing, fulfilment rules.

Operational and internal systems

The tools staff use all day. Unglamorous, and usually where the largest time savings sit.

System integrations and APIs

Making existing systems exchange data reliably, including what happens when one of them is down.

Legacy modernization

Replacing what has to be replaced and leaving alone what still works, without a two-year freeze on everything else.

Data applications and dashboards

Reporting built on a definition of the numbers that everybody agrees with before the chart is drawn.

Mobile applications

Where the work genuinely happens away from a desk, rather than because a phone app was assumed.

How we work

Four things that happen before anything is committed

01
We map the workflow before scoping the build
Including the exceptions. The exceptions are where custom software earns its cost, and where estimates usually go wrong.
02
We agree what the system will not do
A bounded first version that reaches production beats a complete one that does not. What is deliberately excluded gets written down.
03
We build against real data
Test data hides the problems: the duplicate records, the fields used for something other than their name, the ten-year-old rows nobody wants to talk about.
04
We plan the handover from the first week
Who owns it, how it is deployed, what happens when it breaks at 2am. Decided during the build, not after go-live.

Where we stop

What we will not do

A supplier who never says no is only ever selling. Each of these has cost us work, which is rather the point of writing them down.

We do not customise software for the sake of customisation.
We do not rebuild a working system because its stack is unfashionable.
We do not quote a fixed price on a scope nobody has mapped yet.

Where this connects

One capability rarely arrives on its own

Strategize

Technology strategy

It works out what the business needs technology to do, then decides how to get there: build something new, buy an exis...

Managed technology

Keeping a production system healthy after launch: monitoring and alerting, patching and dependency updates, backup and...

Custom AI Systems

Some operations do not fit a category. Multi-party approvals, deadline-bound fulfilment, regulated handoffs, decades o...

Ecommerce Automation

Order status, returns, refunds, “has it shipped”, “can I change the address”. The volume is predictable, the answers l...

Before you talk to anyone

Work out the numbers yourself

Every model is published on the page. Several will tell you the work is not worth doing.

Project Cost EstimatorA range based on scope, integrations and complexity.Build vs Buy CalculatorSettle the question before scoping a build.Manual Process Cost CalculatorWhat the current way of working costs in a year.

FAQ

Questions we get asked

It depends almost entirely on how many exceptions the workflow contains and how reachable the existing systems are. A single well-bounded internal system typically runs from the low tens of thousands; a platform with integrations, roles and money movement is a different order of cost. The honest answer needs the workflow mapped first, which is why we scope before quoting.

Configuration bends your process toward the product. Custom software bends the software toward your process. Configuration is cheaper and faster and is the right answer most of the time. It stops being the right answer when the configuration itself becomes a system nobody can maintain.

You own everything built for you, with the repository, the deployment configuration and documentation written for someone who was not on the project. That holds whether or not you keep us on afterwards.

Yes. That is common where a team is strong but stretched, or where a specific piece — an integration, a migration, a platform rebuild — needs people who have done it before.

Then that is the first piece of work, and it is a strategy question rather than an engineering one. It is a short engagement, and it sometimes ends with us recommending a product we do not sell.

For a bounded internal system, six to twelve weeks to production. For a platform replacing something operationally critical, longer, and it should be staged so parts of it are live and useful before the whole thing is finished.

Describe the workflow

Tell us what your people do by hand. We will tell you what is worth building, what is not, and roughly what it takes.