Building features without building a team

An agentic pipeline that takes a non-technical founder from idea to production.

The problem

I worked with a recruiting company founder as a consultant. He had ten-plus years in the hiring space, a clear sense of what tools his team needed, and a folder full of broken prototypes to show for it.

He’d been vibe coding with Claude Code, getting prototypes working locally, then hitting the same wall most non-technical builders hit. The tools didn’t ship. They didn’t connect to real systems. They didn’t survive contact with his team. He had vision and judgment but no path from idea to production-grade software.

It’s a pattern I keep seeing. Founders and high-agency operators across companies are running into the same wall.

The approach

I took ten-plus years of building software products at scale and tried to distill it into a software factory of agents at the founder’s disposal.

Before I designed anything, I named the goal and the constraints I’d hold to.

The goal

The founder and his non-technical staff describe what they want in plain English. They get back working code that plugs into their existing systems.

The constraints

• The user is non-technical. The system has to meet them where they are.
• Back-and-forth with the user is expensive. Only ask high-leverage questions. Minimize friction.
• The system has to evolve as the business does. The team needs to be able to iterate on it without me.
• I should not become the bottleneck. Most AI consulting projects I’d seen ended with the consultant permanently embedded as the only person who could maintain what they built. That’s a feature of the business model, not the customer’s problem. I wanted to build the opposite: a system that needs me less over time, not more.

Those constraints pointed to a two-layer architecture. Opinionated platform infrastructure underneath, an agentic pipeline on top.

The platform is Vercel and Supabase with structured architecture files and a file system that defines agents, docs, and patterns. AI agents can only build reliably when the ground rules are explicit.

The pipeline runs in four phases.

Phase 1 · Capture

• Concierge agent: receives the founder’s idea in plain English, verifies the local dev environment, syncs the working branch.

Gate: idea received, environment ready.

Phase 2 · Requirements

• Socratic agent: runs a five to eight question dialogue to surface unstated requirements, drafts a PRD, iterates with the founder until it’s right.

Gate: founder approves PRD.

Phase 3 · Planning

• Requirements agent: breaks the PRD into numbered, testable stories with acceptance criteria and affected file paths.
• Standards agent: checks the requirements against project rules, protected files, and non-functional requirements.
• Planning agent: sequences the stories into a phased implementation plan with dependencies.

Gate: founder approves plan.

Phase 4 · Building

• Backend agent: writes data fetchers, API routes, database migrations.
• Frontend agent: builds pages and components against the design system.
• Test agent: drafts test specs, runs the build, iterates until everything passes.
• Verification agent: reviews the result against project rules and acceptance criteria.
• Finalization agent: commits, pushes, opens a PR against staging.

Gate: human reviews the diff, merges to prod.

The result

The founder and his team now ship their own internal tools end to end including backend logic, database migrations, real UI, deployed and tested. As the technical consultant, my role compressed from build-everything to diff-review. A non-engineering team operates with the leverage of a small product org.

Why this matters

This is bigger than one client. There is a generation of non-technical operators, founders, domain experts, ops leaders, who are often best positioned to solve the problems in their own organizations. They know the workflows, they know the edge cases, they know what would actually move the needle. They’ve historically been blocked by the cost of engineering.

Tools like Claude Code gave them a first glimpse of building software themselves. Almost all of them get stuck in the same place: turning a working prototype into something reliable, deployed, and iterable. That last mile is the gap.

The companies that figure out how to close that gap at scale will move at speeds the rest of the market can’t match. I want to help build that.

Where this goes next

Three open problems I want to push on.

1. Removing the final code review. Right now a human reviews the diff before it ships to prod. Automated review at production grade is genuinely hard, but it’s the last gate between a non-technical operator and full autonomy. Lots of people are working on this, none of them have nailed it yet.
2. Less opinionated infrastructure. The platform layer assumes Vercel, Supabase, and a specific file system today. The system should inspect a team’s existing cloud, code, and conventions during initial setup and configure itself to match. Reliable agents on whatever stack you already have.
3. Compressing the founder checkpoints. Phases one and two ask the founder to approve the PRD and the plan. The system can be much smarter here. Instead of approving documents, the founder reacts to lightweight working prototypes generated in seconds. Decisions move from reading to clicking.