Helper CTO Series 12 | How a Non-Technical Owner Can Tell If an Engineer Is Right

"He talked for twenty minutes about switching the whole system to a new framework. I didn't understand a word, but I didn't want to say no." The cost of nodding along without understanding shows up six months later: the money's spent, the time's gone, the system isn't any better, and you can't even say what went wrong. You're not lacking intelligence — you just don't have a set of questions you can ask on the spot. The following five questions require no technical background and can be used in any technical discussion.

You Don't Need to Understand Technology — You Need to Know How to Ask

Let's clear up a misunderstanding first: judging an engineer isn't a technical exam. Advice that's completely correct from a technical standpoint can still be the wrong call for your company:

• Too expensive: the approach itself isn't wrong, but it costs more than the problem it's solving is worth.
• Too early: your current scale doesn't need it at all, and by the time you actually do, the right approach might be different anyway.
• No one's watching it: once it's built, no one owns it, and a few months later it becomes another corner of the system nobody dares to touch.

So the question isn't "Is this the right approach?" It's "Is this worth it for our company, where's the risk, and who's responsible afterward?" The article Non-Technical Owners Can Still Manage Outsourcing Well already covered pinning down the goal and setting milestones. This one goes a step further and gives you five questions you can ask directly.

Five Questions, One Table

Here are the five questions alongside what a good answer should sound like. When your mind goes blank halfway through a discussion, just work through this table:

You don't need to remember the reasoning behind each question — just remember that a good answer contains three specific things: a specific person, a specific timeframe, and a specific fallback.

The First Three Questions: Cost, a Smaller Approach, Who Maintains It

The first three questions ask about three sides of the same thing: if you go through with this, who's carrying the risk?

• Cost: any piece of advice can turn out to be wrong. What matters is whether they've thought through what happens if it does, and whether you can back out within two weeks.
• A smaller approach: engineers naturally want to do things completely, and complete usually means expensive and slow. Rewriting just the most-used page first is often enough.
• Who maintains it: a finished feature will break, will need updates, and someone will ask how to use it. If they can't say who owns that, the proposal is only counting half its real cost.
• You can ask all three in a row: it's not impolite — it actually shows the other side that you care about the long run, not just the quoted price.

Someone willing to find a smaller approach for you is saving you money; someone who insists on doing it all at once deserves one more "why."

The Last Two Questions: Not About Skill, but About Whose Side They're On

The last two questions are sharper. They're not about technical skill — they're about whose side this person is really on.

• "Would you do it this way yourself?": ask directly whether they'd spend the money this way if it were their own company and their own money. Most people pause, then give you a more honest answer than before.
• "If you left tomorrow, could the next person understand this?": follow up by asking whether records are kept, whether the code lives under the company's own account, and whose name the server and domain are registered under.
• You don't need to force an answer on the spot: what you're watching for is the reaction. Someone willing to shift perspective and proactively get things organized is worth a long-term relationship.
• Ask both questions face to face: ask over a message and you'll get a polished paragraph back; ask in person and you'll actually see that pause.

These two questions are the best filter for people who build it and walk away.

Why Someone Would Ask These Questions for You

You can ask all five questions, but most owners eventually get stuck, because they can't judge the answer underneath the answer: when someone says "we can roll it back," you don't know if that's actually true; when they say "I'll keep records," you don't know if those records are good enough. That's exactly where Helper CTO fits in — someone on your side who understands that next layer. The article What Is Helper CTO explains it further: it's like an in-house technical lead, just not on your payroll. As for whether to hire someone full-time or bring in outside help, there's a separate article on how to weigh that cost.

What Nerdtechnic Listens for on Your Behalf

• We work out the cost before we give advice: every technical decision is explained upfront — what happens if you do it, what happens if you don't, and whether you can back out.
• The same team handles it start to finish: taking over, maintaining, improving, and continuing development — whoever gives the advice is also the one who stays accountable for it.
• Our health check has only three possible conclusions: take it over as-is, clean it up first, or a rebuild would actually be cheaper — never a vague answer.
• Documentation and records stay with you: the engagement ending never turns into a black box — you always keep a second option.

You don't need to become a technical expert yourself. You need someone who doesn't leave you stuck choosing between trusting everything or trusting nothing.

The most reliable way to tell whether an engineer is telling you the truth is having someone beside you who listens on your behalf. Nerdtechnic takes over and maintains your system long-term as your Helper CTO. The first step is a 60-minute system health check: we only need to see your code, no production credentials required, and within 3–5 business days you'll get a one-page report you can actually understand. If you're stuck on a technical proposal you can't make sense of, bring it with you, and we'll walk through these five questions with you: Helper CTO: System Maintenance Plan.