Seven months in, every status meeting ends with "we're ninety per cent done", and nobody can explain why the last ten per cent has taken three months. You have no working screen to click, no test address to try, and the contract never defined what "done" means. That is rarely down to a bad development team; far more often, the client side lacks the tools to steer.
This is a handbook for whoever commissions custom software. You do not need to code; you need to know what to ask for, what to see and when, and which sentences belong in the contract. We go in order: discovery, MVP, user stories, contract models, sprint and demo rhythm, testing, source code and handover, and life after launch.
Discovery and scope: write down the problem, not the screens
Most projects start with a list of screens: "a login page, an order screen and a reports page". A screen list is really a proposed solution. What matters is the problem behind it. "Our dealers place orders by phone and wrong part numbers cause returns every week" is worth more than a ten-item screen list.
Discovery is a short phase in which you and the development team pin down that problem, the users and the constraints, usually through a few workshops, watching the current process on site and a technical review. A good discovery leaves you with:
- A definition of the problem and of success: what should be different when the project is finished, and how will you measure it?
- User roles: dealer, sales rep, warehouse lead, finance, system administrator.
- A map of today's process, including who does what by hand at each step.
- The systems to integrate with: ERP, accounting software such as Xero or Sage, payment provider, couriers.
- Constraints: GDPR or UK GDPR, sector regulation, internal IT security rules, the devices your users actually have.
- A prioritised backlog and a rough architecture proposal.
- A risk list: what is least understood and most expensive if it goes wrong.
Buying discovery as a separate, small contract is healthy for both sides. You see how the team works before committing the big budget, and the team learns what it is really building before it estimates. The outputs should belong to you and stay useful with any supplier. Our article on writing a good project brief covers the groundwork.
Cutting the MVP down to the right size
An MVP, a minimum viable product, is not a half-finished full product. It is the smallest working version that lets you test your riskiest assumption with real users. The key word is "working": a narrow path on which users can complete their task from start to finish beats a wide shop window that touches everything a little.
Take a spare-parts distributor with two hundred dealers. The tempting list for version one is long: ordering, stock, promotions, account statements, returns, a mobile app, advanced reporting. A properly trimmed MVP says this instead: a pilot group of ten dealers can search parts by part number or vehicle model, see stock, place an order, and the order lands in the ERP automatically. Promotions, returns and the app wait for phase two.
Slice by user flow, not by technical layer. "First the whole database, then all the screens" produces nothing a user can see for months. A simple classification such as MoSCoW helps: Must, Should, Could and Won't (this time). A list with an empty Won't column has not cut anything.
Three things are forgotten in MVPs again and again:
- The admin side. Who edits products, users and permissions, and where?
- Data migration: how do customer accounts and price lists from the old system get into the new one?
- Reporting, because in week one management will ask how many orders came in.
If those three are missing, your MVP is small on paper and incomplete in reality.
User stories and acceptance criteria
A practical way to write requirements is the user story: "As a [role], I want to [do something], so that [I get a benefit]." For example: "As a dealer, I want to search parts by vehicle model, so that I can order the right part without knowing its number." A story should be short, describe one need and be small enough to finish within a single sprint.
What makes a story useful is the acceptance criteria underneath it, the measurable answer to "when is this done?". A common pattern is "given this situation, when this happens, then that should follow":
- Given a dealer has reached their credit limit, when they try to confirm an order, then the system blocks it and shows the remaining limit.
- Given an item is out of stock, when it is added to the basket, then the expected supply date appears on that line.
- Given an order is confirmed, then it appears in the ERP within a few minutes and the dealer receives a confirmation email.
The project also needs a Definition of Done, a Scrum Guide term for the shared quality bar every piece of work must meet: code reviewed, automated tests written, deployed to the test environment, documentation updated. Without it, "done" means something different to everyone.
Fixed scope or time and materials? Contract models
This is the most argued-over topic at proposal stage, and the right answer depends on how well the project is understood. The clearer the scope, the more sense a fixed price makes; the more uncertainty, the more honest time and materials becomes.
| Model | How it works | Upside | Downside |
|---|---|---|---|
| Fixed scope, fixed price | Scope written up front, price and date tied to it | Predictable budget, easy to compare bids | Every change means a contract variation; uncertainty is priced in as risk |
| Time and materials | Effort billed at agreed rates | Easy to change priorities along the way | Budget control is yours; risky without transparent reporting |
| Capped time and materials | Time and materials with a monthly or overall ceiling | Balance of flexibility and budget control | Scope gets renegotiated as the cap approaches |
| Phased model | Fixed-price discovery, then development in phases or sprints | Big budget committed once more is known | Deciding again at each phase takes management effort |
| Dedicated team | A set team capacity reserved for you each month | Continuity and a team that knows the product | Needs a strong product owner on your side |
A fixed price looks safest on paper, but it hides two costs. The supplier prices unknowns in as a risk margin. And everything you learn along the way arrives as a change request, so the relationship drifts from improving the product to interpreting the contract.
Time and materials needs trust and visibility. Weekly hours, backlog progress and the remaining estimate are not extras in this model; they are the model. A healthy pattern we see often is fixed-price discovery, capped time and materials for the build, and a monthly support agreement after launch.
How to read estimates
A software estimate is a forecast made at a given level of knowledge, not a promise. Estimates before discovery swing widely and narrow as discovery ends and the first sprints complete. Ask for a range rather than a single number, and ask why it is wide: which integration, which unknown? Story points are not hours but relative sizes; what means something is the average pace that emerges after a few sprints. Revisiting the estimate after the first two sprints is normal enough to write into the contract.
Sprint and demo rhythm: how do you see progress?
Agile teams split work into short periods called sprints. Under the Scrum Guide a sprint lasts a month at most, and in practice most teams choose one or two weeks. The sprint review at the end is your most important meeting, because finished work is shown running in the test environment.
The test is simple: working software, not slides. "Designs are ready" or "the back end is eighty per cent there" is not progress. Ask for the mouse during the demo: click around, enter wrong data, press the back button.
Your side needs a product owner who decides priorities, answers questions within days and attends demos. If decisions circulate around a five-person committee, the team waits, and under time and materials waiting goes straight onto the invoice. Appointing a manager who cannot spare a few hours a week slows the project from day one.
You also need to see the backlog. Ask for read access in Jira, Linear or GitHub Projects. A simple burn-up chart, showing how much scope is done and how the remaining estimate moves, is a more honest indicator than any monthly report.
Keeping scope creep under control
Scope creep rarely arrives as one big decision. It comes as "a small addition", as "while you're building that screen, could you also...", or as the finance or IT security team joining halfway with requests of their own. Each one is reasonable; together they push the delivery date out by months.
A simple rule usually works: if something comes in, something goes out. The new request is logged and estimated, and the product owner decides what it displaces. Each decision goes into a decision log with its date and reasoning, so six months later "who asked for this, and why?" has an answer.
Creep does not only come from the client: an animation nobody asked for, or a module "just in case", counts too. If you spot one in a demo, ask which story it belongs to.
Testing and quality: staging, automated tests and acceptance
A professional project has at least three environments: development, where engineers work; staging, which mirrors production as closely as possible; and production. Demos and your testing happen on staging; nobody experiments on production.
Copying real customer data into staging as-is is a common and dangerous shortcut. Personal data should be anonymised or replaced with realistic synthetic data; under GDPR a test environment deserves the same care as the live one.
Quality does not come from clicking around alone. A good team writes automated tests at several levels and runs them on every merge in a continuous integration pipeline such as GitHub Actions or GitLab CI:
- Unit tests check that individual functions calculate correctly, discounts and VAT for instance.
- Integration tests: they show that code talking to the database, the ERP or the payment provider behaves correctly.
- End-to-end tests drive a real browser with tools such as Playwright or Cypress through a flow like "dealer logs in, searches for a part, places an order".
- Code review, meaning every change is read by a developer other than its author.
Security, performance and accessibility checks come on top. OWASP's ASVS and Top 10 are a good starting list for security, and WCAG 2.2 is the reference for accessibility. For systems handling personal data or payments, an independent penetration test before launch is a sensible expense.
The final step is your user acceptance testing. You work through the acceptance criteria and report defects by severity: system unusable, important function broken, or cosmetic. Agreeing in advance how many open defects of which severity still allow go-live saves a heated argument in the last week.
Source code, intellectual property and handover
Source code should live in a GitHub or GitLab account that belongs to your company, from day one. The supplier is given access; the repository does not sit in their account waiting to be "handed over" at the end. The same goes for the cloud account, domains, app store accounts, email service and third-party API keys: all opened in your company's name, with the team granted permissions.
On intellectual property, the basic point is this. Software is protected by copyright, and an agency or freelancer is not your employee. In the UK, under the Copyright, Designs and Patents Act 1988, work made by employees in the course of employment belongs to the employer, while work by contractors stays with its author unless copyright is assigned in writing. Other countries have their own rules, so a single line saying "the code belongs to the client" may not be enough.
Two more details matter. The supplier may bring its own libraries and tools that existed before your project; for those you get a licence rather than ownership, and its scope should be written down. And almost every project uses open-source components. Permissive licences such as MIT rarely cause trouble, but copyleft licences such as the GPL or AGPL can require you to publish your own source code when you distribute the software or offer it over a network. Ask for a licence inventory at handover.
Documentation and handover
Documentation keeps the system out of one person's head. At handover, receive at least:
- Setup instructions (a README): how does a new developer get the system running on their own machine?
- An architecture overview and the reasons behind key technical decisions.
- API documentation, ideally in OpenAPI format.
- The data model, and which data is exchanged with external systems and how often.
- Deployment steps, a list of environment variables, and where secrets are stored and who holds them.
- Backup and restore procedures, tested at least once.
- A list of known issues and postponed work.
The test of a good handover is simple: can a developer outside the team set up the system and ship a small change using only these documents? Checking that for real can be an acceptance step. Tidy up access too: close the accounts of people leaving the project and rotate shared passwords and API keys.
After launch: support, SLAs and what sinks projects
Support and SLAs
Software is not finished on launch day; that is when its life begins. Updates, security patches, bug reports and small improvements all need a support agreement, with the service level agreement at its centre.
A good SLA classifies incidents first: critical when the system is down, high when an important function fails, normal when work can continue. Each class gets two separate times, a response time and a resolution or workaround time. Do not confuse them; "we respond within two hours" and "we fix it within two hours" are very different commitments. Support hours, monitoring and alerting, backup frequency and who is responsible for hosting belong in the same document.
What sinks projects most often
Code quality rarely sinks a project on its own. The causes we see most often are about management:
- No single person on the client side who can make decisions.
- Real users seeing the product for the first time a week before launch.
- Data migration and integrations waved through as "we'll sort that later".
- Big-bang launches instead of a pilot group and a phased switch.
- Choosing the lowest bid without understanding the scope.
- Only one developer understanding the system.
- No budget at all for life after launch.
Where to start
- Write the problem, the users and the measure of success on one page; leave the screen list for later.
- Start with a separate, small discovery engagement and make sure its outputs belong to you.
- Cut the MVP down to one user flow, and add the admin side, data migration and reporting to the list.
- Require measurable acceptance criteria for every story and a Definition of Done for the project.
- Choose a contract model that matches the project's uncertainty and review the wording with your legal adviser.
- Appoint your product owner and give them a diary that genuinely leaves room for the role.
- Open the code repository, cloud accounts and domains in your company's name from day one.
- Sign the support agreement and SLA before launch, while you still have negotiating power.
At AYTE Digital we run discovery as its own phase on custom software projects and open source code and accounts in the client's name from the first day. If you have a project that is running or stuck, we can go through your backlog together and see which of the points above are missing.
