TL;DR: Most advice on hiring a developer tells you to check reviews and ask for a portfolio. Both are easy to fake. The eight checks below ask for artifacts a developer can only produce if they actually work the way they claim, and each one tells you what to do when the answer is bad.
You can't evaluate code. That is the whole problem, and every piece of advice that ignores it is useless to you.
The standard guidance says look at their portfolio, read their reviews, check their GitHub. A polished portfolio proves someone can build a portfolio. Reviews on a directory come from clients who also couldn't evaluate the code. GitHub is unreadable unless you write software.
So the checks below don't ask you to judge quality. They ask the developer to produce evidence of how they work, and evidence is much harder to fabricate than a case study. Every check has a failure mode and an escalation, because knowing a red flag exists is worthless if you don't know what to do when you see one.
Before you start: write down the one process in your business that the software has to fix. One sentence. If you can't, no developer can help you yet, and the ones who take the project anyway are the ones you're trying to avoid.
1. Ask what they build when nobody is watching
Request a written plan from a recent project. Not a proposal, which is a sales document. The internal document that says what will be built, in what order, and what could go wrong.
Shops that plan in writing produce these constantly. Shops that improvise cannot produce one, because it does not exist.
For reference, our own platform has 11 written execution plans in its docs folder covering work from April through July 2026, each one written before the code. That is not unusual for a team that works this way. It is table stakes.
Failure mode: they send a sales proposal instead, or say plans are "internal." Escalation: ask for one with the client name redacted. A refusal to show a redacted internal document usually means there isn't one. Ask them to write a one-page plan for your project before you sign anything, and treat the quality of that page as the audition.
2. Ask how they decide something is finished
The answer you want involves tests. Automated tests are code that checks the other code still works, and they are the difference between a change that ships safely and a change that breaks three things nobody noticed for a month.
Ask how many automated tests the last project had, and what happens when one fails.
Our platform carries 99 test files, and a failing test blocks the release. That number matters less than the fact that it can be answered instantly.
Failure mode: "we test everything manually before release." Escalation: manual testing is fine for a small build, but it will not scale past the second change. Ask specifically what happens six months in when a small fix silently breaks an old feature. If they have no answer beyond "we'd fix it," price ongoing breakage into your budget, because you are buying it.
3. Ask what they do about security before they write code
Not "is it secure," which everyone answers yes to. Ask what document exists about security for a specific feature, and when it was written relative to the code.
The order is the tell. Security thought through before the build gets designed in. Security considered after gets bolted on, and bolted-on security is the kind that fails.
We write a threat model for anything touching data or money before building it. There are 144 of them in the repository. When we built the client drawing review feature, the threat model is dated 11 July 2026 and the feature reached production ten days later, which meant the eleven risks it identified were designed against rather than discovered live.
Failure mode: vague reassurance, or a claim that the platform handles it. Escalation: name a specific risk in your own project and ask how they'd handle it. If you're storing customer records, ask what stops one customer seeing another's data. A developer who cannot answer that in plain language on the spot has not thought about it, and you should ask for it in writing before signing.
4. Ask who owns the code and where it lives
Ask three questions with one-word answers: Whose account holds the repository? Whose name is on the hosting? Whose name is on the domain?
Every one should be yours. If a developer holds any of them, leaving costs you a negotiation.
Failure mode: "we host everything for our clients, it's simpler." Escalation: it is simpler, and it also hands them a bargaining chip for the day you want to leave. Accept it only if the contract says the accounts transfer to you on request within a fixed number of days, at no cost. Get the number written down. If they won't commit to one, that is the answer.
5. Ask what happens when you change your mind
You will change your mind. The requirement you describe in month one will be wrong by month three, because you will see the thing working and understand it better.
The question is whether that is a crisis or a Tuesday.
Ask how the last project handled a mid-build scope change, and what it did to price and timeline. You want a specific story, not a philosophy.
We killed an entire module partway through ours. The roofing configuration originally included a quoting tool, and we removed it in April 2026 once it was clear roofing work needs photographs and explanations that a quote line item cannot carry. Proposals replaced it. That was a real reversal on shipped work, and it was the right call.
Failure mode: "changes are handled by change order" with no example. Escalation: ask what the smallest change order they've ever issued was. If everything triggers one, you have found a shop that profits from your uncertainty. Negotiate a defined allowance for revisions inside the base scope before signing.
6. Ask them to explain your own business back to you
At the end of the first call, ask them to describe your workflow in their words.
This is the single highest-signal moment in the process and it costs nothing. A developer who has listened will describe your process with the specific vocabulary of your trade and will get the sequence right. One who hasn't will describe generic software.
Industry experience matters less than most people think. Attention matters more. Someone who has never touched your vertical but repeats your process back accurately will serve you better than someone with ten projects in your industry who is pattern matching from the last one.
Failure mode: they describe features instead of your workflow. Escalation: correct them once and see whether the correction sticks in the next conversation. If you have to explain the same thing twice, you will be explaining it for the length of the project, and the finished software will reflect their assumption rather than your operation.
7. Ask what they'd refuse to build
A developer who agrees with everything is selling, not advising.
You want to hear something like "that feature will cost more than it saves you" or "do the simple version first and see if anyone uses it." Pushback in the sales conversation is the best available proxy for judgment during the build, because during the build is when it actually costs you.
Failure mode: enthusiastic agreement with every idea you raise. Escalation: propose something deliberately over-engineered and see what happens. Ask for something you don't need, phrased confidently. If they take the order without a question, you have learned what the whole project will feel like.
8. Ask what happens if they disappear
The most common bad outcome in small software projects is not fraud. It is silence. A developer gets busy, takes a bigger client, and your project drifts.
Ask two things: who else at the company knows this project, and what you receive if work stops.
Failure mode: a single freelancer with no backup and no answer. Escalation: this is not automatically disqualifying, because good solo developers exist and often beat agencies on cost and attention. It does mean the contract must include a code handover schedule, work delivered to your repository at agreed intervals rather than in one lump at the end, and a defined response window with what happens if it lapses. Freelance versus agency is less about capability than about what happens on the bad day.
What good looks like when you're done
You should be able to answer these without asking the developer again: where the code lives, who can access it, what proves it works, what happens when you want a change, and what happens if the relationship ends.
If all five have clear answers before money moves, you have removed most of the risk that is removable. The rest is the ordinary risk of building something, which is real and which no checklist eliminates.
One useful piece of context on that risk. The Standish Group's CHAOS research, which surveys IT executives on project outcomes, reported 31% of projects successful, 50% challenged and 19% failed in its 2020 data, against 16.2% delivered on time and on budget when the survey began in 1994. Worth knowing that the underlying dataset is proprietary and has drawn academic criticism, so treat it as an industry survey rather than an audited fact. The direction is still the useful part: most software projects do not go smoothly, and the ones that go worst are usually the ones where nobody agreed what "finished" meant.
Frequently Asked Questions
Should I pay a developer upfront or on completion?
Neither in full. Milestone payments tied to working deliverables are the norm, with a deposit to start. What matters more than the split is what each milestone actually delivers. "Design phase complete" is not a deliverable you can verify. "Login and customer list working on a URL I can open" is.
How do I compare quotes when they're wildly different?
They are usually quoting different scopes rather than different prices. Send all bidders the same one-page description and ask each to list what they have assumed. The assumptions will differ more than the numbers, and that is the actual comparison.
Is it a problem if a developer wants to use a no-code tool or AI to build it?
Only if they hide it. The relevant questions are whether you can still get your data out, whether you can hire someone else to work on it later, and what the tool costs monthly forever. A build that is cheap to make and impossible to leave is not cheap.
How long should vetting take before I commit?
Two conversations and one document. If a developer will not produce a written plan for your project after two calls, that is your answer, and it arrives cheaply.
Do I need a technical person of my own to manage this?
For a single-workflow build, usually not, if the checks above are answered in writing. For anything touching payments, customer records, or multiple integrations, an independent technical advisor for a few hours at the contract stage is cheap insurance against a bad structure you cannot see.
If you can name the process you want fixed, that is the entire first conversation. We will tell you honestly whether it is worth building, whether something off the shelf already does it, and what the real scope looks like.
See custom app development or start a discovery call.
Sources
- The Standish Group, CHAOS research on IT project outcomes — 1994 baseline of 16.2% delivered on time and on budget with 31.1% cancelled; 2020 figures of 31% successful, 50% challenged, 19% failed. Underlying dataset is proprietary and has been academically contested. opencommons.org (retrieved July 2026)
- ClickWerxs platform repository — 11 execution plans, 144 STRIDE threat models, 99 test files, 1,024 commits between 6 April and 22 July 2026; drawing review threat model dated 11 July 2026 with the feature in production 21 July 2026; roofing quoting module removed in favour of proposals, April 2026. First-party operator data.
ClickWerxs builds custom software for businesses and earns revenue from those engagements. This post reflects our direct experience building and operating our own platform, not independent third-party research. Cost and outcome figures cited from third-party surveys are attributed and dated; verify current figures at the source before relying on them. This is operator opinion and not legal or financial advice.
Kaleb Dickhaut — Founder, ClickWerxs. Kaleb built ClickWerxs from the ground up, from payment processing ISO to the Command Center platform to the AI SEO methodology the blog runs on. He has onboarded hundreds of small businesses onto payment and CRM systems. linkedin.com/in/kaleb-dickhaut