Software engineering · Systems · Integration

Bespoke software development that ends with the source in your hands.

Business systems, portals, integrations and legacy replacement, built around one organisation's process rather than a product's. Discovery produces a written scope you own before anyone writes code, and handover gives you the source, the documentation and the environments.

Talk to a technical director See AI digital workers

Talk to MSD

named process per first engagement

directors on every engagement

day rates — a fixed price against a written scope

What people bring us

Six shapes of problem that end in a bespoke build.

If your situation is not one of these, we say so and point you somewhere better.

01 PROBLEM 01

Nobody has written the scope down

The requirement lives in a handful of heads and a long email thread. Discovery turns it into a document you own, whoever ends up building it.

02 PROBLEM 02

The last developer left with the knowledge

The system still runs the business and nobody can change it. The first job is reading what exists and writing down how it behaves.

03 PROBLEM 03

Two products nearly fit

Each product covers most of the process and neither covers the part that matters. Somebody bridges the gap by hand every day.

04 PROBLEM 04

The record exists in two places

Two platforms hold the same customer record and somebody types it into both. The duplicates, the credits and the reconciliation all come from one missing integration.

05 PROBLEM 05

The replacement cannot stop trading

The platform running the business has to keep running while it is replaced. That makes the work phased, reconciled and reversible at each step.

06 PROBLEM 06

Every new client adds an administrator

Volume is absorbed by hiring, because the repetitive steps were never automated. AI takes the steps that follow a rule and escalates the rest to a person.

What that becomes

The capability list supports the proposition. It is not the proposition.

Engineering, not web design. These are the forms the work usually takes.

01 BUILD

Systems and applications

Operational and business systems. Customer and employee portals. Booking, scheduling and workflow platforms. Applications and internal software products.

02 CONNECT

Integration and data

API, CRM, finance and payment integration. Workforce-management platform integration. Data migration and reconciliation. Monitoring, alerting and error handling.

03 REPLACE

Legacy and AI in the workflow

Legacy replacement and phased migration. AI decisioning designed into an existing process. Document and unstructured-data handling. Automation of the repetitive manual step.

Scope

What we do not do

Brochure websites, template themes, marketing microsites and generic digital services. If that is the requirement, we are the wrong supplier and say so on the first call.

AI in a bespoke build

No AI worker is live for a client yet

Where a bespoke build includes an AI worker doing one repetitive job, it is scoped and discussed before it goes anywhere near live data. No AI worker has run for a client yet. We scope it and discuss it; we do not claim it is running for a client.

Source, documentation, environments and training.

The engineering process

A professional software engineering process, written down.

Every stage produces an artefact you keep — a scope, an architecture, a demo, a handover pack. Nothing is invisible and nothing is verbal.

DISCOVERY Process map, written scope

TECHNICAL DISCOVERY Architecture, integrations, risk

BUILD Development against the written scope

HANDOVER Documentation, training, source

MEASURE Check the result against the agreed scope

DISCOVERY OUTPUT A written scope and process map you own outright, to take to another supplier if you want to.

TECHNICAL DISCOVERY OUTPUT An architecture, integration map, data model, and the risks and assumptions the estimate rests on.

HANDOVER OUTPUT Source, documentation, environments and training. Support is an option, never a dependency.

How we work

The engineering standards behind it.

Engineering standards, applied on every engagement
Area	How we handle it
Architecture	Documented before build. Chosen for the operating environment and the team who will own it, not for novelty.
Integration	APIs where they exist; authenticated portal and inbox automation where they do not. Everything monitored and alerting.
Data	Migration planned and reconciled. UK data residency where required, with processing terms and a DPIA.
Accessibility	Tested against recognised accessibility standards rather than assumed. Expected on public-sector work.
Security	Least-privilege credentials, an audit trail on every automated action, dependency and access review at handover.
Release	Works alongside an internal team, to their standards, their environments and their release process.

Questions we get asked

Straight answers before you call.

What counts as bespoke software?

Bespoke software is written for one organisation's process rather than bought as a product and reshaped to fit around it. It answers the process you actually have, not the closest one on the market. If a product already does the job, we say so on the first call.

What are some examples of bespoke software?

A supplier or client portal built around your own document set, rather than a generic one. A workflow platform that replaces a spreadsheet being used as a system of record. An integration that removes a manual step between two products you already run. Each is shaped by a process a bought product does not fit.

What is an MVP in software development?

An MVP is a first release that does one workflow properly rather than every workflow partly. For an operational system, minimum still has to survive a live working day, so the real question in discovery is which single process can carry that first release.

Do we own the source code and the documentation?

Handover transfers the source, the documentation, the environments and training, on final payment. Discovery and technical discovery hand over their own artefacts earlier: a written scope and process map, then an architecture, integration map, data model and risk list. All of it is yours to take elsewhere, including to another supplier.

Can you replace a legacy system without stopping trading?

Nothing is cut over until it reconciles against the system it replaces, and every phase has a way back to the version before it. The platform running the business keeps running throughout. Data decides the schedule rather than code, so migration and reconciliation are planned in technical discovery before any build starts.

What does a software consultancy deliver before any code?

Documents, not code, come first: a written scope and process map from discovery, then an architecture, integration map, data model and risk list from technical discovery. Both stay yours whoever ends up building the system, and take them to another supplier and they remain valid, which is the point of writing them down.

Where this leads

Describe the system that does not exist yet.

A short call with a technical director, then a discovery session with the people who do the work today.

sales@msdsystems.co.uk Book a scoping call

Your operation is the starting point.