This article is part of our Journal archive. Any prior offers reflect its publication date. Read our current services and approach.
You are being asked to buy work you have no way to inspect. Here are six checks a non-technical buyer can actually run, and the one that beats all the others.
Buying software is strange in a way that buying almost nothing else is. If you hire a contractor to redo your kitchen, you can walk into a house they finished and open the cabinets. If you hire a developer, you get a portfolio of screenshots, a confident conversation, and a number. The actual product is invisible until you have paid for it.
The usual advice is to check references and look at their past work. That advice is thin. A portfolio proves someone shipped something once, with a client who may have had a bigger budget, a clearer idea, and more patience than you. References are self-selected. Neither tells you what will happen on your project, with your constraints, when something goes wrong at week six.
Here is what does tell you, in rough order of how much it is worth.
One: ask to see something working before you pay
This is the strongest signal available to you, and it makes the other five almost unnecessary.
Anyone can write a proposal. Proposals are cheap, and the people who write the best ones are often the people who spend the most time writing proposals. Very few can take a rough description of your business and come back with a working, clickable thing on a real URL in a matter of days.
So ask. Ask whether they will build something first, something small and real, before you commit money. Pay attention to how they react. If the answer is a flat no, that is not automatically disqualifying, but it should make you ask why. If the answer is a Figma file or a slide deck, understand that you are being shown a picture of software, not software. A picture cannot be wrong in the way that a build can be wrong, which is exactly why it is easier to produce.
We build a prototype before a client pays anything, so we are obviously not neutral here. But the reason we do it is the same reason you should ask for it: it converts a promise into evidence, and evidence is the only thing you can actually judge.
Two: ask who writes the code, and get a name
Small agencies sell you the founder and staff the work with whoever is available. Larger ones sell you a senior team in the pitch and hand you a junior one after signing. This is so common that it has a nickname in the industry, and there is no polite way to say it: the people who impressed you are frequently not the people who will do the work.
Ask directly. Who writes the code. What else are they working on while they write mine. Who do I talk to when something breaks at four in the afternoon on a Friday. You want a name and a straight answer, not a description of a process.
Three: ask what happens when you leave
Every engagement ends. The question is what you are left holding.
Ask who owns the source code, and get it in writing. Ask whose name is on the domain registration, the hosting account, the analytics, the app store listing. Ask what it would take for a different developer to pick this up cold, and how long it would take them to get oriented.
A developer who has thought about this will answer easily, because building for handoff is a habit, not a favor. A developer who gets uncomfortable is telling you something important. Software you cannot leave is not an asset. It is a subscription with extra steps.
Four: make them explain one decision in plain words
Pick any technical choice they have mentioned and ask why. Why that framework, why that host, why a database instead of a spreadsheet, why an app instead of a website.
You are not checking whether the answer is right. You could not check that, and you do not need to. You are checking whether they can hold a technical idea and a business reason in the same sentence. The good answer sounds like "it costs less to run and your team can update it without me." The bad answer is a list of technologies, or a tone that suggests you should not have asked.
The ability to explain is not a soft skill here. Someone who cannot explain a decision to you cannot explain it to themselves, and you will pay for that later, in a system nobody can reason about.
Five: ask what they would talk you out of
This one is quick and it separates people fast.
A developer who agrees with everything you say is selling. You want to hear a real objection, ideally about something you already suspected: that the feature you are attached to is not worth the money, that the app you asked for should probably be a website, that the phase-two idea should be phase four or never.
The willingness to shrink the project in front of you, before the contract, is the closest thing to a character reference you will get. It costs them money to say it. That is precisely why it means something.
Six: watch the speed and quality of the small things
Before any money changes hands, you already have data. How fast did they reply. Did they answer the question you asked or the one they wanted to answer. Did the notes after your call match what was actually said. Did they follow up on the thing they said they would follow up on.
This is the most attentive they will ever be, because they are trying to win you. If the pre-sale version is already slow or vague, that is your ceiling, not your floor.
A note on price
Price tells you less than people expect. The cheapest quote often reflects someone who has not understood the work yet, and the gap gets closed later through change orders or through corners you cannot see. The most expensive one may be buying you a project manager, an office, and a sales team rather than more engineering.
What matters more is whether the number is attached to something specific. A fixed price against a scope you have read and understood is a commitment. A fixed price against three vague bullet points is a guess wearing a suit, and you will meet the guess again at invoice time.
The short version
If you only do one thing, do the first one. Ask to see the actual thing, working, before you pay for it.
That is the standard we hold ourselves to, and we mean it broadly: a website, a mobile app, enterprise software, an internal tool, an AI workflow. We build it first, you click it, and you decide from there. No obligation, no money down. If it is not right, you owe us nothing and you have lost only the time it took to look.
You should ask that of anyone you are considering, including us.