Custom software development

Software is only worth what your teams can take over.

Parent division: Software and systems

The problem

The question is not package versus bespoke, but where the specificity actually sits.

Most organisations do not need entirely bespoke software. They need one precise part of their activity — the part that sets them apart, or the part no vendor covers — to be properly supported, with the rest resting on what already exists.

Bespoke development is justified when the process is genuinely particular to the organisation, when integration with what exists weighs more than the function itself, or when sovereignty over data and code rules out hosting outside the applicable framework.

In every other case it produces dependency. Software written with no architecture documentation, no test suite and no trained team belongs in practice to whoever wrote it, whatever intellectual property clause the contract carries.

What makes software recoverable, schematic

01Observation: The process as actually performed, not the one the documents describe.
02Released increment: Put into the hands of real users, rather than a single acceptance at the finish.
03Integration: Documented interfaces, agreed formats, explicit handling of errors and rejects.
04Cutover: Window, point of no return and rollback procedure, written before go-live.
05Test suite: Runnable by the client. It is what lets another team verify it has broken nothing.
06Repository and documentation: Code accessible from the first delivery, a rebuildable environment, architecture documentation.

Schematic. The accented path is reversibility, which is decided on day one and not on the way out.Typical delivery figures. Delivery cadence and coverage are targets; they are set at the first increment, not in the contract.

Scope

What the service covers

Framing: A survey of real processes rather than described ones, actors identified, arbitration between what is taken from an existing solution and what is built, and the scope of first release.
Design and development: Documented architecture, delivery in increments that are released and exercised, code review, automated test suites, and version control the client can access.
Integration: Documented interfaces with the systems in place, agreed exchange formats, explicit handling of errors and rejects, and logging of exchanges for reconciliation.
Data migration: Quality analysis of the existing data, written transformation rules, quantified consistency checks, and successive trial migrations before the final one.
Acceptance and go-live: Acceptance run by users on real cases, training, a planned cutover with a rollback procedure, and support through the first weeks.
Operation and handover: Hosting on the client’s or on sovereign infrastructure, monitoring, tested backups, operating documentation, team training and a progressive transfer of responsibility.

Situations

The most frequent situations

A process particular to the organisation: No vendor covers the process, or covers it at the price of an adaptation costlier than building. Bespoke is then the cheaper answer.
Integration across heterogeneous systems: Several systems each render a useful service but do not talk to one another. The work is interfaces and data consistency, not a rebuild.
Replacing an unmaintained tool: An internal tool works, nobody can change it any more, and its author has left the organisation. Recovery starts by reconstructing the business rules.
Sovereignty requirement: Data cannot leave a given legal framework. Development comes with controlled hosting and documented reversibility.

Requirements

What to require, of us as of anyone

These requirements hold whichever supplier is appointed. Written into a tender, they filter out the responses that will not hold.

Ownership of the source code and its actual handover to the client, from the first delivery rather than at the end.
Architecture and operating documentation produced as the project runs, not written after acceptance.
Automated test suites the client can run, which make a takeover by another team possible.
Intermediate releases put into the hands of real users, rather than a single acceptance at the finish.
Written migration rules and quantified consistency checks, before the cutover.
A reversibility clause stating what is handed over, in what format and within what time.
Training for in-house teams, with an explicit scope of autonomy at the end of the project.

Pitfalls

Common mistakes, and what they cost

Specifying before observing: The process described in the documents differs from the process performed. Software faithful to the document and foreign to practice is worked around from go-live.
Delivering once, at the end: The gap between need and product surfaces at acceptance, when it costs most to correct. Regular releases turn that gap into ordinary correction.
Treating data migration as a technical task: It is a business task: anomalies in the existing data must be arbitrated by those who produced them. Left to the provider alone, it produces arbitrary decisions discovered after the cutover.
Deferring operability to go-live: Monitoring, backups, logging and restoration procedures are designed with the application. Added afterwards they are incomplete, and the first incident is what reveals it.

Questions

Questions asked before consulting

How do you know bespoke development is justified?

By comparing the cost of adapting an existing solution with the cost of building, over the expected life rather than at purchase. Bespoke is justified when the process is genuinely particular to the organisation, when integration weighs more than the function, or when data sovereignty rules out hosting outside the applicable framework. Otherwise, adapting a package costs less.

Who owns the code produced?

The client, and the clause alone is not enough. Ownership is made real by a code repository the client can access from the first delivery, architecture documentation, runnable test suites and a reproducible build procedure. Without those four, ownership is formal and the dependency remains entire.

How long does a project like this take?

Duration depends less on the size of the software than on the availability of the people who know the process and on the state of the data to be migrated. A narrow scope released early and then extended reduces risk more than a long schedule run in one go.

How is the software integrated with existing systems?

Through documented interfaces, with agreed exchange formats and explicit handling of errors and rejects. What costs is not the nominal exchange but the exception cases, and the ability to reconcile the two systems when they diverge. That logging is designed in from the start.

What happens if we change provider?

Nothing, if reversibility was addressed during the project rather than at its end. It presupposes a current code repository, operating documentation, a rebuildable environment and test suites that let a new team verify it has broken nothing. It is a requirement to state on day one, because it changes how the work is built.

Should the application be hosted on the client’s own infrastructure?

The criteria are data sensitivity, the applicable legal framework and the organisation’s ability to operate infrastructure. Hosting on the client’s infrastructure keeps control and brings the operating burden with it; sovereign external hosting removes the operating burden while keeping the framework. Both are documented, including where the data physically sits.

Evidence

Where we have applied it

Government and public administration2023
Public administration — case-handling platform
Digitisation of a public-facing service, designed to remain usable on unstable connections and outside the capital.
Counters deployed
9
Months of programme
11
Reference KP-2023-005