The Custom Software Development Process

The shape of a build

Every custom software development process is a variation on the same six phases. Teams differ in how strictly they separate them — an agile team loops through the middle four every fortnight rather than passing through each once — but the same six kinds of decision have to be made, in roughly this order, whatever the method is called.

The timings below assume a department-level system: a few user roles, a handful of integrations, three to four months end to end. A focused internal tool compresses the same shape into six to ten weeks. A multi-module platform stretches it across a year and repeats phases three through five per module.

1. Weeks 1–2

   Discovery

   Document the real workflow, surface the edge cases, and turn a conversation into a fixed scope.

2. Weeks 2–4

   Design

   Decide what each screen does and who sees it, in a form the client can react to before code exists.

3. Weeks 3–5

   Architecture

   Choose the data model, the stack and the hosting shape — the decisions that are expensive to reverse.

4. Weeks 4–16

   Build

   Ship in slices, each one demonstrable, so progress is visible rather than reported.

5. Overlapping

   Testing and UAT

   Automated checks throughout; then the client’s own team runs their real work through it.

6. Final week

   Launch and handover

   Migrate data, train the team, transfer the accounts and code, then support the first weeks of real use.

What follows is what actually gets decided in each phase, and what it costs you to get it wrong.

Phase 1 — Discovery

Discovery exists to answer one question: what does the work look like when nobody is describing it in a meeting? The gap between how a process is described and how it runs is where every late change request comes from.

Good discovery is mostly watching and collecting. Sit with the people who do the job. Take copies of the spreadsheets, the paper forms, the WhatsApp threads where approvals actually happen. Ask what happens when something goes wrong, because the exception handling is usually half the software and never appears in the initial brief.

What comes out of it

• Written workflow
• Roles and permissions
• Numbered scope list
• Out-of-scope list
• Integration inventory
• Open questions

Phase 2 — Design

Design here means interface design and interaction design, not visual polish. The output is a set of screens specific enough that a client can look at them and say “that is not how we do returns” — which is exactly the sentence you want, in week three rather than week fourteen.

The discipline that matters most is designing the ugly states. Every screen has an empty version, a loading version, an error version and a version where somebody has entered forty-two items instead of three. Systems feel unfinished in production almost entirely because those four were skipped in design.

A prototype is the cheapest place to be wrong. Every phase after this one multiplies the cost of the same correction.

Phase 3 — Architecture

Architecture is the set of decisions that are expensive to reverse: how the data is modelled, what the stack is, where it runs, how identity and permissions work, how it talks to the systems you already have.

The data model deserves disproportionate attention. Framework choices can be revisited; a schema that got a core relationship wrong is felt in every feature built on top of it, and by the time that becomes obvious there is a year of data in it. If any phase warrants slowing down and arguing, it is this one.

Questions to settle before code

• What is the system of record for each piece of data — this build, or something else?
• What happens to a record when it is deleted? Genuinely gone, or archived and audit-logged?
• Who can see what, expressed as rules rather than as a list of screens?
• What is the recovery plan — backups, retention, and who has tested a restore?
• Which third-party services become dependencies, and what happens when one is down?

Phase 4 — Build

The longest phase and, if the previous three were done, the least dramatic. Work ships in slices — a slice being a complete piece of behaviour a user could actually use, not a layer of the stack. “The database is done” is not progress anyone can verify; “you can now raise a purchase order and have it approved” is.

Expect a demonstrable increment every one or two weeks, on a URL you can open yourself. The cadence matters more than the ceremony around it. A project where the client has not seen working software for six weeks is a project with a problem that nobody has found yet.

What your team owes the build

Roughly two hours a week: look at the increment, answer the questions that came out of it, make the decisions only you can make. This is the phase where clients most often go quiet, and the rework that follows is the most expensive kind, because it lands on code that is already written and already tested.

Phase 5 — Testing and UAT

Two different activities that get one name. Automated testing runs throughout the build and is the developer’s responsibility: it catches regressions, the things that used to work and quietly stopped.

User acceptance testing is yours, and it is not a demo. It means your team running a week of real work through the new system in parallel with the old one — real orders, real customers, real awkward cases. Every serious problem found in UAT is a problem not found in production with your reputation attached.

Phase 6 — Launch and handover

Launch is a data problem more than a technical one. Existing records have to move, and real data is always messier than the sample: duplicates, missing fields, three spellings of the same supplier. Migration is worth a dry run against a copy of production before the day it matters.

Handover is the part most often left vague. It should include the source repository, the infrastructure accounts in your company’s name, deployment documentation, and enough training that your team can operate the system without calling anyone. Then a defined warranty window for defects, and a support arrangement if you want one.

Budget attention — and some money — for the first three months after launch. Real usage always surfaces adjustments that testing did not, and a system that gets those small changes quickly is the one the team keeps using. There is more on that in what custom software costs.

Where projects go wrong

In our experience, failures cluster at five specific points rather than being spread evenly across a build.

• Discovery was skipped to save money. The understanding still has to be bought; it is simply bought later, as change requests, at a worse rate.
• Nobody on the client side could decide. Every project needs one person empowered to settle questions in days rather than weeks. Decision-by-committee is the most common cause of a slipped timeline, and it never appears in a status report as such.
• Scope grew without the plan changing. Additions are legitimate; adding them while the date and budget stay fixed is not. Every change should visibly move something.
• UAT was treated as a formality. A signed-off demo is not a tested system.
• Nobody planned for after launch. A system with no owner and no budget for small changes decays into the thing people work around within a year.

If you are earlier than this — still working out whether to build at all — start with what custom software development is or browse examples of what these systems look like.

Built this way

Enterprise Resource Planning System

Emarath ERP

Inventory, procurement, finance, HR and reporting folded into one system with role-based access.

Real Estate Website

VRS Real Invest

A property investment site built around one job: turning research traffic into booked consultations.

Questions