Back to Blog

Launching Our First MVP: Indie Hacker 𝕏

Reflections on building and launching our first MVP: Indie Hacker 𝕏. Lessons learned, challenges faced, and future plans.

indie hacker posts preview image

Posted by

Introduction

Indie Hacker 𝕏 is a directory app containing 50 of the best recent posts about indie hacking on 𝕏. It was created after I (Cameron) saw how many great posts I was seeing on 𝕏 every day.

I wanted an app that I could use to easily view my favorite posts and filter based on the topic I was interested in at a particular time.

It’s easy to read advice and later forget it if you don’t apply it right away. By being able to filter based on topics, I could look for articles that aligned with the current challenges I was facing in growing SwiftLaunch and reference them as needed.

The Development Process

I built Indie Hacker 𝕏 over roughly 3 days. I could have probably built it in 2 days under regular circumstances, but I was suffering from pretty bad jet lag after flying from Europe to Asia a few days prior.

I was also slowed down by the fact that I spent a few hours creating a wireframe in Figma. I often work with designers, but if I’m going to be doing client work I figured I should upskill here so I can quickly create wireframes for future clients.

wireframe using figma

Overall though, I still have about 5 years of software development experience so the technical challenges for this app weren’t too overwhelming. I am, however, still getting used to working on MVPs vs working on bloated enterprise projects where most of the foundational architecture decisions had already been made 5-10 years earlier.

While I enjoy the technical challenge of working on huge complex systems, it’s also a lot of fun to build something from the ground up.

I built Indie Hacker 𝕏 using Next.js and Tailwind. Unlike most developers, I don’t hate CSS, but Tailwind is great for getting an app up and running as quickly as possible. I’d planned to use Supabase and offer users an option to login and add their own posts to the database, but that brings me to the next point…

Challenges and Solutions

One thing I didn’t foresee was that the 𝕏 API had become pay-to-play. Previously Twitter allowed you to fetch posts for free, but that seems to have changed over the last year or two.

While I probably wouldn’t be out much money if I opted for live data, paying anything more than an annual domain renewal fee seemed excessive for what was effectively a portfolio piece.

For that reason, I instead architected the app such that the data was stored locally instead of being fetched from 𝕏 each time they visited our page. The good thing about this was that it simplified the app and allowed me to avoid any recurring fees (apart from the domain name).

The bad thing of course, was that if users wanted to add their own posts it would’ve required me to add in forms for them to enter the post’s URL, user’s URL, user’s name, post content, etc. I could’ve done this, but I didn’t expect to receive enough traffic for this small demo app to warrant spending an additional day implementing this.

Lesson learned? I need to be updated on current usage costs of any external APIs before building an app.

Launch and Initial Feedback

I announced the app on my 𝕏 account yesterday. The reception was pretty lukewarm to be honest. One person thanked me for mentioning them and said, “nice work”. That’s literally the only feedback I got.

The post received 3 likes, and roughly 500 views in the first 24 hours. I also got blocked by one of the people I tagged in my post lol.

I was wondering if it would look spammy because I tagged a lot of people, but I thought it was fine because it was just a list of people whose work was included in my app. Oh well.

Key Learnings

Technical Lessons

As mentioned earlier, wire framing a design is a good start, but it’s not enough to qualify as a robust plan for building an app. I also need to think more about the cost of external APIs before getting started and other potential backend/database issues.

Building this app helped me continue to become more proficient with Tailwind, whereas I previously used mostly CSS, Sass, and Styled-Components for styling.

Authority and Trust

Moving past the technical lessons, let’s talk about my account on 𝕏. While my account is currently on pace to grow 100-150 followers per month, that’s not enough to land clients as quickly as I’d like. Why?

Because having a large following is only one element of sales. As I gain more followers I’ll have a larger funnel and be seen as more of an authority figure. However, I still won’t be able to convert sales if my audience doesn’t fully trust me.

This is especially the case because selling a $1,000+ service is significantly more of an investment than a $9 ebook.

So what’s the solution? Simple. Be transparent and share my growth, my setbacks, and the lessons I learn along the process of delivering MVPs.

That’s why this blog post is being written, and why I’m going to make more of an effort to share my growth and the lessons I’m learning along the way.

Future Plans

Doing great work for clients is the only thing I care about. As the months progress the quality and complexity of demos SwiftLaunch delivers will continue to get better and better.

Interested in our world class price to value MVP service? Submit your idea here for consideration.