Don't forget to start small
This is just a reminder to start small. Whatever plan you have for your product is probably too ambitious for a starting point. By paring things down a bit, you can avoid some nasty problems that kill a lot of indie hackers' dreams:
- spending weeks, months, or years building the wrong thing
- getting burned out before you get locked in*
- getting distracted by another shiny object before you get locked in*
- releasing something crappy, because it took so long to create that you don't have time to make it good
- not ever getting started because it's too intimidating or complex
- etc.
(*locked in = getting to the point where external factors besides just your intrinsic motivation can help keep you going, e.g. actual users or customers)
In addition to avoiding some of the deadliest traps, one advantage to starting small is that you can collect feedback quickly. You get the best feedback when you release, so you want to release often, which means releasing quickly, which means small releases.
Another advantage is you can start building an audience earlier. The best tip for building an audience is to "be useful on the internet." If you create something people find valuable, that counts as being useful, even if it's small. In fact, some of the best "small" starting points are often indistinguishable from tactics normally reserved for audience building: tweeting, blogging, sending an email newsletter, etc. For example, Indie Hackers is a thriving community, but it started off as just a blog. Y Combinator started as a talk.
Start small is something you want to think about sooner rather than later. It's easy to start small, but it's very difficult to start big, regret it, and then try to get smaller. By then it's likely too late, unless you have the strength of will to throw away a lot of your hard work, which you probably won't. It's better to avoid that situation in the first place.
I wish I read this post four years ago :)
It took me awhile on my own, but I think I'm finally seeing the right path forward.
Great advice. Especially the warning of, “releasing something crappy, because it took so long to create that you don't have time to make it good”.
It can be so easy to get caught up with grand ideas, but excellent execution really takes up a lot of time.
Frankly, I’m very guilty of this. When I started building PanelJam I had no backend experience. I was also very naive about the difficulty of delivering an in-browser drawing application that actually performs well across devices.
At the time, I had experience building custom Wordpress sites, and small JavaScript games. Yet I thought it would be a good idea to build a freemium social network and in-browser drawing program....needless to say, this left me to release something that sucked.
Some things that sucked:
a rather janky responsive layout (because I targeted tablet-first and then went in either direction up or down for media queries...don’t do this, it’s too much to maintain)
Up until 3 months ago, all images were delivered through the database, not cdn. (SLOW)
Bugs everywhere, front and back...
It’s starting to not suck, but it’s taken a year of development since launch to get there. If there weren’t users saying how much they “love” the platform (despite all the shortcomings) and if I wasn’t just very passionate about the problem myself, I would have killed the project long ago.
But in a way, the contrast of having users review the website as something they “LOVE!” next to my long list of problems with the website keeps me going. I figure, if I can incrementally improve, maybe I’ll have something great... but this isn’t necessarily a route I’d recommend. Don’t bite off more than you can chew :)
Always a great reminder, Courtland! The bar is really high for new products in many categories. That high bar is often about experience, not feature set. I advocate investing / thinking about the experience, while being ruthless in keeping features minimal.
Best advice ever, I wish I read this one year ago when I left uni… Probably wouldn’t have understand it tho, now I dealt with it first hand.
As with all things involving a product... it depends.
And it's usually not even solely dependent on the product: it also depends on the size & competitiveness of the market, the sophistication of the customers/audience (how problem aware and how solution aware they are), and the complexity of the “need”.
Some situations lend themselves well to a bite-sized approach. But other situations demand a more involved approach.
Instead of a “start small” mantra, how about this:
Don't forget to start simply.
Start as simply as you can.
It's not just semantics. Just by replacing the word “small” with “simple” (or “simply”) the advice is much more useful.
I coined a term for starting small at our last meetup. Launch a MAP ‘Minimum Available Product’ 😏
Except when entering a crowded market, where product to market fit is known.
Entering a crowded market is even more reason to niche down since it can be hard to differentiate yourself from existing mature solutions.
Your answer is based on maker mentality. I suggest, out execute. Makers are scared of competition.
Thank you for this, Courtland!
Great tip! Super valuable to keep in mind! Thanks
The advice is great, but nfortunately, it doesn't work always.
There are situations when you can't start small just because of the project's nature. For example, if you try to create the next bubble.is (or something like that) you can't start small - your product just will not have a value.
But of course, it's always possible to provide a minimal set of functions - at least to evaluate the idea. The problem is "minimal" means different things for different projects.
I don't necessarily agree. I want to write a post on this, but I think a common assumption is that all startups looked the same at the beginning as they did at the end, but just smaller or with fewer features. The reality is that, often, the best path is to build successful product X is to start by building a totally different product first.
Two examples: Nomad List and Indie Hackers are both communities, but Nomad List started as a spreadsheet and Indie Hackers started as a blog.
I agree some transformation may happen, but not necessarily. It's just "a pivot".
I think it’s still possible to start small in this case. Maybe make Bubble tutorials, templates etc - maybe a plugin (if they exist with Bubble - never used it).
No! Tutorials and templates (especially about Bubble) is an absolutely different idea.
I'm talking about the idea to create IDE, and I mention bubble just as an example.
It has nothing to do with it, actually.
So, you have an idea to create a better web apps builder. How you can start small?
I guess I disagree with you - you’re working to solve a problem - tutorials and guides can help you get started on that journey without hiding away coding for months or years.
You then have an audience that you can reach out to when you start building whatever you decide to build - or you might learn that the problem you were looking to solve doesn’t exist or is already well solved for and your unique selling point isn’t something anyone wanted.
I also think starting as a first time founder with a web app builder or something as complex might be too ambitious - practicing shipping smaller things is probably wise.
I think good examples which are related:
AJ from Carrd built and sold HTML templates before building Carrd
Steve from Site Builder Report ended up scrapping his site builder and making a site that compares other site builders instead, which was much more successful
Obviously not all advice applies to everything, but for the audience of this site, it probably applies more often than not.
Well, you mixed different things together.
AJ from Carrd didn't start his product small. He started it because he got bored with building and selling templates and they were 2 different stories.
That's how he came to the idea of a website builder. And as soon as he came to it, he started building it and it was not small (although a builder of simple websites is no too complicated per se).
Thank you for your advice.
Thanks for the reminder @csallen
This comes at a good time for me, I was just saying "Think of things that do not scale ;-)" after I added an item to the feature list :-D
Very much true!
You mention collecting feedback quickly, do you have any tips on how to do this?
The book is awesome too!
All the best!
Thank you..i constantly remind this daily
Thanks for this reminder.
Great reminder.
Also, doing things that don't scale in the beginning. E.g., hard coding stuff, sending transactional emails manually, etc... until you're locked in.