Six Questions That Tell You If Your Build Is in Trouble

Your weekly stand-up update says "on track." Your engineers seem calm. Nothing has broken publicly. And you still have the feeling — the one you can't quite justify to your cofounder — that something underneath is wrong.

You're probably right, and here's why the status report isn't going to tell you. A team that's been carrying a fragile system for months doesn't experience it as an emergency. They experience it as Tuesday. The workaround for the flaky deploy, the manual step nobody automated, the one service only one engineer understands — none of it gets reported as a risk, because from the inside it's just how the system works. Fragility that's been normalized doesn't announce itself. You have to go looking for it.

You don't need to read a line of code to go looking. You need six questions that don't ask anyone to explain the technology to you — they ask about behavior, and behavior is something you're fully qualified to evaluate.

The six questions

1. "What's the one thing only you know how to do?" Engineers call this the bus factor. Don't use that phrase out loud with your own team — ask it plainly, ask every engineer separately, and follow up with "who else could do it if you were away for two weeks?" If the same one or two names come up every time — for the deploy process, for a specific service, for "the thing with the payment integration" — you have a single point of failure that isn't on any roadmap, because fixing it doesn't ship a feature. It just prevents a future disaster.

2. "When's the last time something broke in production, and how did you find out?" Listen for the discovery mechanism. "A customer told us" or "I happened to notice" means you have no monitoring catching problems before your users do. "An alert paged us" means someone built the system to tell on itself. The gap between those two answers is the gap between a team that gets surprised and one that doesn't.

3. "How long would it take to undo the last deploy if it broke something badly?" A confident, specific answer ("ten minutes, we roll back with one command") means there's a real safety net. A vague or worried answer ("it depends," a long pause, "we'd have to figure it out") means every deploy is a one-way door, which means your team is quietly more conservative about shipping than you think they are — and that conservatism is invisible to you until you ask.

4. "What's the thing you'd fix first if I gave you two free weeks and no feature requests?" This is the least guarded version of "what's actually wrong." Engineers who name something specific and technical ("I'd rewrite the way we handle background jobs, it silently drops things") are telling you exactly where the fragility is. Engineers who can't answer, or who name something trivial, either haven't been given room to think about it or don't trust that an honest answer is safe to give you.

5. "What do you do differently because of something that broke before?" You're checking whether failures turn into changed behavior or just get patched and forgotten. "We added a check for that after the last time it happened" is evidence of a team that learns from its own incidents. "That was a one-off, we fixed it" repeated about several different incidents is a pattern of the same failure recurring in different clothes.

6. "If I asked you to onboard a new engineer next week, what would take the longest to explain?" This surfaces undocumented knowledge — the stuff that lives only in someone's head. A long, uncomfortable answer means your system's real architecture exists nowhere except inside your current team, which means you're one resignation away from losing institutional knowledge you didn't know you were depending on.

What you're actually listening for

None of these questions require you to evaluate a technical answer. You're listening for two things across all six: specificity and hesitation.

A team on solid ground answers fast, with detail, because they've thought about these failure modes before — often because they've already lived through a version of the answer. A team carrying more risk than they've surfaced to you answers slower, more vaguely, or deflects into reassurance ("it's fine, we've got it handled") instead of specifics. The hesitation itself is the signal. You don't need to understand what a background job queue is to notice that the answer to "what would you fix first" took twenty seconds of silence before it came.

Ask these of more than one person if your team is bigger than two or three engineers. A junior engineer's answers will differ from a lead's, and the gap between what a junior thinks is fine and what a lead knows is fragile is itself useful information — it tells you how much of the real risk picture has actually been communicated inside your own team.

The scar behind this list

Architecture decisions that looked clean in a design review have come back to me as production outages that paged me at 2am — the kind of feedback loop that permanently changes how you think about a system. A coupling that seemed reasonable on a whiteboard, a missing fallback that felt like unnecessary complexity at the time, a single point of failure everyone silently agreed to live with — each one looked fine until it was the reason something broke in the middle of the night, and I was the person who had to trace it alone.

The uncomfortable part wasn't the outage. It was realizing that nobody had hidden the fragility from me — I was the one who designed it, and it still hadn't occurred to anyone on the team, including me, to say it out loud. Saying "this part is held together with a workaround" feels like admitting failure rather than describing an ordinary trade-off every team makes under deadline pressure. So it goes unsaid, and the person who designed the system turns out to be the person who owns its worst night.

Design reviews optimize for elegance. 2am optimizes for recoverability. The test I apply now isn't whether an architecture is clean — it's whether your on-call can fix it at 3am without the person who built it. You find out whether you have that by asking. Otherwise the outage tells you, and it charges for the answer.

What to do with the answers

You're not trying to catch your team doing something wrong. Carrying some fragility is normal — every real system has a few things nobody's proud of, because building anything under real constraints means making trade-offs you'll revisit later. The point of asking is to convert invisible risk into a known, prioritized list, instead of finding out about it during an outage in front of a customer or an investor.

Once you have honest answers, you have a real conversation to have with your team: which of these risks are worth fixing before you scale further, and which are fine to carry a while longer. That's a resourcing decision, and it's yours to make — but only once you can see the list. Right now, without asking, you can't.

When the answer to question 4 comes back as a cleanup request with a time estimate attached, that's the next decision, and it has its own pricing method: how to tell real technical debt from a nice-to-have dressed up as urgent. If the answers instead convince you the team itself is the gap, the hiring conversation runs on the same principle as these six questions — ask about a failure, not about the technology.

Your next step

Pick two of these six questions and ask them at your next 1:1 with your lead engineer, before your next stand-up. Listen for hesitation more than content. If what comes back sounds bigger than you can evaluate alone, I do a few free second opinions a month for founders trying to read technical risk they can't assess themselves — no pitch, nothing to buy afterward. hello@ruchitsuthar.com.

Frequently asked questions

How do I know if my development team is doing a good job without being technical?

Ask behavior-based questions instead of technical ones: what would nobody else be able to fix, how they find out when something breaks, how long a rollback takes, what they'd fix first with free time, what they've changed after a past failure, and what would be hardest to explain to a new hire. Listen for hesitation and vagueness — that's the signal, not the technical content of the answer.

How can I tell if my startup's codebase is in trouble?

You usually can't tell from a status report, because a team that's normalized fragile parts of the system won't flag them as urgent — it's just how things work day to day. Direct, specific questions about failure history, rollback confidence, and single points of failure surface the risk without requiring you to read any code.

What questions should I ask my developers to check on progress?

Beyond status updates, ask about production incidents (how discovered, what changed afterward), rollback speed, bus-factor risk (who's the only person who understands a given part), and what they'd prioritize fixing with unstructured time. These reveal operational health that "on track" status reports don't capture.

Is it normal for a startup's tech to have some fragile parts?

Yes. Every real system carries trade-offs made under deadline pressure, and that's not automatically a red flag. The goal of asking these questions isn't a perfect answer — it's converting invisible risk into a known, prioritized list you can make a resourcing decision about, instead of discovering it during an outage.

What's a single point of failure and why should a founder care?

It's any part of your system, or any person, that things depend on with no backup — one engineer who's the only one who understands the deploy process, one service with no fallback if it goes down. If that person leaves or that service fails, you lose function you didn't know you were relying on. It's one of the cheapest risks to surface early and one of the most expensive to discover during a crisis.