There is an old restaurant rule: if You want to know what the kitchen is like, look into the restroom. If it is clean, the kitchen is most likely in order too. If the mirror has three-day-old streaks, no truffle menu will save You. The rule is crude but very accurate, because culture cannot be selective. It is either everywhere or nowhere.
The same works with IT contractors. The quality of a future system is visible long before the first line of code is written. It shows in how they talk to You, what questions they ask, how they write emails and how they behave when You disagree with them. For many years I have sat on both sides of this table: I sell Ingello's services and I hire contractors for individual tasks myself. And the longer I do it, the less I look at presentations and the more I look under the hood.
The first conversation: who asks the questions
A good doctor first takes your history and only then prescribes. A bad one writes out pills while You are still taking off your coat. In development it looks like this: a strong contractor asks more than he tells in the first conversation. He wants to know how your processes work today, who will use the system, what hurts most, where the money comes from and where it leaks.
If the whole first call is spent telling You about themselves, their technologies, their awards and how they "did something similar for a big bank", that is a warning sign. A person who asked no questions cannot know what You need. So he will sell what he knows how to make, not what You require. I sometimes joke that a contractor with a ready answer for everything simply has not understood the question yet.
Pay attention to the awkward questions too. A good contractor will definitely ask what You did not think of or were afraid to think of: who will maintain the system in a year, what happens to the data if the vendor changes, who makes decisions on your side and how long that takes. This is not nitpicking. It is a sign that the person is already building your system in his head and has bumped into its weak spots.
The email after the meeting
My favourite test is very simple: what arrives after the first meeting. If nothing, that is bad. If it is "thanks, it was nice talking, we look forward to your spec", slightly better, but not by much. If it is a short summary of what they understood about the task, what risks they see, which questions remain open and what the next step is, then You are dealing with people who know how to work with information.
Software development is eighty percent about transferring meaning between people and only twenty percent about writing code. Someone who cannot neatly record a one-hour conversation will not neatly record six months of requirements either. And lost requirements are what kill projects most often, far more often than difficult algorithms.
What the estimate looks like
The next checkpoint is the proposal and the estimate. It is easy to go wrong here, because the eye catches on the total. Look at the structure instead. A good estimate is broken into clear parts: stages, modules, approximate effort for each. It states honestly what is not included. It contains assumptions: "we assume the bank integration is done through a standard API". And it names the risks out loud.
A one-line estimate like "CRM development: 15,000 dollars, 3 months" only tells You that someone made the number up. It may even turn out right, but You will never know until it is too late. Like a builder who quotes the price of a house without looking at the plot: he might guess, but it is better to pour the foundation with someone who checked the soil first.
A small paid stage instead of a big leap
The most reliable way to check the quality of a service is to start with a small piece of paid work. At Ingello we almost always suggest beginning with an analysis stage or a prototype: a couple of weeks, a clear result, moderate money. For the client it is a chance to see us in action before trusting us with a big budget. For us it is a chance to understand whether we can work with this client. It is like a test drive, only more honest: You drive not around the dealership but along your real route.
At this stage, watch for the following:
- Whether agreements on timing are kept, even small ones: they promised to send it on Tuesday, and it arrived on Tuesday.
- Whether You see intermediate results or everything is shown only on the last day.
- How the contractor reports problems: in advance and with options, or when everything has already burned down.
- Who actually does the work: the people You talked to during the sale, or performers You learned about by accident.
- Whether the result is understandable to someone who did not attend the meetings.
The disagreement test
I also recommend checking how the contractor reacts to disagreement. Deliberately challenge one of his proposals. A good specialist will neither take offence nor give in immediately. He will explain his position with arguments, and if yours turn out stronger, he will honestly admit it. A bad one will do one of two things: either argue on the level of "we know better", or instantly agree with anything just to keep You happy.
The second option is more dangerous, even though it looks nicer. A contractor who agrees with everything will not protect You from your own mistakes. And You, like any client, will certainly make some, because You are not obliged to understand database architecture. You need a partner who at the right moment will say "NO, do not do it this way, and here is why".
A contractor's culture cannot be selective. If the email is sloppy, the code will be sloppy too.
What to do tomorrow
If You are choosing a contractor right now, make yourself a short checklist from this article and go through it with each candidate: how many questions they asked, what they sent after the meeting, how the estimate is structured, what they agree to in a small first stage. Compare answers, not prices. After a week of this kind of checking, the picture usually becomes so clear that the decision almost makes itself.
And do not hesitate to check us the same way. At Ingello Systems we are used to it and, frankly, we trust clients who check more. They are much easier to work with later, because they understand what they are paying for.
