There are two types of side projects, both with different goals: learning something new & making a profit.

Greetings friend,

I started working on a project I’ve had in mind since early 2019, but I’m not starting by writing a ton of code. Instead, I’ve been doing waay more customer research than I normally do (not hard to beat considering I did almost zero research on past projects).

Drew Bredvick @DBredvick It’s crazy how hesitant I was to “hop on a call” to talk about my side projects six months ago. I’m calling five potential customers before initial commit this time. August 31st 2021 0 Retweets 19 Likes

​

This “validation” concept doesn’t apply to all side projects. This newsletter focuses on SaaS side projects with the goal of making a profit.

So where are these rules coming from? Well, they’re the things I’ve had to remind myself multiple times throughout this process of trying to start with an audience rather than a product (and a little from Arvid Kahl‘s great book, Zero to Sold).

These are the places I’ve failed on my previous SaaS adventures.

Rule 1: Find customers first

With SaaS, most of the time risk is not tech risk. The risk is mostly market risk, meaning “can you find a market for this product?”

The reason the risk isn’t tech risk?

We’re developers, building software is what we do. While some SaaS products are more technically challenging than others, they are generally not impossible.

Finding a market that doesn’t exist? Closer to impossible.For my current project, I’ve DM'ed several of my favorite builders on Twitter and asked for feedback on a one-pager of my product. I’ve gotten tons of great feedback already (great meaning “it’s impacted my roadmap”).

After I create a demo, I’m going to focus on getting five presales before shipping the finished product.

Rule 2: Build with tech you know

Speed matters on SaaS side projects a lot. Building with tech you know will help you be more efficient.

If nothing else, I’m consistent. My earliest blog post covers this exact topic:Tech decisions and developer guilt (drew.tech)​

All of my side projects that focus on profit will always be in React/JS land for this exact reason.

Rule 3: Tackle the right problem first

When you set out to build a new product, you’ll find tons of problems you want to solve. How you prioritize these problems will determine if your project succeeds or if you burn out and don’t ship a V1.

How to pick the right problem/scope?

There’s plenty of good thoughts on this already:

• ​The Lean Startup​
• ​Simple Loveable Complete​
• Courtland Allen’s “Business idea” framework​

On my new project, I’m not 100% certain I have this right yet, but only time will tell.

Notable links

​Michele Hansen’s new book, Deploy Empathy, is out and everyone who builds should read it. Her conversation on the IndieHackers podcast is a great primer.

​Developer DAO is a community created by Nader Dabit. While I haven’t dug into the NFT space much, I am a big fan of Nader’s. I purchased a token to gain access to the private community.Is it just a text file? Yes. But I’m hoping it ends up to be more than that with time :)

​

Up next

In the next newsletter issue, I’ll share what I’m building, who it’s for, and why I think it needs to exist.

See you on the other side,

Drew