When a custom software project ends badly, it is rarely bad luck. It is usually a decision taken before the first line of code was written: it was chosen on price, ownership of the code was not insisted on, the meeting was attended with the idea in someone’s head rather than on paper. These are the nine most expensive mistakes when hiring custom software development, and the concrete question that prevents each one before signing.
Why getting it wrong here matters more than in other purchases
Custom software is not bought, it is entered into. It lives for years, it goes into the centre of your operation and the day you want to change supplier you discover how much weight the decisions you took at the start carried. That is why hiring mistakes do not show up on the first invoice: they show up at six, twelve or twenty-four months, when they are already expensive to fix. The good news is that almost all of them are avoided with questions asked in time.
The nine most repeated mistakes
1. Choosing on the lowest price
Faced with three quotes, the temptation is to go for the lowest. The problem is that in software a low price is almost never efficiency: it is a cut you cannot see yet. Either they have understood a smaller project than the real one and the difference will show up as "extras" halfway through, or they cut what you cannot see — tests, documentation, security — and the system works in the demo and breaks in production.
What matters is not the first invoice, but the total cost of ownership: development, plus maintenance, plus what it costs to change supplier the day you need to. Ask the supplier: "What does this price include in tests, documentation and security, and what is left out?". If the cheapest is cheapest because it omits all that, it is not cheaper: it is more expensive in instalments.
2. Not asking to own the code
This is the most expensive mistake and the one fewest people check before signing. If the contract does not explicitly say the source code is yours, you may be paying to use something you do not own. The result is the classic vendor lock-in: code only they understand, hosted where you have no control, impossible to move without starting from scratch.
At Plantekia we say it without qualification: no black box, no vendor lock-in. The code belongs to the client, documented and portable. Ask the supplier: "Is the source code my property, is it in a repository I have access to, and can I take it to another team if one day I want to?". Get it in writing.
3. Arriving with vague requirements
"We want something to manage the orders" is not a requirement, it is a wish. The vaguer you arrive, the more each supplier imagines something different, the more some inflate and others cut, and the less comparable the quotes are. The ambiguity does not disappear: it gets paid for later, as scope changes halfway through the project.
You do not need a perfect technical specification — that is the team’s job — but you do need to know what problem you are solving, for whom and how you will know it is solved. Ask yourself before the meeting: "Can I describe in five sentences what the system does and whose concrete pain it removes?". If you cannot, the first deliverable is not code: it is a diagnosis.
4. Not insisting on documentation and tests
Documentation and tests are the first thing cut when someone wants to lower the price, and what you will miss most afterwards. Without tests, every change is a roulette: you fix something and break something else without noticing. Without documentation, the knowledge lives in one person’s head, and the day that person is not there, you depend again on whoever built it.
Code you can understand, audit and maintain is not a luxury: it is the difference between having an asset and having a dependency. Ask the supplier: "What test coverage do you deliver and what documentation am I left with so another team could continue without you?".
5. Paying everything up front with no milestones
Paying a hundred per cent up front removes your only point of control. And paying against a single final milestone, conversely, leaves all the risk on the wrong side. The healthy option is paying by milestones: tranches tied to concrete deliverables you can see, test and approve before releasing the next payment.
That aligns incentives: the supplier gets paid when they show real progress, and you keep the ability to stop if something does not fit. Ask the supplier: "How are the milestone payments structured, what concrete deliverable corresponds to each, and what happens if a milestone does not meet what was agreed?".
6. Not diagnosing before building
Asking for a software quote with no prior diagnosis is like asking for a building quote with no plans: every supplier imagines something different and the numbers are not comparable. Worse still, sometimes the real problem is not solved by the software you were about to commission — it is solved by tidying up a process or integrating two systems you already have.
That is why we diagnose before proposing. A short diagnosis puts the operational map on the table, where the friction is and what has a real return. Ask the supplier: "Do you run a diagnosis before quoting, or do you just give me a number?". A number over the phone, with no questions asked, is a red flag.
7. Confusing a pretty demo with a solid product
A demo is designed to impress in ten minutes with fake data and the happy path. A product in production has to survive real data, distracted users, load spikes, errors and the passage of time. They are different things, and what you see in the demo is exactly what is easiest to fake.
What holds a product up is beneath the interface: architecture, error handling, security, observability. Ask the supplier: "What happens when this receives malformed data, a thousand users at once or a failure in an external service? Show me something running for real, not just the prototype".
8. Not defining how success gets measured
If nobody agrees at the start what it means for the project to have gone well, at the end each side will have its own version and the conversation will end in who promised what. "That it works" is not a criterion. "That the operations team processes orders in half the time" or "that it cuts invoicing errors to under 1%" are.
Defining success in measurable terms orders the priorities and makes delivery objective. A joint question at kick-off: "Which concrete metric has to move for this to have been worth it, and how will we measure it?". No magic promises: one real metric, agreed in writing.
9. Not asking who maintains the system afterwards
The project does not end when it is delivered: that is when it starts to live. There will be bugs to fix, dependencies to update, changes to request. If you do not agree from the start who maintains the system, under what conditions and at what cost, you risk being left with live software and nobody to look after it, or tied to whoever built it on terms you never negotiated.
Ask the supplier: "Once delivered, what does maintenance look like, what does it cost, what response times do you have and what happens if I decide to maintain it with another team or in-house?". The answer tells you whether they build so you depend on them or so you become self-sufficient.
A short list to take to the first meeting
If you only take one thing away, make it this set of questions. Ask the supplier before signing and the noise separates from the signal very fast:
- Ownership: is the code mine, accessible and portable, in writing?
- Quality: what tests and what documentation do you deliver?
- Payments: what are the milestones and what deliverable corresponds to each?
- Diagnosis: is there a prior analysis or do you just give me a number?
- Reality: can I see something in production, not just a demo?
- Success: which concrete metric measures that this has worked?
- Afterwards: how, at what cost and with whom is the maintenance?
None of these questions is aggressive or technical. They are the ones anyone would ask who understands they are commissioning something that will live for years inside their operation. A good supplier welcomes them, because they prevent misunderstandings. Whoever they make uncomfortable is giving you valuable information.
The antidote: diagnose before proposing
Almost all of these mistakes share the same root: taking big decisions on small information. A supplier gets chosen without knowing what is wanted, a contract gets signed without knowing what is owned, something gets built without knowing how success is measured. The antidote is not technical, it is a matter of method: putting things on the table before committing.
That is exactly how we start any custom software development project: we diagnose before proposing, with no black box and no vendor lock-in, with code you can understand, audit and maintain. If you are weighing up a contract and want to avoid these mistakes from the start, let us talk about your operation and we will begin with an honest diagnosis of what you really need — and what you do not.