What's New: Advice for first-time founders

(from the latest issue of the Indie Hackers newsletter)

What do you wish you had known when starting out?

• Founders share their top advice below. Whether you've been indie hacking for a while, or are just starting out, check out these gems for encouragement.
• Is website redesign a challenge for you? These tips can help you structure your redesign tasks into manageable, accessible chunks!
• Founder Allison M. harnessed the power of invite-only launches to curate a passionate, dedicated user base. Here's how.

Want to share something with nearly 95,000 indie hackers? Submit a section for us to include in a future newsletter. —Channing

💬 Advice for First-Time Founders

by Rand Assi

What do you wish you had known when starting out? Whether you're a new or established founder, advice from other indie hackers can be helpful!

Don't be afraid to pivot

Have you:

1. Completely skipped talking to customers,
2. Spent months creating your product, and
3. Realized that no one wants to buy?

PIVOT.

Talking to customers is the most important thing that you can do when building a startup. Figure out what the people want and build it, not the other way around. It's not a marketing problem at this point, it's the fact that you built something no one wants.

Months to build = months to sell

Anil K. ponders what happens when founders don't have any customers to speak with?

I never had any potential customers to talk to before building anything. It's almost like the chicken and egg problem.

People don't often think about what they are missing until we show them what they "need." We didn't "need" Facebook or Instagram. Before they existed, no one was crying about not being able to share photos of what they eat or drink.

I think that "no one wants to buy" is a misconception. We are the ones who are failing to convince people to buy. The selling part is just as important as the building part, if not more. We need to give people reasons to buy it.

Keep in mind that, if it takes months to build, it's going to take months to sell.

Minimum viable community

Arun Pariyar thinks that anyone who wants to start building should start with a minimum viable community. Talking to anyone who likes your idea, and getting them all into a common space like Slack, Discord, WhatsApp, etc., is priceless. Build in public with this community.

Greentfrapp adds a piece of advice:

Here's a trick that I learned from Jake Knapp's book Sprint:

All you really [need] to check is if people want this.

This means that you can gauge their reactions with anything, ranging from a landing page to a flyer. Even a dummy app built with PowerPoint or Figma can work. One example listed in Sprint was helping a company test reactions to a new industrial pump using brochures that potential customers would have seen in a sales meeting. You don't have to overcomplicate this!

Stick to your principles

Adam Isaacs Rae advises to not be afraid to get feedback and build in public.

Also, be sure to stick with the principles. What core problem does your business look to solve? Does the solution that you’re providing really do that?

I’d say that getting a cofounder could be well worthwhile, depending on your business. Finally, don't forget to have fun! Building a business is always going to be work, but it should be a bloody laugh along the way, am I right?

What are your tips for new founders? Let's chat below!

Discuss this story.

📰 In the News

from the Volv newsletter by Priyanka Vazirani

💰 Online traders plow into Twitter, thanks to Elon Musk.

📹 Only 12% of content creators make over $50K per year, according to Linktree.

😵‍💫 CNN's new streaming service will shut down weeks after launch.

📱 Why are there suddenly fewer viral moments on TikTok?

🥸 The fake artist problem on Spotify is much worse than you realize.

Check out Volv for more 9-second news digests.

🛠 How to Structure Your Website Redesign

by Victoriia Stets

Is website redesign a challenge for you? For some founders, it can seem like a nightmare. Between the long list of tasks, and differing opinions on the internet, you may be wondering how to even get started. These tips can help you structure your redesign tasks to make the job more manageable. Let's dive in!

1. Research

Research will become your best friend! Don't even attempt a redesign without some background analysis.

Here are your main steps at the moment:

• Audit: Examine everything you have and find the major pain points. Think about how to solve the business problem with a design. If the client has the analytics, ask for it.
• Research: Conduct deep market and user research.
• User interviews: Find the audience and ask them all sorts of questions.
• Mood boards: Brainstorm, be creative, and think outside of the box!

2. Structure your research

• Informational structure: Compile everything that you have, and organize content in an engaging flow.
• Wireframes: This is your website skeleton. Connect your website info to see the content layout.

3. Design

• Design concept: This is your very first design attempt, so don’t be afraid to make a raw draft. Here, ask for feedback, and try to design the main pages.
• UI work: Dive into the main work! Do your best, and don’t forget to implement all of your work from the previous steps.

4. Documentation

Prepare all of your documentation so that you can use your new redesign elements in other materials.

Guess what? You have now upgraded your website to a new level!

Learn more about the website redesign timeline, background, and main mistakes here!

What are your top website redesign structure tips? Share below!

Discuss this story.

🌐 Best Around the Web: Posts Submitted to Indie Hackers This Week

📝 Where to launch your MVP. Posted by Carlos Avendaño.

🤷 Which license should I use for open source? Posted by Mohsen Kamrani.

🧐 Identifying real versus charlatan founders. Posted by Darko.

👀 The big Twitter debate. Posted by Austin Parker.

🧚 Companies that launched as startups are now completely out of touch. Posted by Saul Fleischman.

👥 How do you authenticate and manage users? Posted by Ropesneer.

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.

💌 Allison M.'s Invite-Only Launch

by Allison M.

Hello my fellow Indie Hackers! I'm Allison M., founder of Sidekick, a productivity tool that blocks distracting sites and schedules pomodoro sessions.

A little while ago, I read this Indie Hackers post about launch strategies, and it got me thinking about how grateful I am for my own. Since launch is one of the biggest milestones for a new indie hacker, I wanted to share some reflections on my approach.

Along with many other questions, many of us ask this one: Invite-only or public? I went with invite-only, and here’s why it was the right choice for me!

A quick overview

In April 2021, I launched Sidekick to private beta, otherwise known as invite-only.

My earliest adopters were my friends, and from there, it grew through word-of-mouth. After the first 30 users, I started participating in different Reddit communities and submitting Sidekick to sites like BetaList.

I spent time with users through email and in our Discord community. There, I shared my roadmap, behind-the-scenes updates, articles, and memes. I also sent out the occasional product poll.

Within eight months, I had grown our user base from two to 100, released 12 major features, resolved many bugs, and implemented UX/UI improvements. On January 1, 2022, we transitioned to public beta.

Why invite-only?

Here’s a quick TL;DR for the main points on invite-only versus public beta:

As you can see, there are a lot of reasons to do invite-only launches. For me, the most compelling reason was maintaining a tight feedback loop.

A good feedback loop was so important to me because it meant a direct channel to the people using my app. There are two parts of a feedback loop:

1. Receiving feedback: Invite-only meant launching to a group of people who were truly interested in Sidekick. I knew that this would lead to quality feedback, instead of spam or distractions.
2. Addressing feedback: Sidekick is a team of two, so I had to be realistic about our time. I knew that the only way we could address feedback was to keep the group small. Putting all of this together led to iterations every single week. We saw Sidekick change right before our eyes, and that was all thanks to our users.

To my surprise, this approach created the feeling of a small family among my beta users. It gave me the opportunity to truly connect with them, and ask them what they were working on. We also celebrated every day wins with the actual humans behind the screens.

This wouldn’t have been possible with a large group!

Quality > quantity

When asked about quality versus quantity, I choose quality every time. Sidekick doesn’t have huge numbers, but it does have a small group of people who are hugely passionate about the product and the concept of deep work. And that means everything! It’s why the product is improving, why it will continue to improve, and why, one day, Sidekick will have bigger numbers.

Although I’m a strong advocate for invite-only launches, everyone is different. What works for me might not work for you, but hopefully this gave you something to think about!

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 Rand Assi, Priyanka Vazirani, Victoriia Stets, and Allison M. for contributing posts. —Channing