Hiring an App Developer? Two Questions Every Founder Should Ask First

You are about to commit between R 100,000 and R 500,000 to a software build. Most founders make this decision the way they would choose a contractor for a house renovation: references, a price quote, a portfolio of past work, a gut feel for the team. Those signals are not wrong, but they are not enough. In 2026 they will miss the single biggest risk in your project.

The risk is no longer that the developer cannot code. AI has made writing code cheap. The risk is that the team in front of you can produce code without being able to engineer software, and you will not learn the difference until your launch breaks in front of real users.

The good news is that you can detect this in a thirty-minute conversation, with two questions. They cost nothing to ask, and a team that cannot answer them well is showing you the future you will be paying for.

Question 1: When this breaks, do you know how to fix it?

Note the word when. Not if. Software in production breaks; that is not a failure of the developer, it is a fact of the medium. Networks drop, third-party APIs change their response shape, a payment provider returns a status code your code never anticipated, a user does something nobody on your team thought to test. Every team that has shipped real software has felt this on a Friday afternoon.

The question is not whether your dev team can prevent every break. They cannot, and any team that promises they can is selling you something. The question is whether they will know what to do when it happens, and whether the system they are building you actually gives them the tools to find out.

What a good answer sounds like

A team that has shipped real software answers this question with specifics. They will walk you through how they would diagnose a production issue. They will mention the things you cannot see from the outside: structured logging, error tracking, performance monitoring, the ability to reproduce a bug in a staging environment, the fact that they have an alert that fires when a key metric drifts. They will probably tell you a story about a time they handled a real incident.

A senior developer who genuinely understands the system they have built can do something powerful: they can sit in front of an unknown bug and reason about where it might live, narrow it down, and fix it. That ability comes from understanding the architecture deeply, not from knowing the syntax of the language.

What a bad answer sounds like

Vague reassurance. “We will fix any bugs.” “Don’t worry, we are good at debugging.” No specifics about monitoring or logs. No mention of how the team would tell that something had broken in the first place. Most of all: an over-reliance on the team’s AI tools to diagnose problems they themselves did not architect.

This is the vibe-coding problem in a sentence: when AI builds the system and the human dev does not fully understand the code that was generated, the whole structure is a black box. When the black box breaks, as it always does, there is no one in the room who can confidently fix it. The team reaches for the AI tool that built it, hoping the AI will also know how to heal it. Sometimes that works. Often it does not, and the cost of finding out is yours.

Question 2: Can you prove it won’t break in production?

This question goes deeper than the first. Anyone can claim they will fix a bug. Proving a system will not break under conditions that have not happened yet is a different kind of work: it is the work of engineering.

“Working code” and “production-ready code” are not the same thing. Code that runs on a developer’s laptop, with their single test user, with perfect Wi-Fi and valid email addresses, is the easiest possible test of software. Production is when fifty people click Submit at the same time, the internet drops in the middle of a payment, the user types an emoji into a field that did not expect one, and a 5 GB PDF gets uploaded as a profile picture. Production is what the QA team simulates on a Tuesday so a real user does not discover it on a Friday.

What a good answer sounds like

A team that has shipped to production will describe a testing strategy. They will distinguish between unit tests (the small pieces), integration tests (the pieces talking to each other), and end-to-end tests (the whole user flow). They will mention staging environments, automated test suites that run on every change, manual QA passes before a release, performance testing under simulated load, and a deployment pipeline that does not let broken code reach production by accident.

They will also be honest about the limits. Nothing makes software unbreakable. What separates engineered software from vibe-coded software is not that one cannot break. It is that one has a system designed around the expectation that it might, and the other has a hope.

What a bad answer sounds like

“We tested it manually.” “It runs without errors on our machine.” No tests committed to the repository. No staging environment separate from production. No CI/CD pipeline that would catch a regression before deployment. A team that points at the LLM and says “the AI wrote the tests too” without being able to tell you what the tests actually verify.

Generated code that runs without an error message is not the same as code that has been engineered to survive contact with real users. An LLM does not care if a loop is O(n²) and will destroy your CPU at scale. It does not care if a dependency it imported has a known security vulnerability. It does not care if the architecture it produced is fundamentally wrong for the problem you are actually solving. It is completing a pattern, not engineering a system.

Why these two questions, together

The two questions test different things. The first tests understanding: does this team genuinely know the system they have built, deeply enough to reason about it when it misbehaves. The second tests discipline: does this team have the engineering practices that make a system safe to ship and safe to maintain.

Neither can be faked with a confident demeanour. A team that has only ever built prototypes will struggle with both. A team that has shipped real software to real users. A team that has been on the other end of a 2am production incident, that has rolled back a release because monitoring caught something ten minutes after deployment, answers both questions with the kind of specificity that comes from scar tissue.

Ask both questions. If the answers are vague, your project is at risk before the contract is signed. If the answers are specific and grounded, you are probably in the right room.

How we answer them at Pocket Dev

We use AI tools every day. We are not anti-AI. We are anti-pretending that AI removes the need for engineering judgment. The difference shows up in every decision: architecture before code, testing as we build rather than as an afterthought, monitoring designed in from day one, code structured so that a human (us, or whoever maintains the system after us) can understand and change it.

When a founder comes to us with a vibe-coded prototype that has started to crack, the work we do first is not building: it is diagnosing. What got built. What it actually does. Which parts of the architecture will hold and which parts need to be rebuilt before features get added on top of them. That diagnostic is the Project Blueprint, a fixed-price, two-week engagement that produces a clear answer to the same two questions above, applied to your specific codebase, before you commit to a full build or rebuild.

Before your next dev meeting

You do not need to be technical to use these two questions. You need to listen to the shape of the answer. Specifics are good. Stories are good. Honest acknowledgement of the limits is good. Vague reassurance is the warning sign.

And if you have already signed a contract and the project is in flight, the questions are still useful. Ask them in your next review meeting. The answers you get will tell you something true about what you are paying for.