Making Money As A Solo Software Developer
How I Built a $20M Side Hustle: Lessons From Chrome Extensions to AI Voice Cloning
The Solopreneur's Dream
There's a dude out there running a one-man business developing Chrome plugins that makes over $20 million a year. That's four times more than the average NFL quarterback. Unfair? Maybe. But it highlights one of the best things about learning to code: it gives you the ability to build money-printing machines that regular people simply can't.
In my world, the ultimate freedom is being a solopreneur with a business that runs itself on autopilot. No deadlines, no bosses, no need for Bugattis—just pure freedom. But that's easier said than done. You won't get there with a 4-Hour Work Week, and for most of us, it takes a lot of hard work and some luck.
I've built tons of side hustles over the years, and I'll be honest—almost all of them failed miserably. But a few have been moderately successful, giving me enough wealth to move out of my mom's basement. Today, I'm going to show you exactly how I built and deployed my own real AI software-as-a-service application with only two days of programming work.
The Side Hustler's Mindset
Before we dive into the code, we need to talk about the mindset of a successful side hustler.
Take Danny Postma, who created Headshot Pro, a service that now has over 12,000 customers. Many might say he got lucky by jumping on the AI hype train—and they'd be absolutely right. But here's the thing: he made his own luck. He first developed the skills to build things, then identified a problem (corporate photos being a huge waste of money), and when AI got good enough to replace photographers, he seized the moment.
Here's another example: movie director Quentin Tarantino wrote a screenplay where Salma Hayek pours tequila down her leg and someone drinks it off her toes. Guess who he cast in that role? Himself. That's what making your own luck is all about.
The problem is that most of us won't get this lucky very often. That's why you need to be prepared to:
- Fail early
- Fail often
- But always fail forward
The only person who can actually tell you whether you're going to fail is the customer. That means you need to get real users giving you feedback as soon as possible. The last thing you want is to spend two years building a project in secret, only to release it and find out nobody actually wants it.
Finding Your Idea
Now that you're in the right mindset, it's time to come up with an idea.
Recently, I came across a trendy new "manosphere" channel telling men how to live the "gigachad lifestyle." Weirdly, I was the one narrating it... except I don't recall ever doing that. That's because they were illegally using my cloned voice!
I could tell the FBI to find this guy and put him in jail, but I actually like the idea of people replicating my voice for mass distribution. So that's how I came up with the idea for "Vocalize.Cloud"—a platform that allows people to use my voice legally, along with the voices of many different celebrities.
So far, I've reached out to Morgan Freeman, Tom Cruise, Scarlett Johansson, Michael Jackson, and others. None have gotten back to me yet, but I did get a green light from A-list Hollywood actor Dax Slame (you might know him from 21 Jump Street or his YouTube channel). We even collaborated on an AI cartoon that combines Meta's new character animator with Midjourney and the voice cloning technology I'm about to show you.
Validating Your Idea
There's one big problem with my side hustle idea: I have no idea if anybody actually wants to use it. Before you get too deep into an idea, it's crucial to validate it. Most of us don't want to admit that we're delusional and our ideas are garbage.
In my case, I have a YouTube channel to promote my idea, so within 24 hours, I should know if I have a billion-dollar idea or if I need to take this app behind the barn and shoot it.
Here's another thing you should know: ideas are cheap; execution is everything. By execution, I'm not talking about the technology itself, but rather the business model. You could build the most awesome app in the world, but if you don't have a good marketing plan, nobody will ever use it.
If you're rich, you can pay for advertisements or pay influencers to promote you. But assuming you're not, you'll likely have to do some form of organic marketing, usually through social media like Twitter, YouTube, TikTok, or whatever platform works for your audience.
It's no different than fishing:
1. Figure out where the fish are
2. Put out some bait (like an advertisement or call to action)
3. Once a user signs up, provide them with an awesome service they'll be happy to pay for
Choosing the Right Tech Stack
Now that you know not to write any code until you have a marketing plan, let's talk about choosing the optimal tech stack.
Here's a secret: it doesn't matter if you use WordPress, React, Angular, or build some kind of freak show on Kubernetes. Nobody cares except the tech bros on Twitter. The only thing that matters is that it works.
Peter Levels, another indie maker who earns at least $3 million a year from various side hustles, uses boring old PHP and ignores all the trendy developer products tech companies try to sell you. The key is to find technologies that optimize your productivity and stick to them unless you have a really good reason to move somewhere else.
For me personally, that tech stack is Svelte Kit and Firebase, also known as the "SF" stack. I also use the Carbon Design System from IBM—it helped me build the UI very quickly. In most of my projects, I use Tailwind and build something more custom from scratch.
Ideally, you should have a great design to go along with your app, with a landing page that immediately explains why anyone would want to pay for your product. The design should be:
1. Functional
2. Beautiful
3. Unique
In that order. A great place to find inspiration is mob.com, which curates designs from top web and mobile apps.
My Tech Stack Breakdown
With any tech choice, there are tons of trade-offs, but I want to highlight why this particular stack makes me so productive:
Frontend: Svelte vs. React
Most developers choose React, but I choose Svelte for a simple reason: I just like writing Svelte code more. One thing that's extremely demoralizing is working with tools you don't like. I even wrote my own library called "Svelte Fire" that integrates Svelte stores with Firebase data. In the code, it allows me to read data from my backend database by simply putting a dollar sign in front of the reference for that data.
This is literally all the code it takes to get an authenticated user and fetch the data owned by that user—pretty cool, right?
Backend: Firebase
Firebase has some negative trade-offs like vendor lock-in with Google Cloud, and it can be expensive in certain situations. But here's how it simplifies things:
When a user submits a form to get a voice clone sample, it writes the text to the Firestore database. On the backend, several things need to happen:
1. Reach out to the 11Labs API (the service handling voice cloning)
2. Save the audio file in a cloud storage bucket
3. Generate a secure download URL accessible only to that user
4. Show the user a loading state and update the UI when the job is done
With Firebase, when the initial document is saved in Firestore, it triggers a background function that does all the work securely. We don't need to expose any HTTP endpoints to the frontend.
What's really awesome is that the Firebase SDK on the frontend keeps the database in sync in real-time. Initially, the document has a status of "processing," then changes to "complete" once we have a download URL. In the Svelte code, this allows us to use an if statement with the real-time store that produces elegant, simple code.
Additionally, we can secure this code by ensuring the authenticated user only has access to their own data with just a single line of code in the security rules.
Database Considerations
The next huge component of any application is the database. Firestore is a document database that's fast and easy to use, but not always suitable for highly complex data relationships.
In my case, I just have users, and users can generate many audio clips—a simple relationship that's perfect for Firestore. But choosing the wrong database can be a disaster.
In general, relational databases like MySQL and PostgreSQL are the safest bet for most applications, but they're not immune to their own problems. The YouTube channel Code Dam has a great eye-opening story about how they hit the limitations of "limitless scale" with Prisma and Planet Scale.
The bottom line: do your research and be careful when choosing a database.
Making Money with Your Side Hustle
How do you actually get that money? Unless you're some kind of psychopath, you'll want to use a payments API. In my projects, I've always gone with Stripe, but there are many other providers out there.
In my application, I give users 100 free tokens to get started. In my opinion, it's always a good idea to have some kind of free trial to let users try out your app. In this case, you can use my app for free, but once you run out of tokens, you'll need to buy more.
To handle payments, we have an authenticated Firebase Cloud Function that generates a checkout session on Stripe, which redirects the user to a hosted checkout page so we don't have to code up any UI manually.
Once the user makes a payment, Stripe sends a webhook to our server (another Firebase Cloud Function). The webhook contains data about the payment, so we can look up the user in Firebase and update Firestore with the tokens they purchased.
I'm also using SendGrid to send a transactional email to the customer with their order confirmation.
But how much should I charge for these tokens? I'm going to use a technique they teach in business school called the "Vercel strategy." 11Labs charges 18 cents per 1,000 characters generated with their voice cloning service, so I'm jacking up the price to $6.90 per 1,000 characters.
And that, my friends, is how you build a money-printing machine.
And that, my friends, is how you market a side hustle within a blog post about side hustles! Thanks for reading, and I'll see you in the next one.
Comments
Post a Comment