About Skills Work Journey Blog Contact
Career · 7 min read · February 2026

How I Shipped 11 Live Projects as a Solo Developer

People ask me all the time: how do you ship so many things? The honest answer is that most of these weren't planned as portfolio pieces. They were problems I wanted to solve, ideas I couldn't stop thinking about, or client briefs I decided to own end-to-end. Eleven live projects later, here's what I actually learned.

The 11 Projects

Quick rundown before we dig in:

How It Actually Started

The first few were pure exploration. I wanted to get better at React so I built Dev Pulse. I wanted to understand Supabase so I built something with a real database. Each project taught me something the next one could use.

The mistake most developers make is waiting until they're "ready" to start. You're never ready. You learn by building something slightly above your current level and figuring it out as you go. Every single project here taught me something I didn't know when I started it.

The Pattern That Works

After 11 projects I've noticed I follow the same four-step pattern, whether intentional or not:

  1. Pick a real problem — not a tutorial clone. Mapleins came from watching friends struggle with the Canadian job market. stalejs came from writing the same boilerplate five times.
  2. Define the smallest version that's useful — not the full vision. What's the one thing it has to do?
  3. Ship it ugly — get it live. A live ugly thing beats a perfect local thing every time.
  4. Iterate with real feedback — once it's live, you get real data. What do people actually use? What's broken?

On Tech Stack Choices

I don't have a dogmatic stack. I pick based on the project:

  • Next.js + Supabase for anything with auth, a database, or server-side rendering needs (Mapleins, Appointly)
  • Pure HTML/CSS/JS for landing pages and brand sites — faster to ship, easier to deploy, no build step (Aurora, Pulse, Verdure, Solstice, Axiom)
  • Vanilla JS libraries when I'm solving a specific technical problem (stalejs)

The biggest lesson: don't reach for a framework because it's popular. A Verdure Restaurant page does not need React. A pure HTML file deployed to Netlify in 30 seconds is the right call.

What I Actually Learned

Some non-obvious things that took multiple projects to sink in:

  • Deployment matters as much as code. A great product that nobody can access is worthless. I learned Vercel, Netlify, and custom domains early and it changed everything.
  • Design is a skill, not a talent. My early projects looked rough. I studied design systems, stole patterns from products I admired, and iterated. Design improves with deliberate practice.
  • Performance is a feature. Users notice slow. I didn't take web vitals seriously until a project loaded slowly on mobile and I watched someone close the tab.
  • The README is part of the product. For open source work especially — if people can't understand what it does in 30 seconds, they won't use it.

What I'd Do Differently

Honest mistakes I made and wouldn't repeat:

  • Not setting up analytics from day one. I have no idea how many people visited early versions of these projects. That's a lot of lost signal.
  • Over-engineering the first version. I spent weeks on Mapleins' infrastructure before anyone had used it. Ship the MVP, then scale.
  • Not writing about what I built. Projects without documentation disappear. That's why I started this blog.

What's Next

The projects I'm most excited about going forward involve AI tooling for developers — specifically around the gap between what AI can generate and what actually works in production. More on that soon.

If you're staring at an empty editor wondering how to start your first project: pick a problem you're annoyed by, build the smallest thing that solves it, and put it online. That's the whole playbook.
Share

More Writing