Custom Software Development Services

Packaged software is the right answer far more often than vendors admit. Custom work earns its place when the process itself is the advantage.

Custom software development is the practice of building an application around an organisation’s existing process rather than changing the process to fit a licensed product. That is the whole distinction, and it is also the whole risk: a custom system inherits every assumption nobody wrote down, so the work is mostly about surfacing those assumptions before they are encoded.

When a custom build is the wrong answer

There are four situations where we will say so rather than quote.

The first is when the process you are protecting is not actually differentiated. Payroll, general ledger, email marketing and helpdesk ticketing are solved problems with mature products. If your objection to the packaged tool is that it names a field differently, you are buying a maintenance liability to avoid a training session.

The second is when nobody internally can decide. A custom build converts opinions into schema. If three people give three answers about how a discount is approved, the build will stop on that question at some point, and the cost of stopping is real. Settle it first, on paper, in the existing tools.

The third is when the honest requirement is reporting. A surprising share of “we need a system” conversations end with the realisation that the operational data is already being captured correctly and simply cannot be read. That is a warehouse and a few dashboards, not an application, and it is an order of magnitude cheaper.

The fourth is when the timeline is shorter than the decision-making. Software can be built quickly. Agreement cannot be compressed the same way, and a build that outruns its own decisions produces screens nobody will use.

What the first two weeks actually produce

Discovery here is not a workshop that produces a slide deck. It produces three artefacts: the documents the business already generates by hand, a data model, and a written list of what is deliberately out of scope.

The documents come first because they are the most reliable specification available. On a quoting build for a bespoke fabricator, asking for three of the customer’s own real quotations — a long priced one running past sixty line items, a bill of quantities carrying no prices at all, and a short two-page quote — answered questions that a requirements call had left ambiguous, and settled two live arguments about tax treatment. A conversation produces what people remember about their process. A document produces what their process actually does.

Read the outputs the business already produces before designing the outputs you intend to replace them with. The same audit of a fabricator’s pricing workbook found twelve formulas that were referenced by other cells and had never been written — a gap a person had been silently covering for years, and one that no amount of describing the process aloud would have revealed.

How a fixed scope is agreed, and what happens when it changes

An estimate is built by decomposing the scope into things that can be individually demonstrated — a screen, an endpoint, a report, a migration — and pricing those, not by applying a multiplier to a feature list. Where a line cannot be estimated confidently, it is called out as unestimated rather than padded, because padding hides exactly the items that need a conversation.

Scope changes are expected and handled by exchange rather than by argument. New work is priced, and it either extends the engagement or displaces something of comparable size that has not started yet. What we do not do is absorb changes quietly, because absorbed changes are how a delivery date moves without anyone being told.

One discipline is worth stating because it costs money when it is missing. A backlog is a description of the system, and descriptions go stale faster than code. On one project a gap register listed an offline sync layer as an entire module not built. It existed — local database, mutation queue, conflict classification, unsynced-writes screen, all working — and two rounds of work had already been commissioned against that entry before anyone checked. Over the life of that project the register was found materially wrong six times. Now, anything the backlog claims is missing gets verified against the running system before it is scheduled.

Which decisions are expensive to reverse

Most of a system can be changed cheaply later. A small number of decisions cannot, and those are made carefully in the first fortnight regardless of how tight the timeline is: how records relate to each other, how tenants or branches are separated, how identity and permissions work, and how anything financial is recorded.

Permissions in particular are worth over-specifying, because they fail in a direction that is invisible. A permission model enforced at the data-access layer can be entirely correct and still be walked past by an export endpoint that builds its own query — which is how a branch-scoped user ends up able to download the whole organisation’s customers, orders and payments as a CSV. Every read path has to be covered, not just the ones the framework happens to route through.

Money is the other one. Amounts stored as floating point, or totals stored without the working that produced them, produce disagreements that surface months later in the accounts and cannot be reconstructed. Store the inputs and the rule, not only the answer, and keep the precision of a rate separate from the precision of an amount.

Where a record has to be trustworthy rather than merely correct, the guarantee belongs in the database. On a compliance system we build, the audit log is hash-chained — each row carries the hash of the one before it — and a trigger refuses updates and deletes outright, so the table is append-only as a property of the schema rather than as a convention the application is trusted to follow. Conventions survive exactly as long as the person who knows about them.

What working software in increments has to mean

An increment counts when someone outside the delivery team can use it against real data. A demo of screens wired to fixtures is not an increment; it is a picture of one.

That standard has consequences for how the work is verified. The same end-to-end suite runs before a push and again after a deploy, pointed at a different host, so there is no second set of post-deploy checks quietly drifting away from the first. Deployment steps live in the repository rather than on the machine — a configuration file your deploy does not install is documentation, not configuration — and a deploy that cannot complete a required step fails the run instead of printing a warning and reporting success. Every one of those rules exists because its absence cost us something on a real system.

The tooling gets the same scepticism as the code. An audit script we wrote for our own site reported confidently on the wrong site for a while, because the port it assumed was already serving another project; it now binds an unused port and refuses to run unless the homepage proves it is the site under test. Its first complete run produced two hundred and seventeen findings of which a hundred and thirty-four were false. A tool that has not been checked against a known answer is a source of opinions, not evidence — which is the same reason a green test you have never seen fail is not a passing test.

What you own at the end

Source, database schema and migrations, infrastructure definitions, the test suite, the deployment scripts and the runbook. All of it in your repository and your accounts, from the first commit rather than at handover, which is the only version of code ownership that means anything.

In practice that means specific files, not a promise. The web server’s virtual host for your domain and the service unit that keeps the application running are checked in, not typed onto a box. Staging and production have separate deploy scripts, and applying migrations is a scripted step rather than something someone remembers to do. The environment templates are versioned with the code that reads them.

The test of a handover is not whether documents were delivered. It is whether a team that has never met us can stand the system up from the repository, run the tests, deploy a change and know what to do when it pages at three in the morning. Anything that exists only on a server, or only in someone’s head, fails that test — so after any fix applied directly to a machine, the question asked is what would be lost if that machine were rebuilt tomorrow.

Handover documents are written to be checkable rather than reassuring. One of ours records, of a mobile release, that the production API host was confirmed by reading the shipped bundle and finding the local development port appearing zero times in it — because that, and not a green build log, is the only real evidence the development branch was compiled out. A handover note that cannot be disproved is not telling you anything.

There is no proprietary framework here that you would need us to maintain. The stacks are the ordinary ones — Node, Python, Angular, React, React Native, Postgres — for the unglamorous reason that you can hire for them without us.

Who is actually doing the work

The same engineers build and run our own products, which is a different relationship to production than agency work usually creates. Seven of them are in the portfolio at different stages: AdBoard and Rentals live with operators, Quote live with a reference customer, Factory in production in cold-press oil manufacturing, Field in user acceptance testing, Comply in build, Engage pre-launch. Nobody on this side gets to hand over a system and stop hearing about it.

AI is used in the delivery loop and the review standard does not change to accommodate it. It earns its place on scaffolding, on tests you would otherwise skip, on mechanical migrations and on reading unfamiliar code. It is not trusted on domain correctness, on architecture with real trade-offs, or on anything where looking right and being right diverge. A person reviews and is accountable for every line that ships, however it was produced.