An article by a supplier on how to assess suppliers. The questions, the answers you should hear, the ones that should slow you down, and the five lines that belong in the contract.
by Nadia Maar ·
This is the only piece in the series with no application to open, because it is not about a product: it is about the decision that comes first — who to trust with the work. It is also the most uncomfortable to write, because I am one of the suppliers you would be assessing, and every criterion I propose is one you can measure me by.
I write it anyway for a practical reason: almost every custom software project that goes wrong goes wrong for non-technical reasons. It goes wrong because the wrong person was chosen for the right problem, and the choice rested on a quote, a rapport and a portfolio. The seven questions below cost half an hour and filter far more than those three things combined.
The first thing to check is not about the supplier, it is about you. Custom software is the right answer to a precise problem, and an expensive, slow answer to everything else. Before opening a tender, three checks.
A serious supplier, faced with a problem an off-the-shelf product solves better, says so at the first meeting and loses the project. It is not generosity: a client sold the wrong thing comes back, and comes back angry. If none of the suppliers you are talking to has ever suggested buying instead of building, the problem is not their luck — it is that nobody is looking at your case.
Ask all of them, in the same order, to every supplier. The first two cost little and filter a lot; the last ones are the ones people forget and that later decide how it ends. Open a question to read why it matters and what you should hear back.
This is the question separating an investment from a rental. Custom software whose code you do not own ties you to a supplier who may not exist in five years, and the renewal price will be theirs to set, knowing you cannot leave.
An answer that reassures: “Yours, on delivery, with the repository and the documentation to work on it. It is in the contract.” No hesitation, no caveats about internal libraries.
An answer that should slow you down: “The code stays ours but you get a perpetual licence.” It sounds equivalent and is not: a licence cannot be handed to another developer, and without the repository you cannot even fix a bug.
In many tenders the person who convinces you is not the one who will do the work. It is common practice and not always bad, but you must know beforehand, because the quality of software is the quality of whoever writes it, not of whoever presents it.
An answer that reassures: “Me, and here are two other things I have built.” Or, in a larger firm: “this person, who joins the technical meetings from now on.”
An answer that should slow you down: “We have a dedicated team.” An answer with no names is not an answer. Ask who, and if it stays collective, ask to speak with whoever will write it.
It happens almost every time, and not because anyone got it wrong: you understand your own process while describing it. The point is not avoiding it, it is knowing how it will be handled before it happens.
An answer that reassures: “We quantify it before doing it and you decide whether it goes in now or later. Estimates update when the facts change.” They will also show you how it went last time.
An answer that should slow you down: “Everything is included in the price.” Either the quote is padded to cover the unknown, or changes will be refused, or the project will be delivered unhappily. A fixed price on a vague scope protects neither side.
Maintenance is the line nobody puts into the comparison between quotes, and the one paid for years. Software lives five or ten years; what it costs in the first is less than half the story.
An answer that reassures: A figure or a range, and what it covers: fixes, security updates, small changes. With a stated response time for failures that stop work.
An answer that should slow you down: “We will talk when you need us.” That is fine until you need them on a Saturday. Without a written agreement, priority is set by the supplier according to who shouted loudest that day.
Many suppliers build on proprietary platforms they operate. That is not wrong in itself — it often costs less — but it radically changes what you own at the end, and it should be known before rather than after.
An answer that reassures: A list of well-known, widely used technologies, and where each one runs. “If you change supplier tomorrow, anyone who knows these can pick this up.”
An answer that should slow you down: “We use our own platform.” Then ask what happens if the relationship ends one day, and get it in writing. If the answer is that the software stops working, you are not buying software: you are renting it.
In projects that go badly, the bad news always arrives at the end. In ones that go well it arrives early and small. The difference is not luck: somebody had decided in advance how progress gets measured.
An answer that reassures: “Every two weeks you see something that works, however small, and you can use it.” Not a status report: a thing you can open and try.
An answer that should slow you down: “We send a weekly update.” An update is a text, and a text can say everything is fine for two months. Ask to see the software, not to read about it.
A portfolio shows how something looked on delivery. A client from a year ago tells you how it behaved afterwards — which is the only information that matters and the only one the supplier does not control.
An answer that reassures: A name and a number, with the simple courtesy of warning them first. And, when you call, a person who also talks about what did not work.
An answer that should slow you down: “For confidentiality we cannot.” It does happen, but not for every client and not always. If after ten years of work nobody is willing to speak well of you by name, that is information too.
Spoken answers help you choose; the contract keeps you from arguing a year later. These five points are the ones I have seen make the difference — not legal advice, for which you need someone who does that for a living, but the phrases to look for before signing.
It must say the source code is yours and that it is delivered to you. Watch for wording that grants use while retaining ownership: it is the same sentence with the opposite outcome.
The phrase to look for: “On delivery, the client acquires full title to the source code developed under this engagement, delivered in full together with technical documentation.”
Repository, servers, keys. Not on delivery: from day one. A project where you cannot see the code as it is written is a project whose state you learn only when told.
The phrase to look for: “The client has read access to the repository and development environments for the entire duration of the project.”
The most common cause of dispute is not quality: it is that the two sides had different finish lines in mind. You need a list of things that must work, written in advance, and a way to check them that is not an opinion.
The phrase to look for: “The supply is deemed complete upon passing the acceptance cases listed in the technical annex, verifiable by the client.”
A period in which defects get fixed at no cost. It need not be long: it needs to exist and be written, because it is the only difference between “we will fix it” and “that is additional work”.
The phrase to look for: “For twelve months from delivery, correction of defects attributable to development is at the supplier's expense.”
The clause nobody wants to write at the start and the only one that actually gets read, when it is needed. It must say what is handed over if the relationship ends, and within how many days.
The phrase to look for: “On termination, the supplier delivers within thirty days the code, data, documentation and credentials, providing the assistance needed for handover.”
If a supplier accepts all five without argument, that is a good sign. If they argue one of them with a reason, that is an excellent sign: it means they read it. If they reject the lot saying they are “industry standard”, ask which industry — because in custom software these five lines have been the norm for twenty years.
Three very different numbers arrive and the temptation is to sort by price. First they have to be made comparable, because they almost never describe the same thing.
It is almost never because somebody is more efficient: the gap between two experienced developers is not 60%. Usually it is one of three things — they understood a smaller scope, they intend to make it back on variations, or they have not yet grasped how complicated it is. The third is the most dangerous for both sides, because halfway through somebody will have to choose between losing money and delivering badly.
If you are assessing someone for a project, use the half-hour audit for exactly this: bring the seven questions and test me with them. They are the same ones above, and there are no different answers for whoever asks them of me.
If instead you are still at section one — it is not clear whether software is needed at all — that half hour is worth even more, because that is the question people spend worst on. And if the answer is that an off-the-shelf product will do, I will say so, as I wrote above that anyone should.
Custom web application development
Seven things, in this order: who owns the code when the project ends; who physically writes it; what happens when a requirement changes; what maintenance covers and what it costs; which proprietary components the work rests on; how progress is measured week by week; and whether there is a client with at least a year of the system in production you can talk to. The first two cost nothing to ask and filter out a great deal.
It depends on what the contract says, and silence does not work in your favour. The clause to look for assigns ownership of commissioned code to the client, with access to the repository and environments from day one, not on delivery. Without that line you can pay for a system in full and be unable to have anyone else maintain it: it is the most common way of ending up tied to a supplier you did not choose.
You make them comparable before reading them. Align the scopes, because the cheap quote usually leaves something out; add three years of maintenance to each; subtract the hours that fall on you — data entry, testing, training; and be wary of excessive precision. A figure down to the euro across six months of work is not rigour, it is an estimate presented as a certainty, and you will pay the difference in change requests.
Five: code ownership; access to environments from day one; a written definition of what «complete» means; a warranty with a stated duration; and an exit clause describing how you part ways — who hands over what, in how long, at what cost. The last is the one nobody wants to discuss at signing, and the only one that matters when you need it.