Why does it take so long to launch products? Building working MVPs in a matter of days doesn’t have to be a dream, and no, you don’t have to be the world’s fastest developer. You will quickly become a well-paid developer though.
I learned web dev a year ago and already make far more $ than I did after spending years as an Android developer. If I shared the dollar amount I make across all my projects, you probably wouldn’t believe me, but it’s easily found if you’re a good detective.
If you don’t get triggered, you can might make an extra $100 over the next week using the principles discussed here.
Skill != speed.
The line of thinking that assumes this is not looking at the entire picture. To build the same thing feature for feature will take the average developer just as long as another average developer, so it’s a nice thought to assume that’s why you’re slower. The first thing that broke this myth for me, though, was when I was watching objectively lower-skilled developers completely crush me on timelines. After mending my ways over the last few months, I can honestly say that there’s a better way for a professional dev. If you know what you’re doing, there’s no reason you shouldn’t be able to deliver software faster than the newcomers to the field.
Ultimately it comes down to two trios. The first is Reuse, Leverage, and Value. Let’s look at them in reverse order.
Value
Not all features are created equal. Recently Dan Kulkov brought up on Twitter how getting a 100% on PageSpeed Insights score is not how you bring value to your users. Business savvy builders get this. Nerdy devs, don’t. There’s nothing wrong with being a nerd, but not when it comes to thinking about what your customers really want. Unless you’re selling to other developers, pay attention to what really matters to the user’s outcome. Stop worrying about what is technically complex.
Leverage
Have you tried no code tools? Using GPT to debug an issue? Hiring off-shore talent? These are the sorts of things less technical founders are doing and they’re winning. They’re not worried about whether they’ll be respected by their peers for using TDD from day one. They traded Kubernetes for revenue. Why don’t you?
Reuse
The electrical engineering field figured this out way better than software engineers did. Finding the right software component to plug into your system without bloating it can be hard. Hardware documentation is far more thorough and pedantic than documentation for software. Even so, there’s more than likely a plethora of libraries that have done what you’re trying to build – and as hard as it is to believe, they probably did it better. Why not reuse other people’s code as heavily as you can? Bloat, you say? Who cares, you’re building an MVP. It’s supposed to be fast to build because realistically chances are slim it’s going to work out longer than a few months. If you find product-market fit, it’s not like your market will disappear if you hunker down and build it the “right” way later on.
The next trio is well known. There are three main aspects of an MVP we need to consider:
- Time
- Quality
- Scope
Pick 2…well maybe just 1.
The golden key – mercilessly restricting the scope – will get you further than you might think. But that’s not all. To build an MVP, the quality also needs to be diminished. It hurts your pride, but optimizing software is premature at this point. Improving the UI needs to have a hard line that you’re not going to waste time crossing. To expand on time is to give yourself less attempts at the game. If it takes 100 tries to win, you better move faster.
In Practice
It took me 3 months to build the main features of GoClose, 48 hours to launch a version of PromptEditor, and about 10 hours to launch an early bird version of Find Market (what I’m calling it right now).
You aren’t going to build Photoshop that fast, but most indie projects could be 80% replicated in a week. Once you’ve built something from scratch in a specific stack, you get a lot faster. I can start a new Django project and get it deployed to Heroku with a custom domain setup in less than an hour.
Don’t waste time writing 20 authentication flows for each social media login. Copy/paste the username and password flow you built on your first app and then change the names in the view.
Cut features religiously. Just focus on one core piece. For Find Market, I decided the most useful thing (that people were already asking me for) was a database of the ideas I had. I didn’t remake a sortable, searchable table – I just used Bootstrap Table. This was my first time using it, so getting that right took up the largest part of the 10 hours tbh. That was the core thing and I wanted to make it as useful as possible.
Then it was just a matter of getting the database models setup. I use Django’s ORM to setup the database, so it’s pretty simple to just define all the fields you need (and I’ve been doing Django consistently for 6 months, so that took me all of 20 minutes to get right).
Next I wanted a way to focus on just the marketing ideas the individual user was working on. So I made another DB table to track “My Ideas” and added a new page to add/remove from that list. Also wanted a way to track work, so I added a few modal popups to handle adding time/money spent per marketing channel.
None of this is hard unless you’re trying to do it for the first time. This is where day 1 ended – besides screenshots + writing a bit of copy on Gumroad. Yes, I used Gumroad to collect payments to save even more time setting up all the Stripe logic.
The last part I needed was graphing. I wanted date range pickers to automatically update a line graph to show hours worked by day + money spent by day. I knew making my own range picker was out of the question given the constraints, so I looked around for packages. Most of them sucked, so then I looked in the browser source for a website that I liked the date picker on and was able to find a lesser-known package that looked awesome. That took probably an hour to set up.
For charts, Chart.js is simple and I’ve used it before. But honestly I think they look pretty bad without a good bit of customization. I decided this time to try Apex charts.
It could’ve been faster.
Knowing what I know now, GoClose could’ve had an MVP in a day. It wouldn’t of had a UI, it would just be a few Zapier calls to send email responses when it saw a new message. The defining feature would be that it understood the entire thread. If I couldn’t figure out how to make that part work in Zapier, I would’ve made a simple API to handle a quick IMAP query that could be accessed from Zapier. This would already be a huge improvement on all the Chrome plugins that just feed the latest email into a ChatGPT prompt.
Action taking
Stop, don’t close the page just yet. It’s time to actually take action. What good does reading this do if you don’t change your behavior?
As homework, identify what the #1 core feature is of what you’re working on. If you’re new to your tech stack, give yourself one week to get that as good as you can. If you’re experienced, launch it within the next two days.
