How to Run a Code Review When You Cannot Read Code

What you need to know

• A code review for a non-technical founder is primarily a behavioral review and a documentation review, not a syntax review.
• The demo is the most reliable signal of whether the feature is complete. A feature that cannot be demonstrated working end to end by the developer is not done.
• Documentation completeness is checkable by anyone. If the developer cannot explain what they built in plain language, or if the repository lacks the documentation for another developer to continue the work, the delivery is incomplete.
• Asking for tests on the core user workflows is a reasonable and non-technical requirement. You do not need to read the tests. You need to know they exist and run.
• The questions you ask in a code review shape the developer's behavior in the next sprint. Ask for clarity, completeness, and documented decisions.

The core argument

The non-technical founder who avoids code reviews entirely leaves the quality bar entirely to the developer's judgment. That is fine when the developer's judgment is excellent and fully aligned with the product's long-term needs. It becomes a problem when the developer takes shortcuts under time pressure, assumes certain things do not need documentation because they seem obvious, or produces code that works today but is fragile under the changes that will inevitably come. The code review is the moment the founder re-engages with the quality of the output, even if only at the behavioral and documentation level.

The framework I give to non-technical founders for code reviews has four checkpoints. First, the demo: the developer demonstrates the feature working end to end for a real user scenario, including what happens when something goes wrong. Second, the documentation: the developer shows me the documentation they produced for the feature, including any new environment variables, configuration changes, or architectural decisions. Third, the tests: the developer shows me the tests for the core user flow and what happens when they run. Fourth, the questions: I ask two or three questions that came up while they were walking me through the first three. The questions do not need to be technical. They can be about why they made a specific decision, what happens if a third-party service goes down, or how a user would recover from an error state.

This process takes thirty to forty-five minutes per feature and produces a reliable picture of the delivery quality. The developers I have worked with on projects from Dwarka Bricks to Nexli know that this is the expected delivery standard. The ones who produce clean, documented, tested work find the review easy. The ones who cut corners find the review uncomfortable, which is the intended effect.

Common mistakes

1. Treating the delivery as done when the feature exists in the codebase. A feature that exists but has not been demonstrated working end to end has not been delivered. Always require a demo.

1. Not asking for documentation until the final delivery. Documentation standards should be part of every sprint acceptance criteria, not a post-delivery request. After-the-fact documentation is always less complete and less accurate.

1. Accepting a delivery because the developer says it is done. "It's done" is not a delivery. A demo with a working user flow is a delivery.

1. Not asking about error handling. The happy path demo is easy. Ask what happens when the user enters invalid data, when the third-party API returns an error, or when the database connection is slow. The answers reveal whether error handling was considered.

1. Skipping the review when you trust the developer. Trust is earned through consistent reviews, not substituted for them. A developer who knows their work will be reviewed consistently produces different work than one who knows it will not.

Where to start

1. Add acceptance criteria to every sprint item that include a demo requirement. "Feature X is complete when the developer can demonstrate a new user completing the primary workflow without assistance" is a testable acceptance criterion that does not require technical knowledge.

1. Ask for a README update as a deliverable for every sprint. The README should reflect the current state of the system, including any new configuration or environment variables. This takes fifteen minutes and pays dividends indefinitely.

1. Run a thirty-minute delivery demo after every sprint. Developer shares screen, demonstrates the features, explains key decisions, and takes your questions. This is the most valuable thirty minutes of the development process from the founder's perspective.

Related reading

• How to Hire a Full Stack Developer Without Getting Burned
• Hiring Mistakes That Founders Repeat Endlessly
• The Vetting Framework: How to Verify a Developer's Real Experience
• How to Set Up a Trial Sprint That Reveals Real Skill