From Managing 300 People to Building Solo with AI

I spent years managing teams of 300+ people at BYJUS. I was good at it. Quarterly plans, OKRs, one-on-ones, performance reviews, cross-functional alignment. The machinery of organizational management. But here's what nobody tells you about managing that many people: you stop building.

Not because you don't want to. Because coordination becomes your full-time job. Managers spend 60-80% of their time coordinating, not creating. Every direct report adds roughly 5 hours per week of management overhead. With 300 people across multiple layers, the communication overhead isn't linear. It's exponential. You're writing strategy docs that get reinterpreted by VPs, who brief directors, who tell managers, who explain to ICs. By the time your idea reaches the person who actually builds it, it's been through a game of telephone across four organizational layers.

Then I left to build AppletPod. Just me. No team. No org chart. No alignment meetings. And something unexpected happened: I shipped faster than I ever did with 300 people. In three months, I built and deployed 100+ interactive math applets. Solo.

That's not a humble brag. It's a data point about what's now possible when you remove organizational overhead and add AI as your labor layer. The playbook for building education products has fundamentally changed, and most people haven't realized it yet.

The management tax nobody talks about

Here's the uncomfortable truth about large organizations: most of the work isn't building. It's coordinating who builds what.

Research from Harvard Business Review on span of control shows that managers spend 60-80% of their time on coordination activities: meetings, email, status updates, resolving conflicts, aligning priorities. The actual creation work happens at the edges, done by individual contributors who are layers removed from strategic decisions.

When I managed 300 people, my calendar was a solid block of meetings. Product reviews, design critiques, stakeholder updates, budget planning, hiring, performance management. I touched strategy and approved decisions, but I didn't build anything directly. The distance between "I want this feature" and "this feature ships" was measured in weeks, not hours. Not because the team was slow. Because coordination takes time.

Every person you add to an organization adds communication paths. With 5 people, there are 10 possible communication paths. With 50 people, there are 1,225. With 300 people, the number becomes absurd. You solve this by adding structure: layers of management, formalized processes, documentation requirements, approval chains. But every layer you add to reduce communication chaos also adds latency to execution.

This is fine when you're operating at scale and the coordination is necessary. But for early-stage product development, especially in EdTech where iteration speed matters, the management tax is crippling. You spend more time aligning on what to build than actually building it.

What AI changes about the equation

The standard advice for technical founders is to hire fast. Get a designer, a frontend developer, a backend developer, a QA engineer. Build a team. Delegate. Scale yourself through people.

That advice made sense in 2015. It doesn't in 2026.

AI hasn't just made developers more productive. It's made small teams viable where you previously needed large ones, and solo builders viable where you previously needed small teams. GitHub's research on Copilot shows 55% faster task completion. But that's not the real unlock. The unlock is eliminating roles entirely.

When I build an applet now, I don't need a junior developer to write boilerplate React components. Claude does it. I don't need a QA engineer to write test cases. AI generates them. I don't need a designer for initial wireframes. AI mocks them up. I don't need a technical writer for documentation. AI drafts it.

The 80% of work that used to require hiring people now happens through prompting AI. What I keep doing myself is the 20% that requires domain expertise, strategic decisions, and final quality judgment. That 80/20 split is what makes solo building viable.

This isn't hypothetical. Solo founder success rates have tripled since 2019. According to Indie Hackers data, 40% of profitable indie SaaS products in 2023 were solo-built, compared to 12% in 2019. That's not because solo founders suddenly got better at coding. It's because AI filled the gaps that used to require a team.

The EdTech-specific unlock

EdTech has traditionally required significant capital and team size to build anything meaningful. The typical EdTech MVP timeline was 6-12 months with a team of 3-5 people and a budget of $200K-$500K. You needed curriculum designers, developers, content creators, QA, and instructional designers just to get to a pilot.

That timeline and cost structure meant EdTech startups had to raise venture capital before shipping anything. Which meant pitching investors before validating with real students. Which meant building what investors think is valuable, not necessarily what teachers and students actually need.

AI compresses that timeline and cost by 10x. I shipped the first set of interactive fraction applets in 3 weeks, solo, for less than $10K in infrastructure and tools. No team. No funding round. No pitch deck. Just direct iteration with teachers and students.

The compression isn't just about speed. It's about the type of business model it enables. When your MVP costs $200K, you need to raise money. When your MVP costs $10K, you can bootstrap. When you're bootstrapped, you can stay close to customers and build exactly what they need, not what investors think will scale.

This is the EdTech unlock that most people haven't internalized yet: AI-assisted solo building enables customer-funded EdTech businesses. You don't need to convince VCs that your product will reach 10 million students before you've taught your first one. You can start with 10 teachers, charge them directly, and grow from revenue.

What you actually do solo (and what AI does)

The mistake people make when hearing "solo with AI" is thinking you do everything yourself with AI as a minor assist. That's not the model. The model is: AI does most of the execution, and you do the parts that require human judgment and domain expertise.

What I do:

• Decide which concepts need interactive applets based on teacher feedback
• Design the pedagogical approach (how should a student learn fraction equivalence?)
• Review AI-generated code and catch edge cases
• Test applets with real students and identify what's confusing
• Talk to teachers and adjust based on classroom use
• Set product direction and prioritization

What AI does:

• Write 90% of the React components
• Generate test cases and catch obvious bugs
• Create initial visual designs and iterate on them
• Draft documentation and user guides
• Refactor code for performance
• Suggest alternative implementations

The division isn't "I write code and AI helps me." It's "AI writes code and I steer and quality-check it." That's a fundamental inversion of the traditional developer-assistant relationship.

This works because EdTech products have well-defined requirements. A fraction applet needs to visualize fractions, allow manipulation, and provide feedback. That's specifiable. AI is excellent at executing well-defined specs. What AI can't do is decide whether the fraction applet should use bar models or circle models, or whether the feedback should be immediate or delayed. Those are pedagogical decisions that require domain knowledge.

The key skill isn't coding anymore. It's knowing what to build and how to evaluate whether the AI-built version is pedagogically sound.

Speed as a structural advantage

The biggest advantage of solo-plus-AI isn't cost. It's speed.

Small teams ship faster per person than large teams. This is well-documented. Basecamp and 37signals have written extensively about how organizational size creates diseconomies of scale. More people means more meetings, more documentation, more process overhead. A five-person team ships 10x faster per person than a 50-person team on the same type of work.

Solo-plus-AI is the extreme case of this principle. Zero meetings. Zero alignment overhead. Zero handoffs. I have an idea, I spec it, AI implements it, I test it, I deploy it. Total time: hours, not weeks.

When I was managing 300 people at BYJUS, the time from "let's build this feature" to "this feature is live" was measured in quarters. Product reviews, design sprints, development cycles, QA, staging, production rollout. Every step involved coordination across teams. Most of the elapsed time wasn't work. It was waiting for the next person in the chain to be available.

Building solo, the time from idea to deployment is the time it takes me to write a spec and review what AI builds. For a simple applet, that's a day. For a complex one, maybe a week. That 10-100x speed advantage compounds. By the time a traditional team ships one feature, I've shipped ten and learned which ones actually work with students.

Speed isn't just nice to have. It's a structural competitive advantage. Education products need fast iteration because pedagogical hypotheses are wrong more often than they're right. You can't predict what will click with students until you put it in front of them. The faster you can build, test, and iterate, the faster you find what works.

When this model works (and when it doesn't)

Solo-plus-AI isn't universally applicable. There are clear boundaries where it works and where it doesn't.

It works when:

• The product is technically specifiable (you can describe what it should do)
• Iteration speed matters more than parallel execution (EdTech, indie SaaS, content tools)
• You have domain expertise to guide and quality-check AI output (you're not learning the domain and the tools simultaneously)
• The product is modular (lots of small pieces rather than one massive interconnected system)
• You're bootstrapped or customer-funded (no pressure to "look like a real company" to investors)

It doesn't work when:

• You need true parallel execution (20 people working on independent modules that all ship simultaneously)
• The product requires specialized expertise you don't have and can't easily acquire (medical devices, financial compliance, security-critical systems)
• The domain is so novel that AI can't generate useful code (cutting-edge research, novel algorithms)
• You're scaling a proven product and need execution bandwidth more than innovation (operations-heavy businesses)

The AppletPod use case fits the "works" category almost perfectly. Interactive educational applets are technically specifiable. I have the domain expertise from years in EdTech. The applets are modular (each one is independent). Iteration speed is critical (I need to test with students and adjust). And I'm bootstrapped, so I don't need to justify my org structure to investors.

If I were building a learning management system with complex permissions, real-time collaboration, and integration with 50 school district data systems, solo-plus-AI wouldn't work. That requires coordination across too many interdependent pieces. But I'm not building that. I'm building 100+ small, independent, pedagogically-focused tools. That's where solo-plus-AI excels.

The organizational structure as competitive advantage

There's a broader pattern here that goes beyond EdTech. For a certain class of products, your organizational structure is your competitive advantage.

Large companies can't move fast. They have stakeholders, approval processes, quarterly planning cycles. They're optimized for coordination at scale, not for rapid iteration. That's fine when you're operating a mature product. It's fatal when you're trying to find product-market fit.

Small teams have the advantage of speed, but they still have coordination overhead. Every person you add creates communication paths and handoff delays. You gain execution bandwidth but lose decision speed.

Solo-plus-AI has zero coordination overhead and near-infinite execution bandwidth (AI doesn't sleep, doesn't need onboarding, doesn't have competing priorities). The constraint is your judgment and review capacity, not execution capacity. For products where judgment and direction are the bottleneck (which includes most early-stage products), that's the ideal structure.

The controversial implication: for many technical products, solo-plus-AI beats small team, which beats large company. The optimal organizational structure isn't the one with the most people. It's the one with the least coordination overhead for the type of work you're doing.

This inverts 50 years of management thinking. The old model was: identify work, hire people to do it, coordinate them. The new model is: identify work, do the high-judgment parts yourself, delegate the rest to AI, coordinate nothing.

What this means for EdTech builders

If you're building an EdTech product in 2026, the default path doesn't have to be "raise money, hire team, build for two years, then launch." There's an alternative path that most people aren't taking yet but probably should consider:

Build solo with AI first. Get to a working prototype fast. Test it with real teachers and students. Learn what works. Iterate rapidly. Stay close to customers. Charge them directly. Grow from revenue, not from funding.

If you need to scale beyond what solo-plus-AI can handle, you'll know it because customers are asking for things that require parallel execution (native mobile apps on three platforms, integrations with ten different LMS systems, 24/7 customer support). At that point, you have revenue, you have product-market fit, and you have clarity about what roles you actually need to hire. You're not guessing. You're responding to proven demand.

The traditional path front-loads the coordination overhead. You build the team before you know what you need. The solo-plus-AI path defers it. You stay lean until the product pulls you toward hiring. For most EdTech products, that's a better bet.

I'm not claiming everyone should build solo forever. I'm claiming that starting solo with AI, staying solo longer than you think you should, and only hiring when it's painfully obvious you need to is a better default strategy than the old "hire fast and delegate" playbook.

The best part: this approach is proven. The 100+ applets running in classrooms right now weren't built by a team. They were built by one person with AI as the execution layer. If that's possible for interactive math tools used by thousands of students, it's possible for a lot more EdTech products than people currently realize.

The playbook has changed. Most people just haven't noticed yet.