When One Person Can Run a Team
Published:
Originally published on Substack.
Over the past two months, I did one thing: I rebuilt OmniEdge from scratch.
OmniEdge is a device networking project I started in 2021. It now serves users in 26 countries, with over 10,000 users in total. Back then, we had a team of more than ten people covering frontend and backend, iOS, Android, Windows, macOS, Linux CLI, OpenWrt, Synology, Docker—the full stack. From requirements alignment to the first production release, it took two months.
This time, I wanted to test something:
If it were just me, assisted by AI, how far could I go?
This wasn’t a demo. I fully rebuilt it—redesigned the protocol, restructured the architecture, and even performed a protocol migration mid-development, replacing the underlying protocol while the system was live. In a traditional team setting, that kind of move is high-risk and often derails momentum.
After two months, here’s the data:
38 protocol releases, 227 commits
29 cross-platform client releases, 258 commits
1,202 commits across frontend and backend
$200 total cost (AI subscriptions + servers)
Done across December and January, not full-time
In terms of output volume, it’s close to what a team of more than ten people produced before.
But output isn’t the real story.
What Actually Changed: The Collaboration Structure
In the past, a significant portion of time was spent on “alignment.”
Product wrote PRDs. Design produced mockups. Engineering pushed back on feasibility. Revisions, reviews, more revisions. A single feature would pass through multiple layers before shipping.
This time was different.
An idea formed in my head. AI generated the code. If it was wrong, I adjusted it. If it was right, I committed it. No document handoffs. No meetings. No cross-functional back-and-forth.
This isn’t just efficiency improvement. The collaboration structure itself collapsed.
Of course, AI isn’t magic. It executes efficiently, but it doesn’t decide direction.
How should a protocol be designed for long-term extensibility?
Which features should be deferred?
How should technical debt be managed?
Those decisions remain human responsibilities. If your judgment is wrong, AI simply helps you be wrong faster.
Execution is compressed. Judgment is amplified.
The Role of Background
My background may be a variable here.
For over a decade, I worked in industrial systems—building and deploying robotics system for BMW, Tesla, Mercedes. Later, I defined and built IIoT SaaS products, then OmniEdge, defining products and designing architectures. Last year, I led product at two humanoid robotics companies.
What this trained wasn’t coding ability, but systems thinking:
How a product is structured.
How it evolves.
Where bottlenecks will emerge.
What will become a problem three years down the road.
This experiment made something clearer: in the AI era, what’s scarce may not be coding skill, but system-level judgment.
Code can be outsourced to models.
Architecture decisions and product trade-offs cannot.
Implications for Early-Stage Teams
If this trajectory holds, the optimal structure of seed-stage teams may be shifting.
We used to assume you needed at least 10+ people to build a complete product loop. Now, 3–5 people might be sufficient—provided the capability structure is complete:
One person with strong systems architecture ability
One person who deeply understands the industry
One person who can drive growth and distribution
Architecture determines how the product is built and evolves.
Industry understanding prevents building in a vacuum. Procurement processes, deployment environments, regulatory constraints—these are invisible unless you operate in the field.
Growth capability solves distribution. As development barriers fall, product supply increases. What becomes scarce is user attention and channel access.
As technical supply expands, distribution becomes more valuable.
A Perspective for Funding
This experiment cost $200.
Mapped to seed-stage financing, that implies early capital is no longer primarily for hiring headcount. As team size compresses, capital should shift toward market validation, channel expansion, and industry penetration.
Team size may no longer be a reliable signal.
What matters is whether the capability structure is complete, and whether the core decision-maker possesses system-level judgment.
AI lowers execution cost. It does not lower the cost of strategic mistakes.
Closing
A smaller organization does not mean lower complexity.
In the past, complexity lived in coordination. Now it lives in cognition. Technology, product, industry, and business logic must be integrated within one—or a few—minds.
In the industrial era, the core startup question was: how do you organize people?
In the AI era, the question is shifting toward: how do you organize systems—humans, models, toolchains, and automation workflows—into a coherent engine?
This experiment showed me that a new organizational form is emerging.
This rebuild wasn’t about proving that one person can replace ten. It demonstrated something else: As execution cost approaches zero, the core competitive advantage of startups shifts from headcount to system judgment. The value of an early team lies not in its size, but in whether it possesses architectural capability, industry insight, and a growth loop. For founders, this is an organizational paradigm shift. For investors, it requires an upgrade in evaluation logic.