Software projects rarely fail technically. They fail because two sides understood different things and discovered it at delivery.
Commissioning well is not a matter of trust or luck. It is a matter of three documents: a brief describing the problem, a phased quote, and acceptance criteria written before any work starts.
Want us to look at your brief before you send it?
Send it over and we will tell you what is missing — even if you award the work elsewhere.
What goes in the brief
A brief does not describe a solution. It describes a problem, constraints and success.
| Section | What it contains |
|---|---|
| The problem | What does not work today, with numbers |
| Who uses it | Roles, headcount, technical level |
| What it must do | The 5–10 core functions |
| What it connects to | Existing systems and data |
| What counts as success | A measurable outcome |
| Constraints | Budget, dates, technologies |
The fifth row is almost always missing — and it is the one that decides whether the project is judged a success. “Reduce order entry time from 6 minutes to 2” is a criterion. “Make it user-friendly” is not.
Two things you do not need to know: which technology and how it will be built. A brief that mandates technology without reason narrows the proposals for no benefit.
How to choose a partner
Get quotes from three, not seven. And compare on these criteria, not on price.
| Criterion | What it reveals |
|---|---|
| The questions they asked | Anyone who asked nothing understood nothing |
| A phased breakdown | That they thought about delivery |
| What is explicitly excluded | That there will be no surprises |
| A similar past project | That they know where the difficulties hide |
| Who will actually do the work | Often not the person presenting |
| What happens after delivery | Whether maintenance exists, and its cost |
The cheapest quote is usually the least considered. Somebody quoting without questions is quoting for something they imagined.
If the project is a website, the selection criteria are also covered in how to choose a web developer.
What the contract must say
Eight points. Miss one and you pay for it later.
- Scope with deliverables per phase, not a general description.
- A timeline with milestones and what happens on delay.
- Who owns the source code after final payment. Ask for full transfer.
- Where it is hosted and who owns the accounts.
- What happens to the data and how it is exported.
- A warranty period for bug fixes, typically 3–6 months.
- Maintenance cost after the warranty, with clear coverage.
- A change process: how extras are estimated and approved.
The third and fourth are where businesses get trapped. A system that works perfectly but belongs to somebody else, or runs on an account you do not control, is not yours.
The eighth prevents the most common friction: every project changes along the way. The point is not to prevent change — it is to know in advance how change gets priced.
How to pay
Never everything up front, never everything at the end. Phases protect both sides.
| Phase | Share | What is delivered |
|---|---|---|
| Kick-off | 20%–30% | Analysis, design, timeline |
| Midpoint | 30%–40% | A working part to test |
| Delivery | 30%–40% | Complete, running in trial |
| Acceptance | 10% | After the fixes |
The last row matters most to you. A share held back until everything works properly is the most effective quality tool you have.
Want a template for quote structure and phases?
Ask us for it and we will send it, with no obligation.
How to accept delivery
Acceptance is not “I looked at it and liked it”. It is a checklist, written before development starts.
What you check:
- Every core function from the brief’s list, with real data.
- Mobile behaviour, if people use it away from a desk.
- What happens on failure: what the user sees when something breaks.
- Speed at real volume, not with ten records.
- Connections to other systems, tested end to end — because that is where most problems appear, as set out in API integration.
- Documentation and access to accounts and code.
And one few people ask for: testing by two people who will use it daily, not only by you. They will find things you never imagined.
The five mistakes that cost
- Commissioning without a brief. “You know best” means you will get whatever somebody else imagined.
- Choosing on price. A 30% gap in the quote becomes a 200% gap in change requests.
- No involvement from you during the work. A project without weekly contact drifts quietly.
- No owner on your side. You need one person who decides.
- Building before evaluating an off-the-shelf option. See the comparison in custom software vs off-the-shelf.
The third is the most underrated: one 20-minute call a week prevents most of the problems that otherwise surface at delivery.
Frequently asked questions
What does a typical project cost?
A simple internal application: €5,000–€15,000. A management system: €15,000–€60,000. Add 30% to the initial estimate.
Local or remote partner?
A local one helps with communication and understanding the context. A remote one may be cheaper, but demands a better brief.
What if the project stalls?
Stop payments at the current phase, ask for a written status assessment, and agree either a new timeline or an exit.
Do I need a technical adviser?
For projects above €20,000, usually worth it. Their fee is less than one wrong architectural decision.
How do I know it succeeded?
By the success criterion you wrote in the brief, measured three months later — see how to track it in dashboards.
The first step
Write one page: what does not work today, who suffers from it, and what success would look like in numbers.
If you cannot fill in the third, the project is not ready to be commissioned — and that is the most useful thing you can establish today.
Next step
Book a free 30-minute call with the team at The Dev Alley. We will look at your project and tell you what the quote you receive should contain.