Who Reviews the Apps Your Employees Build?
When employees build their own software, someone must review it for correctness, data access, and risk—and code review can't scale to it. Here's what does.
When domain experts build their own software, the review can’t sit with whoever happened to build it—it has to belong to a defined function, usually a platform or governance team, that checks every internal app for three things before it ships: does it do what it claims (correctness), what data can it touch and who can see it (access), and what’s the blast radius if it’s wrong (risk). The hard part isn’t deciding that review should happen. It’s making review scale when hundreds of non-engineers are each shipping tools. Reading generated code app by app doesn’t scale to that. Reviewing a plain-language plan—a readable spec describing what each app does and what it touches—does.
That gap, between agreeing apps should be reviewed and having a review process that survives company-wide building, is where most attempts to let employees build software quietly fail.
TL;DR
- When employees build their own tools, review has to move to a defined function—usually a platform or governance team—not stay with whoever wrote each app, because the builder can’t be the only one vouching for what touches company data.
- Every internal app needs review on three axes—correctness, data access, and risk: does it work, what can it see and who can use it, and what breaks if it’s wrong.
- The default failure mode is no review at all: employees wire together tools no one signed off on, and the org inherits data flows it can’t see—classic shadow IT, now faster because AI generates the code.
- The other failure mode is trying to code-review everything, which collapses under volume: a platform team can’t read hundreds of generated codebases app by app, so review becomes a worse bottleneck than the old ticket queue.
- Traditional code review assumes a shared language and a shared team; it doesn’t survive when the authors are non-engineers and the volume is the whole company.
- Review becomes tractable when the thing you review is a plain-language spec instead of sprawling code—a readable plan stating what the app does, what data it holds, and who can use it is something a reviewer can evaluate the way they’d review a contract.
- The strategic win is reach: a single review function can govern hundreds of apps it didn’t write, because it approves and refines plans rather than auditing code line by line.
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
Who actually owns app review when everyone can build?
A defined function owns it—not the builder, and not a committee that meets once a quarter. In an org where the finance analyst, the ops lead, and the support manager each build their own tools, “the person who built it reviews it” is the same as no review: the author is the last person who can be the only check on what their app touches. So the review responsibility lands on a platform or governance team—the same group that owns the shared substrate everything runs on, the one IT becomes when it moves up the stack.
That’s a real job with a real definition, not a rubber stamp. The reviewer is answering, for every app before it ships:
- Correctness — does the app actually do what its builder says, or does it quietly miscompute the thing a department is about to rely on?
- Data access — what data does it read and write, where does that data live, and who can see it once the app exists?
- Risk — what’s the blast radius if it’s wrong: which systems does it touch, what’s the worst case, and is that acceptable for a tool no professional engineer wrote? (The security half of this is its own argument: employee-built apps don’t have to be a security hole when the substrate enforces auth and roles by construction.)
Notice that none of these are “is the code elegant.” They’re governance questions. The reviewer isn’t grading craftsmanship; they’re deciding whether something is safe to turn loose inside the company. That distinction is what makes the form of the thing under review matter so much—which is the rest of this argument.
Why doesn’t traditional code review work here?
Because code review was built for a different situation, and almost none of its assumptions hold when the builders are non-engineers and the volume is the whole company. Code review—the pull-request workflow every engineering org runs—works because three things are true: the author and the reviewer speak the same language, they’re on the same small team, and the volume is bounded by how many engineers you employ. Take a tool that depends on all three and point it at company-wide citizen building, and each assumption breaks.
The author isn’t an engineer anymore. A finance analyst who described the tool they needed can’t sit in a code review and defend the implementation—they never wrote it and can’t read it. The reviewer and the author no longer share a language. And the volume is no longer capped by engineering headcount; it’s capped by everyone. Gartner’s research found that half of business technologists already build technology capabilities for users beyond their own department—often entirely outside formal IT. The building is already distributed. Pointing a pull-request workflow at it asks a handful of platform engineers to read generated code across hundreds of apps, written by people who can’t explain it, at a rate no team can staff.
So code review doesn’t fail because reviewers are lazy or the tooling is bad. It fails because it was designed to review code written by engineers, for engineers—and that’s not what’s being produced.
What are the two ways app review usually fails?
Orgs tend to land on one of two failure modes, and both are real. Name them honestly before reaching for a better answer, because the better answer only matters if it beats these two.
Failure one: no review at all. This is the default when nobody’s assigned the job. Employees build what they need—wiring SaaS tools together, standing up trackers, automating a workflow—and nothing gets checked because there’s no function to check it. The work gets done, and the org inherits data flows, access grants, and dependencies it never saw. This is shadow IT, and banning it doesn’t make it disappear—it drives it further underground, because the demand to build is real and the queue that’s supposed to absorb it is full. AI makes this faster, not safer: now the untracked tool gets built in an afternoon instead of a week.
Failure two: try to code-review everything. This is what conscientious orgs do once they notice failure one. They route every employee-built app through the platform team for a full code review. It feels responsible. It’s also a chokepoint that’s worse than the ticket queue it replaced—because now the team isn’t building the backlog, it’s reading the backlog, app by app, in a language the builders don’t speak. The review function becomes the new bottleneck, the backlog reappears as a review queue, and employees route around it the same way they routed around IT. You’ve reinvented the problem with extra steps.
Both failures share a root cause: the thing being reviewed is code. Failure one skips reviewing the code; failure two drowns in it. Change what gets reviewed and both failure modes lose their grip.
How do you make review tractable at company scale?
You change the artifact under review from code to a plain-language spec. A spec, here, is a planning document for the app written in plain language—no code—the brief you’d hand a developer, stating what the app does, what data it holds, who’s allowed to use it, and what each part is for. When that is the source of truth—the thing the working app is generated from—review stops being a code audit and becomes a plan approval.
That single change fixes everything that broke. The reviewer doesn’t need to read the author’s language, because a spec is in everyone’s language. The author can defend it, because they described it. And the volume becomes manageable, because reading and approving a one-page plan is something a person can do at the pace plans arrive—not the pace codebases accrete. A platform lead reviews a spec the way a contract gets reviewed: read what it commits to, check the data clauses, approve or send it back with changes. They’re not inspecting the building brick by brick; they’re approving the blueprint and trusting that what’s built matches it.
This also changes what “fixing a review finding” looks like. If the reviewer flags that an app shouldn’t expose customer emails to the whole company, the change is a line in the plan—“only managers can view contact details”—not a hunt through generated code for where the permission check should go. Refine the plan, regenerate the app. Review and revision both happen at the layer a non-engineer and a reviewer can actually share.
Reviewing code vs. reviewing a spec
The shift is from auditing an artifact almost no reviewer can read to approving one anyone can. Point for point:
| Dimension | Reviewing generated code | Reviewing a plain-language spec |
|---|---|---|
| What the reviewer reads | A codebase per app | A readable plan per app |
| Skill required | Must read the author’s code | Must understand plain language |
| Can the builder defend it? | No—they didn’t write it | Yes—they described it |
| What “correctness” check looks like | Trace logic through files | Confirm the plan matches the intent |
| What “data access” check looks like | Hunt for where data is read/written | Read the data and roles section of the plan |
| Speed per app | Hours; scales with code size | Minutes; scales with plan size |
| Fixing a finding | Patch code, hope nothing else breaks | Edit a line in the plan, regenerate |
| Throughput ceiling | Reviewer’s reading speed | Reviewer’s judgment |
| Failure mode | Review queue becomes the new backlog | Plan is approved but vague—fixable by sharpening it |
Read the bottom rows. The point of reviewing a spec isn’t that review gets easier to skip—it’s that the ceiling moves from how fast a reviewer can read code to how fast they can exercise judgment. The first ceiling is low and fixed. The second is high and scales with the team’s expertise, which is exactly what you want governing the long tail of company-built software.
What makes spec-based review real
Everything above describes a review function the winning org needs: a defined team that checks every app for correctness, data access, and risk, reviewing a plain-language plan instead of a codebase, so review scales with judgment rather than reading speed. It’s exactly the function that appears in the org chart of 2027, where building distributes to the domain teams and a central platform team owns the substrate and the review against it. The model is sound on paper. It only becomes real if the plan is genuinely the source of truth—if the working app is generated from the reviewed spec, not loosely described by a document that drifts out of sync the moment someone edits the code.
That’s what a new category of AI tool—the product agent—is built for. Today the most advanced one is Remy. Someone describes the app they need in plain language; Remy drafts the spec—a readable plan—and that spec compiles into a real full-stack app: backend, database, real server-side auth and roles, frontend, and a live deployment. Because the spec is the source of truth, a reviewer reads and approves the plan, and the running app reflects exactly what was approved. When a finding comes back—“contact details should be manager-only”—the fix is a refinement to the plan, in plain language, and a recompile, not a patch to code the builder can’t read. The data access and roles a reviewer signs off on aren’t documentation; they’re enforced server-side in the compiled backend.
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
Unlike coding agents like Cursor or Claude Code—which edit code in a project an engineer already owns and assume engineering skill—a product agent operates at the product layer: you describe an outcome, it compiles the stack, and the spec is the artifact of record. That’s exactly what the review function needs, because the people building aren’t engineers and the reviewer shouldn’t have to read code to govern them. One honest boundary: this is early. Product agents are in open alpha, and enterprise needs like SSO and SAML aren’t there yet. The review model doesn’t wait for the category to finish maturing—an org can decide today that internal apps must be reviewable as a plain-language spec, and shape its governance around that now.
For the broader operating-model picture, read what the winning org looks like; for the category behind the punchline, what a product agent is.
FAQ
Who should review software that employees build themselves? A defined function—usually the platform or governance team that owns the shared substrate internal apps run on—not the builder alone and not an occasional committee. The reviewer checks each app for correctness, data access, and risk before it ships, the way a senior engineer approves a change instead of writing it.
What should an app review actually check? Three things: correctness (does the app do what its builder claims), data access (what data it reads and writes, where that lives, and who can see it), and risk (the blast radius if it’s wrong—which systems it touches and the worst case). These are governance questions, not code-quality questions.
Why doesn’t normal code review work for citizen-built apps? Code review assumes the author and reviewer share a programming language, sit on the same team, and produce a volume bounded by engineering headcount. When the builders are non-engineers and the volume is company-wide, all three assumptions break—so reading generated code app by app becomes an unstaffable bottleneck.
Isn’t letting employees build apps just shadow IT? Shadow IT is building without review or visibility. A governed model is the opposite: every app goes through a review function and lands on a substrate the org can see. The difference is whether there’s a tractable review step, not whether employees build.
How can a small team review hundreds of employee-built apps? By reviewing a plain-language spec for each app rather than its code. Approving a readable plan that states what an app does, what data it holds, and who can use it takes minutes and requires judgment, not the ability to read someone else’s code—so throughput scales with the team’s expertise instead of its reading speed.
What happens when a reviewer finds a problem? If the source of truth is the spec, the fix is a change to the plan—“only managers can view contact details”—and a regenerate, rather than a hunt through generated code for where to patch. Review and revision both happen at the plain-language layer the builder and reviewer share.
Where should an org start with app review? Decide that every internal app must land on a shared, governed substrate and be reviewable as a plain-language spec, and assign a function to own that review against correctness, data access, and risk. That single decision converts an unbounded code-audit problem into a bounded plan-approval one.
The bottom line
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
When employees build their own software, review can’t be optional and it can’t stay with the builder—it belongs to a defined function checking every app for correctness, data access, and risk. The trap is assuming that means code review at company scale, which collapses faster than the ticket queue it replaced. The way out is to change what gets reviewed: approve a plain-language plan, not a codebase, and review scales with judgment instead of reading speed.
That’s the piece a product agent supplies—real full-stack apps compiled from a plain-language spec, so the thing a reviewer approves is the source of truth. If you want to see what reviewing a plan instead of a codebase looks like in practice, explore Remy →.
