Don't ask other founders whether your idea is good or bad: - **Ask about tactics and strategies. Here's when it makes sense to get** feedback from other founders, and the best questions to ask for helpful, actionable advice. - **This SEO checklist an
Don't ask other founders whether your idea is good or bad:
-
Ask about tactics and strategies. Here's when it makes sense to get feedback from other founders, and the best questions to ask for helpful, actionable advice.
-
This SEO checklist and list of resources can help small teams craft an effective strategy. Remember, your top goal with content is to create something valuable or interesting, then go after SEO!
-
Founder Colin Bartlett built a side project for a client, and grew it through word-of-mouth. When the project staled, he sold to someone who could grow it further. Here's how he decided to sell, how he found a buyer, and his tips for a smooth transfer.
Want to share something with over 90,000 indie hackers? Submit a section for us to include in a future newsletter. —Channing
👂 Asking Other Founders for Feedback
from the Founder Flubs newsletter by Kevin Conti
Founder Flubs is my take on the most common mistakes that I see from running startups and working alongside hundreds of founders over at Software Ideas.
Here's why asking other founders for feedback can be a Founder Flub.
Feedback trap
If you're a first time founder, you may be tempted to build an entire product, launch on Product Hunt, and wait for signups to roll in. The problem with this approach is the lack of customer conversation, as evidenced by Tom Hunt's interview on Failory:
AskTina built an MVP [and] had 35 experts install it on their blogs. With 10K page loads of the widget, we had zero paid calls placed through the software.
Ideally, we could have discovered this before we spent six months working on AskTina by interviewing the readers of specific blogs.
This route will push your customer exploration back until after the product is built, which isn't great. Reaching out to your target companies with no product at all isn't the best approach, either.
You may decide that the best course of action is to seek feedback from other founders. On the surface, asking founders for idea validation sounds great. After all, they'll have fantastic insights on marketing strategies, sales, and even positioning your product for the right audience.
But here's the problem: You're asking the wrong people. Take it from Jon Yongfook's recent Indie Hackers post:
Hands down, one of my most hated questions is [about getting the first X customers].
The question is not specific enough to gain learnings from. It makes the indirect assumption that both Product A and Product B are equal. Therefore, by knowing how A got customers, one can apply the same methods to B, and enjoy the same success.
Why do founders miss the mark?
Why do founders seek validation from peers instead of potential customers? Personally, I think there are two major reasons:
- They don't actually know how to reach their customers. A lot of founders are so focused on the product that they miss the critical step of identifying how to reach their target audience. Instead of exploring how other founders have approached this problem, they ask other founders for product feedback.
- Many founders believe that, if someone reads their post and likes the idea, they'll ask to be an early customer. But the thing is, if the people reading it aren't in your target audience, you're just wasting your time.
When does it make sense?
There are two scenarios in which it makes total sense to ask other founders for feedback on whether your idea is good:
- If your product actually targets founders.
- If particular founders have experience in the market that you are building in.
Best questions to ask
Here are a few great questions to ask founders for helpful feedback:
1. Can you please look at my landing page and see if it comes across as a trustworthy, reputable site?
Notice how we are intentionally moving away from getting idea feedback here. Instead, we are trying to understand whether people feel that the site is trustworthy enough to convince people to buy.
Site trustworthiness is something that, in most niches, won't change from person to person, which means that founders are usually just as good as a real customer for giving you this feedback.
2. Have you seen success with X marketing channel? If so, what's your product and strategy?
Here, we focus less on our own idea and focus on a particular marketing channel instead. This could be Twitter, SEO, or any other way to reach customers.
Again, notice that we are explicitly avoiding asking whether an idea is good or bad. That's not where you get the most valuable learning from founders as a whole.
3. How did you build a successful product without an audience?
Hopefully, you're seeing the theme: Don't ask whether an idea is good or bad. Ask about tactics and strategies.
What are your tips on asking other founders for feedback? Let's chat!
Discuss this story, or subscribe to Founder Flubs for more.
📰 In the News
from the Volv newsletter by Priyanka Vazirani
📖 Ukrainian creators are using OnlyFans as an unexpected war diary.
✍ This NFT novel is being written by its readers.
💁♀️ Women are outpacing men as first time crypto purchasers.
🚘 Sony and Honda plan to make electric vehicles together.
🤪 This company offers masturbation breaks to employees with "Wank pod" and VR.
Check out Volv for more 9-second news digests.
📝 SEO Checklist for One-Person Teams
from the Building No-Code newsletter by Matthew Busel
At Whalesync, we believe that content is essential. It gives us a way to spread the word about our product, while sharing ideas that we think will be helpful to others. While large companies have dedicated content teams, if you're like us, you may only have a single person responsible for the process.
With limited resources, we needed to find 80/20 solutions for our content and SEO strategy. Having waded through a sea of articles and playbooks, we identified a few top resources that work for us. Below are a few of our favorite resources, and a simple SEO checklist that we run new content through. The checklist is just a small piece of the work necessary to rank on Google. I hope that it can serve as a kickstart for other individuals trying SEO on their own!
SEO and content resources
SEO Checklist
1. Title and meta:
- Ensure that the target keyword is in the <title> tag (name) at the front.
- Ensure that the target keyword is in the <meta> description (short description) at the front.
- Try to make the title tag <65 characters.
- Ensure that the target keyword is in the slug.
2. In-post:
- Ensure that the target keyword is in the first <h1>.
- Put your keyword or synonyms in other header tags (<h2>, <h3>, etc.).
- Check that the length of the post is in the ballpark (minimum 300 words).
- Ensure that the target keyword appears in the first paragraph of the post.
- Make sure that your keyword (or synonyms; Google recognizes them now) is used other times throughout the page. Your keyword density should be between 0.5%-2.5%.
- Add <alt> tags to all of the images in the blog post that contain your target keyword.
-
Tinypng all of the images.
3. Links:
- Add links to past articles where relevant.
4. Editing:
Remember your goal
Your number one priority with content is to share something valuable or interesting. Keep that in mind before worrying about SEO.
We don't always do everything on the above list. For example, this piece itself does not check every box. First ensure that your content is valuable, then look for ways to make that content visible to more people using SEO.
What are your top tips on SEO? Share your experience below!
Discuss this story, or subscribe to the Building No-Code newsletter for more.
🌐 Best Around the Web: Posts Submitted to Indie Hackers This Week
🤓 Focus is king. Don't waste it. Posted by Miguel Ferrer Isaza.
🤷♂️ Is Product Hunt a waste of time? Posted by Mark.
👩💻 Alternatives to finding a cofounder. Posted by Maddie Wang.
🧾 Your mission doesn't pay the bills. Posted by Can Olcer.
💵 How long did it take you to reach $1 MRR? Posted by Darko.
📰 Building in public led to a feature in The New York Times. Posted by Alexis Grant.
Want a shout-out in next week's Best of Indie Hackers? Submit an article or link post on Indie Hackers whenever you come across something you think other indie hackers will enjoy.
💰 Colin Bartlett Sold a Stale Side Project
by Colin Bartlett
Hi indie hackers! I'm Colin Bartlett, and Clear Check was born out of development work that I did as a freelance software developer. I built it into a small, but profitable, micro-SaaS back in 2015. Soon, other ideas became my daily focus, and Clear Check started languishing. So, after much debate, I sold it for around $5K in 2021.
Born from a client's idea
I have been building web applications for close to 25 years, mostly as a consultant and freelancer. Back in 2015, a customer came to me with an idea. They had a child who was a member of a local youth football team. Due to new state laws, the team was suddenly required to collect a lot of paperwork from each volunteer adult who worked with kids. The law was meant to protect kids from abuse, but it put a huge burden on small nonprofit organizations. Each team was required to collect a photo ID and several background checks from every adult, and keep detailed records.
My client was looking for a way to manage all of this paperwork, and came to me with the idea to build a scaleable solution. He asked if I would be willing to build it at a reduced rate in exchange for the ability to sell it to other teams.
Usually, I would not entertain these arrangements, but this project had one advantage: I thought that it could be built pretty quickly, and at low risk for me.
Building and marketing
The football team had a minimal budget, so we agreed upon 25 hours of work for the project. I was pretty confident that I could get something basic out the door in that amount of time. I used that 25 hours and was paid for the work, but making the product more market-ready probably took another 50 hours, which I did on my own time.
After launching the service, my client and I attracted other local teams simply through word-of-mouth. Over time, I spent at least another 50 hours adding more features and making the service more useful to those new customers. We raised the price a few times, and ended up with a handful of paying customers. Each customer was paying between $500 and $700 per year for the service.
To sell or shut down?
Clear Check grew to ~$2.5K ARR, but I had no idea how to properly market the product. Several years passed, and the same original customers were still the only ones using the product. There was no growth, and I had no time to dedicate to marketing. I had ideas about making it more useful to other markets (other groups besides sports teams), but no time to do so.
By this point, I had taken on a business partner. The two of us worked together on other products, one of which, StatusGator, was actually gaining traction.
After much debate, I decided to try and sell Clear Check. I didn't sell for the money, but to make sure that existing customers could still use the product. We posted the project on Flippa and SideProjectors, and listed Clear Check at around twice its annual revenue.
Eventually, a buyer from SideProjectors decided to meet our asking price. We agreed to accept half of that upfront, and the other half when all of the existing customers rolled over and renewed. This was a few months away, so it meant that he would only be paying about $2.5K for the product. The rest would come from the money that the existing customers paid to us. We accepted the deal with a straightforward one-page contract, and facilitated the transfer of assets and code.
Smooth transfer
The transfer was pretty easy, and was done over the course of a few days. We planned ahead and made a checklist. We did not use escrow for this process; we simply did this after the first payment and before the second. The amounts were small enough that neither party thought it was worth using an intermediary.
Thankfully, Clear Check always had its own Stripe account, which is something that I recommend to everyone. Make a separate account for every project, even if you have one parent company for them all.
We added the purchaser as an admin collaborator on Heroku and GitHub first, then Stripe. We used Codeship for CI, but also already had a separate organization, so we transferred that to him. We shared a zip file of various assets and minimal documentation, and had him initiate a transfer request of the domain name, which we approved.
The hardest part was the assets that were in S3. There were a few steps, so we had him create new buckets first. Then, we put the site in maintenance mode so that no new assets would be uploaded. Next, we synced them over to the new bucket. Once done, we changed the app configuration to use the new bucket and tokens, and took off maintenance mode.
After a few weeks, when we were pretty sure that no additional support would be needed, the purchaser took us off of everything as collaborators. Removing us as the owners on the Stripe account did require some manual work. He had to call them, then Stripe called us, and I verified some information over the phone.
Lessons learned
We are very happy with the process and the outcome. The process of selling was smooth, and having an established client base, even though it was small, made the product attractive to prospective buyers.
We are thrilled that we did not need to shut down the project. The money we earned was pumped right back into StatusGator, which is currently approaching $20K MRR. Not having the distraction of another project, or its support and maintenance requirements, has allowed us to be more focused.
Discuss this story.
🐦 The Tweetmaster's Pick
by Tweetmaster Flex
I post the tweets indie hackers share the most. Here's today's pick:
🏁 Enjoy This Newsletter?
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 Kevin Conti, Priyanka Vazirani, Matthew Busel, and Colin Bartlett for contributing posts. —Channing
