Business software

Software is only worth what your teams can take over.

Divisions assembled: Software and systems

The issue

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

Few organisations need an entirely bespoke system. 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 is justified when the process is genuinely particular to the organisation, when integration with what exists weighs more than the function itself, or when data sovereignty rules out hosting outside the applicable framework.

Everywhere else it produces dependency. Software delivered with no architecture documentation, no runnable test suite and no trained team belongs in practice to whoever wrote it, whatever intellectual property clause the contract carries.

Where the specificity sits, schematic

01Process observed: As actually performed. Software faithful to the document and foreign to practice is worked around from go-live.
02Specific part: What sets the organisation apart, and what no vendor covers. That is what gets built.
03Common part: What rests on what already exists. Few organisations need an entirely bespoke system.
04Integration: Documented interfaces, agreed formats, logging that allows two diverging systems to be reconciled.
05Data migration: Anomalies in the existing data are arbitrated by those who produced them, never by the provider alone.
06Autonomy: An accessible repository, a rebuildable environment, runnable test suites, a trained team.

Schematic. The question is not package versus bespoke: it is where the specificity sits.Typical figure: the genuinely bespoke share of a business system once the common part is identified. It is measured at framing, and it almost always surprises.

Outcome

What you get

An application in service, whose code is handed over to you, whose environment rebuilds, whose test suites let another team verify it has broken nothing, and whose data is hosted where you decided.

Scope

What the solution includes

Framing: A survey of real processes rather than described ones, arbitration between what is taken from an existing solution and what is built, and the scope of first release.
Development: Documented architecture, incremental releases put into the hands of real users, 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 that allows two diverging systems to be reconciled.
Data migration: Quality analysis of the existing data, written transformation rules, quantified consistency checks, and successive trial migrations before the final one.
Reporting and decision: Indicators defined with those who decide, sources traced back to the originating data, and gaps and uncertainty shown rather than smoothed away.
Operation and handover: Hosting on the client’s or on sovereign infrastructure, monitoring, tested backups, operating documentation, training and a progressive transfer of responsibility.

Sequence

How it is run

01
Observation
The process is observed before it is specified. Software faithful to the document and foreign to practice is worked around from go-live.
02
First scope in service
A narrow scope is released early, then extended. That reduces risk more than a long schedule run in one go.
03
Migration and cutover
Anomalies in the existing data are arbitrated by those who produced them, never by the provider alone. The cutover is planned with its window and its rollback procedure.
04
Autonomy
Training, documentation, a current code repository and runnable test suites. The scope of autonomy is settled in writing at the end of the programme.

Commitments

What is verified at acceptance

These commitments can be held against us. Written into a tender, they filter out the responses that will not hold — including ours, if it does not hold them.

Code is handed over to the client from the first delivery, with a reproducible build procedure.
Architecture and operating documentation is produced as the project runs, never written after acceptance.
Automated test suites, runnable by the client, accompany every delivery.
Intermediate releases are put into the hands of real users, without waiting for a single acceptance.
Migration rules and consistency checks are written and quantified before the cutover.
Data location and the applicable legal framework are documented.
The reversibility clause states what is handed over, in what format and within what time.

Before committing

Questions to settle internally

An organisation that cannot answer these questions is not ready to launch the programme. Saying so is better than selling it a study.

Which part of the process genuinely sets you apart, and which is common to your sector?
Who knows the process as it is actually performed, and will they be available during the project?
What state is the data to be migrated in, and who will arbitrate its anomalies?
Which scope can go into service first without waiting for the rest?
Which in-house team will take over operations, and what autonomy does it need?
Where must the data reside, and for what reason?

Evidence

What we have delivered on this scope

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