Building software no longer requires a big team

Ten years ago, getting a SaaS into production and keeping it running could take a whole team: someone for infrastructure, someone for the backend, someone for the frontend, people for QA, and the odd designer too. Today, a single person can take on almost all of that.

A lot of the work that used to take time and people is now handled by services that practically run themselves. Vercel deploys on a git push, Neon offers a database that scales to zero, S3 stores the files, and tools like Sentry and PostHog help catch errors and understand how users actually use the product. The infrastructure that used to be a full-time job now needs far less maintenance.

The way I build changed too. Day to day I use Claude Code and Codex to explore ideas, plan, implement, debug, refactor, and review code. I work in parallel with Git worktrees and keep context documentation so the agents understand how the project works. I don’t take everything they produce at face value: I review and test the changes before integrating them. The speed is on another level, but the decisions and the responsibility are still mine.

That’s how I built Onpadel. Early on I led a team of designers to define the product, built the platform, and got real organizers using it to run their tournaments. Today it keeps running and growing, with very little day-to-day involvement on my part.

But being able to build faster doesn’t mean the hard part is gone. Choosing what’s worth building, understanding what users need, and getting someone to pay for it are still a challenge. When building stops being the main bottleneck, judgment matters even more: knowing what to do, what to ignore, and where it’s worth investing your time.

Today one person can take on almost an entire product. The advantage isn’t just writing code faster, but being able to connect the different parts: product, technology, users, and business.