The Old Way

Traditionally, building a SaaS product meant:

Hiring developers. Good ones are expensive ($100K+ annually), hard to find, and take months to onboard.

Managing a team. Coordination costs, communication overhead, alignment challenges. Two-pizza teams become six-pizza teams become organizations.

Moving slowly. Spec → design → development → testing → deployment. Each phase takes weeks. Each iteration takes months.

This model worked when it was the only option. But it's been broken for years—we just didn't have a better alternative.

The New Way

AI changes everything. Here's my actual stack:

For thinking and planning:

→Claude Pro / Gemini Pro: Complex logic, strategy, copywriting, architecture decisions

For coding:

→Cursor / AntyGravity: AI-powered code editors that complete, explain, and refactor code
→OpenCode: For debugging and understanding what's actually happening

For building:

→v0: Rapid UI prototyping (generates React components from descriptions)
→n8n: Workflow automation (connects everything without writing backend code)

For deployment:

→Vercel / Supabase: Frontend and backend infrastructure that just works

With this stack, I can build in days what would have taken a team months. Not because I'm special—because the tools are that good.

What Actually Works

After months of building solo, here's what I've learned:

1. Ship before you're ready.

The biggest mistake is waiting until something is "ready." Perfect is the enemy of done. Ship a version that works, get feedback, iterate.

I launched the first version of LU Teams with maybe 30% of the features I planned. It didn't matter. Having something in users' hands taught me more than months of planning.

2. Use AI as a partner, not a replacement.

AI doesn't thinking—it augments it. The replace value isn't in the AI's output; it's in your ability to direct that output.

I ask AI to generate code. I ask it to explain code. I ask it to find bugs. But I still decide what to build and why. AI is the implementation engine; I'm the product mind.

3. Embrace the "vibe" approach.

Vibe coding: you describe what you want, AI generates something, you adjust until it feels right. It's more like art than engineering.

This sounds imprecise, but it's incredibly effective. Traditional coding demands exact specifications. AI allows exploration. Try things, see what works, adjust.

4. Accept that you'll be wrong.

A lot. You'll build features nobody wants. You'll use the wrong tools. You'll make architecture mistakes.

That's OK. The cost of being wrong has dropped to near zero. You can change things quickly. The old model where mistakes were expensive is gone.

5. Build in public.

Share your progress. Get feedback. Build an audience while you build the product.

Building alone is hard. Building with an audience is different—you get energy from people following your journey. And you get feedback that makes the product better.

What I Couldn't Do

Full transparency: there are things I still can't do as a solo builder:

Complex integrations. When LU Teams needs to connect to third-party systems with custom auth, I hit limits. Sometimes I need a real developer.

Performance optimization. Understanding why something is slow and fixing it at the systems level requires deeper knowledge than I have.

Security audits. I trust AI to generate code, but I'd want an expert to review critical security components before launching something high-stakes.

Scale challenges. When you have millions of users, you need architecture decisions I can't make alone.

For now, I'm building for the solo/small-team market. And that's fine. You don't need to scale to billions to build a valuable business.

What This Means for Engineering Leadership

Here's why this matters for leaders, not just builders:

The bottleneck is shifting. For decades, the bottleneck was implementation. You had an idea, you needed developers to build it. Now implementation is cheap. The bottleneck is now idea generation and market validation.

Roles are evolving. Not every "developer" job will disappear—but the nature of development work is changing. More prompt engineering, less syntax writing. More product thinking, less implementation thinking.

Competition is increasing. If you can build with AI, so can your competitors. The moat shifts from "we have developers" to "we understand the problem better" or "we have better data" or "we move faster."

Leadership becomes more important. When implementation is cheap, the differentiation is in direction. Great AI + wrong direction = nothing valuable. Great direction + mediocre AI = something useful.

The Psychological Challenge

Building solo has been harder psychologically than technically.

Loneliness. I miss the energy of a team. The brainstorming. The shared purpose. Building alone means no one to bounce ideas off, no one to celebrate wins with.

Uncertainty. Without a team validating your decisions, everything feels uncertain. Is this feature worth building? Is this the right approach? You don't have peers to check your thinking.

Overwhelm. As a solo builder, you're everything: product, engineering, design, marketing, support. The variety is exciting but exhausting.

The comparison trap. Seeing other solo builders' success can be discouraging. But everyone's journey is different. Comparison is the thief of joy.

These challenges are real. Building solo isn't for everyone. But for those who can handle the psychological load, the rewards are significant.

The Bottom Line

The era of needing a team to build is over. With AI tools, a single person with good judgment can build products that would have required a dozen people a decade ago.

This doesn't mean developers are obsolete. It means the game has changed. The value has shifted from implementation to direction, from building to deciding what to build.

Perfect code that ships in 6 months loses to working code that ships today.

The question isn't whether you can build with AI. The question is whether you know what to build—and whether you have the guts to ship.

This article is part of the Leadership Unfiltered series on engineering team dynamics. For more insights on building high-performing teams in the AI era, explore LU Teams.