Three teams, nearly two years, still no product
The founder's voice carried exhaustion when she found me.
"We hired three outsourcing teams over nearly two years. The first spent six months — they stored passwords in plaintext. The second had great technical skills but over-engineered everything. Eight months in, they were still debating architecture. The third was cheap, but the quality was so bad we couldn't maintain anything they built."
She paused. "I even tried using AI to build it myself. The login page alone had security holes."
She wasn't lazy or incompetent. She was someone with genuine passion for education who'd spent two years and her savings trying to build a product that would actually help students. Every outsourcing cycle was a fresh start from zero.
I asked her: "What do you need most right now?"
She said: "I need something that can go live, with real students using it. And I need a team that can keep running after I leave."
Why did all three fail?
Before taking over, I spent a week reviewing the three repos she'd accumulated.
Team 1: Zero security awareness. Not just plaintext passwords — APIs had no authentication. Anyone could call them directly. Six months of work that was worthless from a security standpoint.
Team 2: Over-engineering. Beautiful architecture diagrams, five or six microservices. But for an education product with zero users, this was like debating which road bike to buy before learning to ride a bicycle. Eight months gone, still discussing API specs.
Team 3: Runs but can't be changed. All logic crammed into single files, no structure. Change one thing, three things break. Within a month of delivery, the founder was afraid to touch it.
Three completely different problems, but one thing in common: they were all solving technical problems, but nobody was solving the product problem.
Nobody asked: "What do students actually need?" "What's the teacher's workflow?" "What three things should V1 do and nothing more?"
Each team walked in with their own technical preferences and built something disconnected from real user needs.
Three months: from zero to launch
I decided not to salvage any of the old repos. Clean start.
Not because old code is always unsalvageable — but because fixing three messes would take longer than rebuilding. And starting fresh, I could use AI-assisted development to move fast.
Month one: only three features.
I told the founder: "V1 does three things." She had a list of fifteen features. We spent an entire afternoon cutting it to three.
I didn't choose which three. I asked three actual users — two teachers and one student — "What do you need most?" Their answers were surprisingly consistent.
Using Claude Code for AI-assisted development, one person's delivery speed equals a small team. But speed wasn't the point. The point was: I had time to talk to users instead of spending all day writing code.
Month two: launch, stumble, iterate.
Launch day, I was nervous. Three features, simple interface, honestly a bit ugly.
But teachers used it. Students used it.
Feedback started pouring in. "Can you add a button here?" "This flow could be smoother." "It'd be great to see a student's history."
Every piece of feedback was a real need — not something I'd imagined in an office.
I changed a lot that month. But every change had a corresponding user story, not a "technically we should do this" justification.
Month three: build the team.
This was the most critical month.
I knew I couldn't stay on this project forever. If I left and nothing could be maintained, how was I any different from the three teams before me?
So in month three, I started training people.
The founder's team had two people, neither with engineering backgrounds. I taught them to use AI to write code, read code, and modify code. Not syntax — process. How to describe requirements so AI understands. How to check if AI's output is correct. How to use version control so they don't overwrite each other's work.
After a month, they could independently handle most feature requests. When I wasn't around, they kept shipping.
Results across three dimensions
Looking back after three months, the results fell across three dimensions:
Product: it launched. Not a demo — a real product with real students using it. Simple, but functional. Every feature mapped to an actual user need.
Talent: the team became independent. After I left, they continued operating on their own. New features, bug fixes, deployments — all handled without calling me back.
Funding: they secured investment. With a working product and real usage data, the founder successfully raised her next round.
All three dimensions were essential. Product without team means everything stops when I leave. Team without product means nothing to show investors. Funding without talent means the money burns out with nothing to show for it.
This wasn't a one-off
Over the past six months, I've used the same approach across multiple projects.
Built an AI-assisted surgical decision system for a hospital — doctors can now discuss cataract surgery options with patients using the system right in the exam room, instead of handwriting comparison charts.
Built a care management platform for a long-term care facility — nurses record notes by voice, and audit preparation shrank from two weeks to half a day.
Built a career counseling tool for a counseling practice — counselors can guide clients through career exploration with structured tools instead of starting from scratch every session.
None of these organizations had engineers. In every case, I didn't just build the product — I trained people who could maintain it independently. After handoff, they run without me.
What's scarcest in the AI era?
Back to the education startup.
Why did three outsourcing teams all fail? Not because they couldn't code. Team 2's architecture was actually quite elegant.
They failed because nobody was making judgments.
Judging which three features V1 should have. Judging which requirements are real and which are imagined. Judging when to launch and when to wait. Judging that building team capability matters more than building features.
In the AI era, the barrier to writing code has dropped dramatically. One person with AI can build what used to require an entire team. But this makes another skill even more critical:
Knowing what to build — and what not to build.
AI can write any feature you ask for. But it won't tell you: "You shouldn't build this yet." It won't say: "Go talk to your users first." It won't judge: "This architecture is too heavy for your stage."
That kind of judgment can't be learned from books or courses. It can only grow from practice — from mistakes, from failures, from real user feedback — one hard lesson at a time.
For those looking for outsourcing help
If you're looking for someone to help build your product, whether outsourcing or building with AI yourself, a few suggestions:
V1 should have three features. Not thirty. Find three people who will actually use your product and ask them what they need most. Their answers will be different from what you expected.
Find someone willing to build your team, not just write code. If you still have to call them back every time something breaks, that's not delivery — that's dependency. Good collaboration means: after they leave, your team is stronger than before they arrived.
Launch before it's perfect. An ugly product that works is worth ten thousand times more than a perfect design that hasn't launched. Because only after launch do you learn what users actually need.
AI is your accelerator, not your steering wheel. AI lets you build faster, but it won't tell you where to go. Direction is on you.
Three outsourcing failures weren't caused by lack of technical skill. They were caused by lack of the most important thing — judgment. And judgment is the one thing AI can't shortcut for you.