The Constructs That Run a Company
March 2026 · Guide
A solo founder needs different agents than a Series B company. A pre-IPO company needs different agents than both. But at every stage, the pattern is the same: a small set of constructs orchestrating together to handle the work that would otherwise require headcount the company cannot afford or cannot hire fast enough.
This is a practical guide to the constructs a company needs at each stage — not aspirational, but operational. What you actually deploy, and how they work together.
Stage 1: Solo Founder (0–1)
You are one person. You write code, talk to customers, handle billing, write docs, and fix production at 2 AM. You do not need a fleet of agents. You need three.
The Solo Stack
Code Reviewer — Your only quality gate. Reviews every diff before you push. Catches the SQL injection you wrote at midnight.
Product Spec Writer — Forces you to think before you build. Takes your vague idea and turns it into a spec with requirements, edge cases, and — critically — a “Won't Have” section.
Technical Writer — Writes your README, API docs, and onboarding guide. The work you would never do yourself but that makes or breaks developer adoption.
At this stage, the constructs operate independently. You invoke them one at a time. There is no orchestration — you are the orchestrator.
Stage 2: Small Team (2–10 people)
You have raised a seed round or generated enough revenue to hire. The codebase is growing faster than anyone can keep track of. You are shipping features but breaking things. Customer requests are piling up.
Add to the Stack
CEO Plan Reviewer — Before committing to a feature, run the plan through a construct that asks “what would make this 10x better for 2x effort?” and “what's the minimum version that validates the hypothesis?”
Eng Manager Plan Reviewer — Locks in architecture before code is written. Data flow diagrams, edge cases, test coverage plan. Prevents the “we'll refactor later” that never happens.
QA Engineer — Systematically tests the app after every deploy. Finds bugs the team missed. Three tiers: quick smoke test, standard coverage, exhaustive audit.
Debugger — When production breaks, you need systematic root cause analysis, not panicked guessing. Reproduce, isolate, hypothesize, test, fix.
Codebase Onboarding Guide — Every new hire costs the team two weeks of context transfer. This construct reads the codebase and produces a 15-minute onboarding doc.
How they orchestrate: The CEO Reviewer feeds into the Eng Manager Reviewer. The Eng Manager Reviewer produces the architecture plan. Engineers build. The Code Reviewer gates every PR. The QA Engineer tests the deploy. The Debugger handles incidents. This is a pipeline — each construct's output is the next construct's input.
Stage 3: Growth (10–50 people)
You have product-market fit. Revenue is growing. The challenge shifts from “can we build it?” to “can we build it without the codebase collapsing?” You need constructs for the functions you cannot hire fast enough.
Add to the Stack
Security Auditor — You cannot afford a full-time security engineer yet, but you are handling real user data. This construct reviews every PR for OWASP vulnerabilities and audits infrastructure configuration.
Database Designer — Schema decisions made now will haunt you for years. Normalization, indexing strategy, migration planning.
System Architect — The monolith is straining. Some services need to be extracted. This construct designs the boundaries without creating a distributed monolith.
Design Auditor — The product looks like it was designed by engineers (because it was). This construct reviews every page for spacing, typography, hierarchy, and accessibility.
Incident Commander — Outages are no longer one-person fixes. Someone needs to coordinate the response, communicate to stakeholders, and run the postmortem.
Data Pipeline Engineer — You are drowning in data but starving for insights. This construct designs ETL pipelines, data quality checks, and analytics infrastructure.
How they orchestrate: At this stage, constructs start running in parallel, not just in sequence. The Security Auditor and Code Reviewer both gate PRs. The Design Auditor and QA Engineer both evaluate deploys. The System Architect and Database Designer both contribute to planning. You need a conductor — a human or a meta-construct that routes work to the right agent.
Stage 4: Scale-Up (50–200 people)
You have raised a Series B or C. There are multiple engineering teams, a product organization, a go-to-market function. The challenge is coordination, not capability.
Add to the Stack
Engineering Retrospective — Analyzes commit history, work patterns, and velocity across teams. Per-person contributions with praise and growth areas. Weekly cadence.
Technical Interviewer — You are hiring constantly. This construct conducts calibrated technical assessments with consistent evaluation criteria across all interviewers.
Migration Planner — You are moving to a new database, upgrading frameworks, rewriting services. Every migration needs a plan with rollback at every phase.
Terraform Engineer — Infrastructure is no longer click-ops. Everything is code, versioned, reviewed. Module design, state management, multi-environment.
UX Copywriter — With multiple teams shipping UI, the voice of the product is fracturing. This construct enforces consistent microcopy, error messages, and onboarding flows.
Compliance & Privacy — SOC 2 is no longer optional. GDPR is real. This construct reviews data handling practices, flags compliance gaps, and maintains the privacy inventory.
How they orchestrate: Each team has its own construct stack tailored to its domain. The platform team runs Terraform Engineer + System Architect. The product teams run Design Auditor + UX Copywriter + QA. The engineering org runs Retrospective + Interviewer. A company-wide meta-construct — the Conductor — routes cross-team concerns and ensures nothing falls between the cracks.
Stage 5: Pre-IPO and Beyond (200+ people)
The company is preparing to go public or has already. Regulatory requirements multiply. Every process needs documentation. The board wants metrics. The challenge is governance without bureaucracy.
Add to the Stack
Document Release Engineer — Every release needs changelog, architecture updates, and compliance documentation. This construct reads the diff and updates every document that needs updating.
Board Metrics Analyst — Synthesizes engineering metrics, product analytics, and business KPIs into the narratives the board needs. Translates technical progress into business language.
Vendor & Contract Reviewer — Every new SaaS tool, API, and infrastructure provider needs a security review, data processing agreement, and compliance check.
Risk & Audit Construct — Continuous monitoring of access controls, change management processes, and audit trail completeness for SOC 2 and SOX readiness.
Cross-Team API Designer — With 20+ services owned by different teams, API consistency is critical. This construct enforces design standards, versioning policy, and breaking change protocols across the entire organization.
How they orchestrate: At this scale, the construct fleet is an operating system. Every construct has defined inputs, outputs, and triggers. The Document Release Engineer fires on every merge to main. The Risk construct runs continuously. The Board Metrics Analyst runs monthly. The humans are not operating the constructs — they are governing them, reviewing their output, and making the judgment calls that constructs surface but cannot resolve.
The Full Stack
Here is every construct mentioned above, mapped to the stage where it becomes essential:
| Construct | Solo | Team | Growth | Scale | IPO |
|---|---|---|---|---|---|
| Code Reviewer | • | • | • | • | • |
| Product Spec Writer | • | • | • | • | • |
| Technical Writer | • | • | • | • | • |
| CEO Plan Reviewer | • | • | • | • | |
| Eng Manager Reviewer | • | • | • | • | |
| QA Engineer | • | • | • | • | |
| Debugger | • | • | • | • | |
| Onboarding Guide | • | • | • | • | |
| Security Auditor | • | • | • | ||
| Database Designer | • | • | • | ||
| System Architect | • | • | • | ||
| Design Auditor | • | • | • | ||
| Incident Commander | • | • | • | ||
| Data Pipeline Engineer | • | • | • | ||
| Retrospective | • | • | |||
| Technical Interviewer | • | • | |||
| Migration Planner | • | • | |||
| Terraform Engineer | • | • | |||
| UX Copywriter | • | • | |||
| Compliance & Privacy | • | • | |||
| Document Release | • | ||||
| Board Metrics Analyst | • | ||||
| Vendor & Contract Reviewer | • | ||||
| Risk & Audit | • | ||||
| Cross-Team API Designer | • |
The Pattern
At every stage, the same pattern holds: start with quality gates (Code Reviewer, QA), then add planning constructs (CEO Reviewer, Eng Manager), then add specialized domain constructs (Security, Database, Infrastructure), then add organizational constructs (Retrospective, Interviewer, Compliance).
The constructs do not replace the people. They replace the gap between when a company needs a capability and when it can hire for it. A startup needs security review from day one but cannot afford a security engineer until Series A. A growth company needs consistent interview calibration but cannot hire a dedicated recruiting operations team until 100 people.
Constructs fill the gap. And when the humans arrive, the constructs do not disappear — they become tools the humans use to operate at a higher level.
Many of these constructs are available on constructs.sh today. Start with three. Add more when the pain demands it.