(from the latest issue of the Indie Hackers newsletter)
"Sell before you build" is common advice for founders:
Want to share something with over 95,000 indie hackers? Submit a section for us to include in a future newsletter. —Channing
by Mick
If I hear one more person say "sell before you build," I'm going to puke. This is such bad advice. It assumes that everyone will nail their product on the first go, when almost no one does.
If I had gone to potential customers and pitched Songbox to them with the initial version that I had in my head, I would have gotten nowhere. And, if I'd given up on it at that point, I would have missed out on having a business that's well into a couple of thousand in monthly revenue, working with some amazing people, and having truly exciting, unique experiences.
There is no doubt that "sell before you build" will work for some people, but for the general populace of founders, it is crushingly bad advice. Thoughts?
Nikita says that "sell before you build" helps save time:
The whole point behind this idea is that you need to validate that people are ready to pay for your product before you actually build it. It saves you time, money, and energy. It's painful to spend 6-12 months building something that nobody will buy or use!
People buy on emotions, not on logic, even in B2B. A good approach is to talk to people to discover their pain points, not to sell your product. That way, you're coming from a place of helping, not being a salesperson.
If your potential customer is not solving their problem in any way, then the pain is not strong enough. They'll likely not buy your product. Don't push your product in a place where it doesn't fit. It'll only irritate your potential customer.
Seth King says that "sell before you build" is not recession-proof:
The concept of selling something that doesn't exist yet really took hold during the era of free money, and the most frothy bull market in history. That mentality isn't going to work in a recessionary market where people aren't just throwing money at anything that sounds nice.
I expect that investors and customers will want to see a product more in-depth before they use it and put money behind it. Dollars are tough to come by these days, and committing them to a new SaaS is more of a risk today than it was even six months ago.
People should just focus on building something that they think is interesting and appealing, then sell it once it's ready to be sold. Showing something that isn't ready is good for getting feedback, but it's also a risk. First impressions matter, and people will remember what that initial experience was like. If it's not good, it could keep someone from buying it. It's better to just wait to present the product when it's ready for the market.
And, by "ready," I mean that it should meet MVP expectations.
Eli Finer believes in "sell before you build" if it's done correctly:
Selling before building should mean having enough conversations with people to let your idea morph into something that people want to buy. It doesn't mean trying to shove your first idea down people's throats.
As you're talking to more people, you're going to need to come up with sketches, then mockups, then an MVP, then a fully usable product. Different people will be willing to commit at different stages. Looking for the right people to talk to only after you've fully built your product definitely makes things harder.
The best approach may to "build as little as you can stomach." Build enough to make a bit of your vision a reality, but not so much that you're deep in sunk cost fallacy world, struggling to morph your idea into something profitable.
Eric Bauman agrees:
I was brought in as COO of a funded startup when the founding COO quit, and the CEO was adamant that we sell before we build. We blew a huge amount of money on advertising to get those first sales since we couldn't actually show the product in use. We also burned all the customers we did get because we couldn't deliver within a reasonable timeframe. Everything that I warned him about ended up happening.
I quit shortly thereafter because we were just burning money, and I didn't want to do that without an end result in sight. This all happened a few years ago, and guess what? The product still hasn't been built. But, at least they've stopped trying to get people to pay for it.
I know that some founders are able to sell first, but this experience has completely soured me on the concept of selling something that you don't have yet. I'd much rather build something small, sell that, and build from there. I wouldn't want to go through this nightmare again.
Hans de Ruiter points out that the literal version of "sell before you build" is incredibly risky:
"Sell before you build" seems to mean different things to different people. I saw an online course that taught people to find a business problem by talking to potential customers, get pre-payments for said problem, then hire a developer to build the solution. That's literally selling before you build.
While that approach can work, it's very risky because it's far too easy to run out of money before you can deliver.
Did you sell before you built? Share your experience in the comments!
Discuss this story.
from the Volv newsletter by Priyanka Vazirani
👀 Inside RadioShack's sex-crazed Twitter account.
💻 The Netherlands is taking action to make WFH a legal right.
🤝 Many emails should, in fact, be meetings.
📵 Starting today, Japan will jail people for posting insults online.
🍿 "Rich Minions" are taking over TikTok, as millions of teens return to the movies.
Check out Volv for more 9-second news digests.
from the Trends.vc newsletter by Dru Riley
Revenue-based financing joins a growing list of options to fund your business without giving up equity.
Companies struggle to raise capital fast without losing equity.
Revenue-based financing helps you fund your business with no dilution, collateral, or personal guarantees.
Lenders are paid back from a share of future revenue.
Revenue-based financing examples:
Revenue-based financing platforms:
"This is expensive."
Yes. It's also fast. Each financing option has tradeoffs. Cost of capital is a downside for revenue-based financing.
"Isn't this just factoring or merchant cash advances with a different name?"
Factoring provides working capital towards sales that have already occurred (accounts receivable). Merchant cash advances, though related, typically have less company friendly terms, shorter payback periods, and are based on debit and credit card sales. Revenue-based financing factors in future revenues.
"You don't get the network and expertise that comes with VC funding."
Some founders want funding without strings attached. The expertise and network aren't always what they're cracked up to be. VC funding (applied to the wrong type of business) pushes for unsustainable growth, and kills profitable businesses.
"Why not just get a small business loan?"
Taking out a loan may take time, and requires lots of paperwork. Also, collateral and guarantees can lead to bankruptcy if the business does not perform as planned.
Go here to get the Trends Pro report. It contains 200% more insights. You also get access to the entire back catalog and the next 52 Pro Reports.
Subscribe to Trends.vc for more.
from the Marketing Examples newsletter by Harry Dry
Sometimes, it's as simple as looking at your product from a different angle.
Go here for more short, sweet, practical marketing tips.
Subscribe to Marketing Examples for more.
Hey everyone! I'm Soheil Rashidi, and a few days ago, volt.fm hit 1M users! My platform allows users to see and compare Spotify stats, promote their playlists, and discover new music. This is a huge milestone for the small project that I started 16 months ago. Here are the details!
I got the idea to build volt.fm two years ago after Spotify Wrapped was released. I was really curious to know what my friends’ stats were, and I wanted to show off my stats to them.
I decided to create a website that gives people a nice public page to show their top artists, songs, genres, and playlists.
Scaling to this number of users has been quite challenging. I've had to re-architecture the website a few times to make sure that it can handle the large number of users signing up every day.
In the beginning, it didn't even have a database other than the one for authenticating users. It just fetched data from the Spotify API and displayed them. But now, its database is 450 GB, and grows by 10 GB every 2-3 days.
My stack is NodeJS, Express, TypeScript, React, and Tailwind CSS. I use Postgres as my database, and RabbitMQ as my message broker.
Everything runs inside Docker on a few DigitalOcean droplets.
I hit number two on Product Hunt when I launched.
Before this project, I had launched two products on Product Hunt (Pikaso and PostSheet), so this time I was a bit more prepared.
I started with the checklist that I had prepared for PostSheet, and added a few new items to it. I also examined several successful launches to see what I could learn from them.
After that, I went through each item and prepared any material that was needed to complete it. That included preparing all the emails, social media posts, images, etc.
Days before the launch:
Right before the launch:
After the launch:
On launch day:
Day after launch:
My biggest channel for acquiring new users has been word-of-mouth. People love to show off their taste in music, so they share their stats on social media any chance they get. This has caused the platform to go viral on Twitter, Reddit, and TikTok numerous times.
Every month, I send an email to all of my users that includes a report of their stats. I am planning to continue to expand advertising in these monthly emails, and include music-related products and services that would be appealing to my community of music lovers. This is how I have monetized my product. By creating content that is interesting to a large number of people, I've built an engaged user base. Advertisers pay to place ads, which has been a better model for me than charging users.
My goal is to continue giving people more detailed insight into their listening habits, and to help them discover new music!
Discuss this story.
I post the tweets indie hackers share the most. Here's today's pick:
Forward it to a friend, and let them know they can subscribe here.
Also, you can submit a section for us to include in a future newsletter.
Special thanks to Jay Avery for editing this issue, to Gabriella Federico for the illustrations, and to Mick, Priyanka Vazirani, Dru Riley, Harry Dry, and Soheil Rashidi for contributing posts. —Channing