How to procure system development – the whole process
Procuring system development starts with a needs analysis and a longlist of vendors, moves through a weighted evaluation where price isn't allowed to trump everything else, and ends with negotiation and a contract. Expect a few months from start to signature. In the final phase, a proof of concept or trial project can separate the last candidates.
Buying system development isn’t like buying a product off a shelf. You’re buying a commitment that will live for years, and the decision is made before you’ve seen the result. A structured procurement reduces the risk of choosing wrong. This guide walks through the process for a private organization – from needs analysis to signed contract – with realistic timelines and an evaluation where the lowest price isn’t allowed to decide alone.
The process step by step
The procurement follows a logical chain, where each step builds on the last:
- Needs analysis. What does the system actually need to solve, and what matters most? This is where the foundation is laid – an unclear picture of needs punishes you at every later step.
- Longlist. A broad list of possible vendors is drawn up, perhaps eight to twelve, based on research and recommendations.
- Rough screening to a shortlist. The longlist is boiled down to a handful of serious candidates worth evaluating in depth.
- In-depth evaluation. The shortlist is met, their experience and ways of working are examined, references are taken, and quotes are compared against an evaluation model.
- Trial project in the final phase. One or a couple of finalists get to solve a small, real task, so their way of working shows for real.
- Negotiation and contract. Terms, responsibilities, and support are negotiated and written down with the chosen vendor.
Realistic timelines per step
The most common mistake is underestimating the time and rushing a decision. A well-thought-out procurement for a private organization usually takes two to four months. Roughly broken down:
| Step | Realistic timeline |
|---|---|
| Needs analysis | 2–4 weeks |
| Longlist and screening to shortlist | 1–2 weeks |
| In-depth evaluation with meetings and references | 3–5 weeks |
| Trial project in the final phase | 2–3 weeks |
| Negotiation and contract | 2–4 weeks |
The time spent on the needs analysis is the most profitable in the whole process. Every ambiguity resolved there is one you don’t have to pay for later as misunderstandings and rework – both in the procurement and in the project itself.
A weighted evaluation model – price can’t trump everything
The most dangerous shortcut is letting the lowest price decide. In system development, quality, ways of working, and collaboration ability affect total cost far more than the hourly rate, because a commitment that drags on or builds the wrong thing ends up the most expensive of all.
A weighted model protects against that. Before the quotes come in, you decide on criteria and weights, for example:
- Technical ability and relevant experience – heavy weight.
- Ways of working, communication, and cultural fit – heavy weight, since a multi-year collaboration lives on them.
- Price – a meaningful, but not dominant, share.
- Support and long-term outlook – what does support look like after launch?
Each vendor is scored against the criteria and the sum decides. The gain is twofold: the decision becomes more deliberate, and it can be justified afterward – to management and the board – instead of resting on gut feeling or the lowest bid at the last minute.
Proof of concept and trial project in the final phase
When a couple of finalists remain, equally matched on paper, presentations are a blunt way to choose. A trial project is sharper.
Let the finalists solve a small, real task for payment – a defined feasibility study, a prototype, or a first module. Then you see what actually decides but never shows up in a quote: how they really work, how they communicate when something gets tricky, what quality they deliver. It’s one of the most reliable ways to tell candidates apart, and it gives both parties a chance to get a feel for each other before the big commitment. Paying for the trial project is reasonable, and it also screens out those who aren’t seriously interested.
A concrete scenario
An organization was about to procure a business system and was initially tempted to go with the lowest price. Instead, they spent three weeks on a proper needs analysis and set up a weighted model where price counted for around a quarter.
Two vendors ended up tied. A paid trial project – a defined first module – decided it. The one that was cheaper on paper turned out to communicate sluggishly and deliver unevenly, while the other worked closely and kept up quality. The choice fell on the latter, despite a higher hourly rate. The trial project cost a small amount and saved them a multi-year collaboration with the wrong partner.
Spend the time where it pays off
Procuring system development rewards patience at the start and sharp tests at the end: a proper needs analysis, a weighted model where price is one factor among several, and a trial project that shows the truth before the contract is signed.
At Weapp we often take part in this kind of process and are glad to contribute a defined feasibility study as a first step, as part of our services. Facing a procurement? Get in touch and we’ll talk through how to set it up to choose the right partner.
Frequently asked questions
How long does a system development procurement take?
For a private organization, often two to four months from needs analysis to signed contract, depending on size and how many vendors are evaluated. The most common time-sink is an unclear picture of needs at the start, which forces rework further along. Time spent on the analysis first is saved many times over later.
Why shouldn't the lowest price decide?
Because system development is a long commitment where quality, ways of working, and collaboration ability affect total cost more than the hourly rate. A vendor who's cheap per hour but builds the wrong thing or drags things out ends up the most expensive in the end. A weighted model lets price be one of several factors, not the only one that counts.
What is a weighted evaluation model?
A model where each criterion – technical ability, experience, ways of working, price – is given a weight in advance, and each vendor is scored against them. The sum decides. The advantage is that the decision becomes deliberate and can be justified afterward, instead of being driven by gut feeling or by the lowest price at the last minute.
What's the difference between a longlist and a shortlist?
A longlist is the broad first list of possible vendors, perhaps eight to twelve. A rough screening narrows it down to a shortlist of a few, who are evaluated in depth through meetings, references, and perhaps a trial project. The point is to put the heavy evaluation work into the few who are genuinely in the running.
How is a proof of concept or trial project used in a procurement?
As a final, concrete test in the last phase. Instead of choosing based on presentations, one or a couple of finalists get to solve a small, real task for payment. That shows you working style, communication, and quality in practice before the big contract is signed. It's one of the most reliable ways to tell equally matched candidates apart.