Custom software development for the workflow no product quite fits

The question that comes before the quote

Every custom software brief should start with a subtraction. Authentication, payments, email delivery, file storage, scheduling and reporting are solved problems with products behind them. What is left after you take those out is usually one screen, one rule set and one scheduled job, and that is the thing worth building.

Buy, build, or stop

The first deliverable on a software engagement is a written split of the process into three columns: what an existing product already does well enough, what genuinely has to be built because the rule is yours, and what should simply stop being done because nobody can say why it happens. The third column is often the cheapest win in the project.

How the work lands

Fortnightly increments on a staging environment you can open at any time. Automated tests go on the parts where being wrong costs money, the calculations, the permissions, the invoicing, rather than chasing a coverage number. Each release is accompanied by a note on what changed and what to look at.

What you are left holding

The repository with its full history, the infrastructure accounts, the keys, and a written handover: architecture, environment variables, deployment steps and how to run it locally. The test of a good handover is whether a developer who has never met us can take it over, and that is what the documentation is written against.

The honest caveat

Custom software is a standing commitment: hosting, dependency updates, security patches and occasional fixes do not stop when the invoice is paid. If nobody in the business is going to own that, we will recommend a product instead, and where a build genuinely is the right answer, the support window is agreed in writing before the first line is written.

The question to settle before any software is written

Almost every request that arrives described as custom software contains three different things: a process an existing tool already performs, an integration between two systems that both have APIs, and a small amount of logic that is genuinely specific to this business. Only the third is worth writing.

Separating them is the first deliverable, not a preliminary. It is written down, it is costed, and it is frequently the point at which a six-figure idea becomes a configuration job and a fortnight of integration work.

Custom software, in practice

• A written buy-versus-build split before anyone estimates a line of code
• Integration boundaries defined first, because that is where builds overrun
• Deployment, backup and rollback scoped as part of the build rather than after it

The website development page covers the cases where a site is the answer instead, and web development services compares the two honestly.

How this work usually starts

Software work starts with the split and the boundaries, and the honest version of that conversation sometimes ends the project. A recommendation not to build is a cheaper outcome than a build that duplicates a tool already paid for, and it is the one we will make when it is true.

Two documents keep a build honest: the buy-versus-build split and the integration boundary list. Both exist to make the expensive parts visible before anybody commits to a date, which is the only point at which a date is worth committing to.