“Anyone can look competent in a sales call. The proof shows up three weeks into the build when the first real problem appears.”
The gap between presentation and performanceWhy This Is Harder Than It Looks
Hiring a developer when you're not technical is one of the highest-stakes judgment calls a non-technical founder makes. The challenge is that the usual signals of competence - confident presentation, polished portfolio, fast response times - are things anyone can fake for long enough to get hired.
The indicators that actually predict whether a developer will deliver something production-quality, on time, and maintainable are less obvious. This post walks through what to look for before you sign, and what to watch for in the first two weeks of an engagement so you can course-correct before significant money is spent.
None of this requires you to be technical. It requires you to ask the right questions and know what a good answer looks like versus a vague one.
Start With Their Questions, Not Their Portfolio
A strong developer asks more questions than they answer in the first conversation. They want to understand your business goal, not just the feature list. They'll ask who your users are, what the core action is that drives value, what the product needs to do in 6 months that it doesn't need to do today.
A developer who launches straight into tech stack recommendations or timelines before they fully understand the problem is optimizing for speed of proposal, not quality of solution. That pattern tends to continue through the entire engagement.
Weak discovery also leads to the most common and expensive development failure: building the right features in the wrong order, or building features the users don't actually need. A developer who asks good questions is protecting your budget even when it feels like they're slowing you down.
How to Read a Portfolio Without Technical Knowledge
You don't need to understand the code to evaluate a portfolio. What you're looking for is evidence of shipped work, not polished mockups. Ask to see products that are live and accessible - apps you can open in a browser or download from the App Store. Screenshots of Figma designs are not evidence of a shipped product.
When you look at live work, try it the way a real user would. Does it load in under 3 seconds? Does it work on your phone? Is the flow intuitive? Poor UX in a developer's own portfolio work is a strong signal about how they'll handle yours.
Ask specifically: "What was the hardest technical problem on this project and how did you solve it?" A developer who can answer that question clearly - with specifics, not generalities - understands their own work. One who gives you a vague "it was complex but we figured it out" probably didn't lead the solution.
The Proposal Is a Test
A good proposal demonstrates that the developer read and understood your brief. It references your specific use case, names your target users, and explains why they're recommending a particular technical approach for your situation - not a boilerplate stack they use for everything.
Watch for these warning signs in proposals: a timeline with no buffer for feedback rounds or revisions; a fixed price for a scope that clearly requires discovery before it can be accurately estimated; deliverables described in output terms ("we'll build a dashboard") rather than outcome terms ("users will be able to view and export their usage data").
Also check whether the proposal includes a payment schedule tied to milestones rather than time. A developer confident in their own delivery will structure payments to milestones. One who insists on large upfront payments before any work is reviewed may be managing their cash flow at your expense.
What to Watch in the First Two Weeks
The first two weeks of a development engagement tell you almost everything. A strong developer sets up version control immediately, commits code regularly with clear messages, and sends you a link to a staging environment within the first sprint. You should be able to see real progress, not hear about it.
If two weeks pass and you have no staging environment, no repository access, and only reassuring messages about how things are "going well," that's a pattern. The developers who deliver on time are almost always the ones who are visible from the start - not because they work faster, but because they've built the feedback loops that prevent late surprises.
Pay attention to how they handle the first problem. Every project hits unexpected complexity somewhere. A mature developer surfaces it early, explains the impact clearly, and presents options with a recommendation. One who goes quiet, overexplains, or asks for more budget without clear justification is showing you their problem-resolution style under real conditions.
Questions That Separate Good Developers From Average Ones
- "What would you build differently if budget weren't a constraint?" - reveals whether they're thinking about your product or just their scope
- "How do you handle scope changes mid-project?" - look for a clear process, not "we're flexible"
- "Who else on your team will touch this project?" - many agencies sell a senior developer and deliver a junior one
- "What does handoff look like? What documentation will I receive?" - great developers plan for the day after launch
- "Can I speak to a past client in a similar industry?" - any hesitation here is worth noting
- "What happens if I'm not happy with the work at the end of a sprint?" - the answer reveals how they handle accountability
The Rescue Signal
One of the clearest signals of a genuinely good development team is whether they've ever successfully rescued a project. Taking over a half-built codebase, diagnosing what's broken, stabilizing it, and shipping it to production is significantly harder than starting from scratch. Agencies that have done it well understand architecture at a level that prevents those failures in their own new builds.
At Zovintra, a meaningful part of our work is exactly that - picking up apps that founders started with Lovable, Bolt, v0, or a previous development team and getting them across the finish line. That experience shapes how we scope, how we document, and how we think about maintainability from the first line of code on a new project.
If you're evaluating agencies right now and you'd like a second opinion on a proposal you've already received - or a review of a codebase you've inherited - that's a conversation worth having before you commit to the next stage of investment.
