How do I know if a developer is any good if I'm not technical?

Question

VX-N · Accepted Answer

You cannot assess their code, so assess their reasoning. A good developer explains the tradeoff in plain language, tells you what they are not going to build, and gives you a smaller first milestone rather than a single large one. Confidence without caveats is the warning sign. Ask for a small paid first step — a plan, a mock, a working demo of the riskiest part. What comes back tells you more than any interview, and it caps your exposure if the fit is wrong. A developer who resists a small first milestone and pushes for one large contract is asking you to take all the risk before either of you has seen how the other works. Listen for what they refuse. A good developer will tell you which parts of your idea should not be built at all — the feature a cheaper tool already covers, the requirement that doubles the cost for a case that happens twice a year. Someone who says yes to everything is not agreeable; they either have not thought it through or plan to bill for the discovery later. The same applies to estimates: anyone who quotes a firm price without asking how your process actually works is guessing, and you will pay for the gap between the guess and reality. There are three questions any serious builder answers cleanly in writing: who owns the code and the accounts when the project ends, what happens when an integration breaks six months from now, and what they would do differently if the budget were half. Vague answers to any of those are the whole answer. The ownership question in particular separates builders from landlords — an arrangement where the developer holds the hosting, the repository, and the API keys converts a one-time build into permanent leverage over you. The other reliable tell is documentation. If nobody but them can understand how the thing works — no written logic, no explanation of what talks to what, credentials scattered across their personal accounts — you have hired a dependency, not a developer. You do not need to read code to check this: ask them to walk you through how a record moves through the system, and see whether the explanation survives your follow-up questions. Finally, look at what they have running, not what they have designed. Portfolio screenshots prove taste; a system that has survived two years of real use, real data, and real users proves engineering. Ask to speak to one client whose system is still in production. The way that client describes the handoff — smooth and documented, or dependent and anxious — tells you what your own year two will look like.