# How to commission software development without overruns

URL: https://casterconsulting.hu/en/commission-software-development/
Published: 2026-10-15
Updated: 2026-10-15
Author: Caster Consulting

> Software projects rarely slip because of the programming; far more often, the client and the developer mean different things by the same sentence. Clear requirements, short testable steps and a good contract protect you better than any fixed price.

**Short answer: software projects rarely slip because of the programming; far more often, the client and the developer mean different things by the same sentence.** Clear requirements, short testable steps and a good contract protect you better than any fixed price. If the client only shows up at the start and the end of a project, a surprise at the end is almost guaranteed.

Most SMEs rarely commission software, so they have no routine for it. The development company does. That asymmetry is the most common reason projects become slower and more expensive than expected. This article looks at it from the client's side.

## Why projects slip

Bent Flyvbjerg and Alexander Budzier analysed 1,471 IT projects. The average cost overrun was 27%, which is unpleasant but manageable. But one project in six became a "black swan", with an average cost overrun of 200% and a schedule overrun of almost 70%. These rare derailments eat most of the money.

According to PMI, the US-based project management organisation, nearly half (47%) of unsuccessful projects miss their goals because of inaccurate requirements management. Not because of technology, but because it wasn't clear what had to be built.

Panorama's ERP project research shows the same: expanding scope, meaning requirements added along the way, accounts for 20% of cost overruns and 19% of schedule overruns.

All three point in the same direction: **the biggest risk is vague requirements that keep changing.** The good news is that this is the risk a client can influence most.

## Before you sign

### Describe the need from the user's point of view

You don't need a technical specification. You do need a description of who will use the software, what they want to achieve and how they'll know it worked. A good format is the user story: "As a warehouse worker, I want to record incoming goods by barcode, so I don't have to type item numbers."

Each story needs acceptance criteria: when do you call it done? For example: "after scanning a barcode, the item appears in stock, and the system warns on an invalid barcode."

### Ask for a prototype

Before a line of code is written, ask for a clickable prototype of the main screens. Users spot in minutes on a prototype what they'd miss for weeks in a written specification. It's the cheapest bug fix in the whole project.

### Decide what the smallest working version is

Keep the first version narrow: one process, one team, the most important features. Everything else goes on a list for later. A smaller first step means less risk, and it quickly shows whether client and developer understand each other. If it goes well, extensions can be planned far more precisely, because they rest on real use rather than assumptions.

## Fixed price or time and materials?

**Fixed price:** you know the cost up front, but the developer prices in the risk, and every change needs a separate amendment. It works when the need can be described precisely and is stable.

**Time and materials:** flexible, and you only pay for work actually done, but the final cost is less certain. It works when the need becomes clearer as you go.

A mix works well in practice: a fixed-price assessment and prototype, followed by time-and-materials development in short, fixed-length phases, each ending with working, testable software. After every phase you can continue, change direction or stop, and you never pay for more than one phase of something that doesn't work.

## How to work during development

### Short cycles with working results

According to the official Scrum Guide, the most widely used agile method, a development cycle (sprint) lasts one month or less. Every sprint ends with a verifiable result (an increment), but only what meets the agreed Definition of Done counts. Anything that doesn't can't be released, and can't even be presented at the end-of-sprint review.

As a client, that means: ask for a demo of working software every two weeks or every month, not a status report. One working screen says more than ten pages of progress reports. Bring the people who will actually use the software to these demos; their reactions are the most reliable early warning you'll get.

### Change control

Requirements will change; that's normal. The question is how. A simple rule: every new request goes on a list, the developer estimates it, and the client decides whether it goes in and what comes out instead. Anything not written down and approved isn't part of the project.

### Make time to test

Someone on the client side must have time to try each result and say clearly what's wrong. Most custom projects don't fail because the developers can't code; they fail because nobody on the client side had time to look until it was too late.

## The contract: IP, source code, exit

This is the point most SMEs forget, and it shapes your freedom for years.

**Who owns the software?** Rules differ by country, but the pattern is similar in many jurisdictions: code written by employees as part of their job usually belongs to the employer, while code written by an outside contractor doesn't automatically become yours. Hungary is a typical example: its copyright act gives employers the economic rights in works created by employees in the course of their duties unless agreed otherwise, makes economic rights in software transferable, and lets the parties freely agree the terms of a licence. With an external developer, nothing is automatic; the contract has to transfer the rights or grant you a licence.

**What do you receive?** Put it in the contract:

- handover of the source code, in a version control system;
- documentation (installation, operation, architecture);
- access to servers and accounts, in your name;
- ownership and exportability of the data.

**How do you exit?** The UK government's purchasing guidance recommends break clauses of two years or less, minimal exit costs, and clear terms on data and intellectual property. An SME should aim for the same: if the development company closes or becomes unreachable, your software shouldn't disappear with it.

## How to choose a development company

The cheapest offer is rarely the cheapest project. A few questions say more than the hourly rate:

- **How do they understand the need?** Do they ask questions, or quote straight away? A good developer asks more than they say in the first meeting.
- **Can they show a similar, working project,** and can you talk to a previous client?
- **Who works on the project?** Does the same team stay throughout, or do people rotate?
- **How do they handle changes** and delays? Is there a written process?
- **What happens after handover?** Bug fixes, support, further development: on what terms?

If an offer is strikingly cheap, ask what's missing. Testing, documentation or change control are often left out, and resurface later, at a higher price.

## Handover and follow-up

The project doesn't end with the last feature. At handover, check the acceptance criteria, ask for complete documentation and access, and plan a follow-up period in which the developer quickly fixes issues found in real use. Put the warranty period for bug fixes and the support response time in the contract.

## What we've seen

Several of our team's earlier projects show how much business analysis and project management matter.

- **A veterinary app on WeChat:** an app for external veterinarians built for the Chinese subsidiary of an international animal health company, in six months. We ran business analysis and project management from Europe, across time zones, in a Chinese-language environment. In that situation, a precisely described need and regular demos aren't formalities; they're the only common ground.
- **Regulatory document management:** at the company's Brazilian subsidiary, regulatory documents and procedures moved from a file server into a document management system with approval workflows, versioning and expiry tracking, for 50 users. Development, business analysis and project management were all our team's.
- **Mobile audits:** a web and mobile audit system built for four European countries in eight months, where our team led development and provided project management and architecture.

In all three, success didn't come from special technology, but from a clear need, short steps and a client who saw the results continuously.

## Warning signs

- The developer shows no working software for months, only status reports.
- There's no written, approved list of requirements.
- The contract says nothing about source code and rights.
- Nobody on the client side has time to test.
- Every change "fits in quickly", without a written decision.
- Servers, domain and accounts are in the developer's name, not yours, and you don't know how to access them.

## What to do now

1. **Write the need as user stories,** with acceptance criteria.
2. **Ask for a clickable prototype** before development.
3. **Define the smallest working version,** and put everything else on a later list.
4. **Choose a contract model,** for example a fixed-price assessment followed by time-and-materials development in short phases.
5. **Put rights, source code, documentation and exit in the contract.**
6. **Name an internal owner** with time to test after every cycle.
7. **Ask for regular demos of working software,** not just reports.

If you'd like help describing your needs, choosing a developer or with the development itself, have a look at our [custom software development](/en/software-development/) and [IT consulting](/en/it-consulting/) services.

## FAQ

### Why do software projects slip?

Most often because of vague or changing requirements. PMI found that nearly half (47%) of unsuccessful projects miss their goals because of inaccurate requirements management.

### Fixed price or time and materials?

Fixed price works when the need can be described precisely and is stable; time and materials when it becomes clearer along the way. A mix works well: a fixed-price assessment and prototype, then time-and-materials development in short, verifiable phases.

### Who owns the source code?

Only what the contract says. In many jurisdictions, rights in contractor-written code don't transfer automatically. Put the transfer of rights or a licence, and the handover of source code, in the contract.

### How often should we see results?

A demo of working software every two weeks or every month. Under the Scrum Guide, a sprint lasts one month or less and must end with a verifiable result.

### What matters most on the client side?

An internal owner with time to try each result and make decisions. Without that, even the best development team works blind.

## Sources

- [Flyvbjerg, Budzier – Why Your IT Project Might Be Riskier Than You Think (arXiv 1304.0265)](https://arxiv.org/abs/1304.0265)
- [PMI – Requirements Management: A Core Competency for Project and Program Success](https://www.pmi.org/learning/thought-leadership/pulse/core-competency-project-program-success)
- [Panorama Consulting – 2017 ERP Report](https://www.panorama-consulting.com/wp-content/uploads/2017/07/2017-ERP-Report.pdf)
- [Schwaber, Sutherland – The Scrum Guide (2020)](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf)
- [GOV.UK – Define your purchasing strategy](https://gov.uk/guidance/define-your-purchasing-strategy)
- [Hungary – Act LXXVI of 1999 on Copyright (in Hungarian)](https://njt.jog.gov.hu/jogszabaly/1999-76-00-00)