← Writings

From Idea to Launch (Part 1)

Over the years, I've built more than seven products by myself. Some worked better than expected, some failed completely, and some taught me lessons that changed how I approach software today.

When people see a finished product, it's easy to assume the hard part was writing the code. I used to think the same thing. After building products like Prioritize, Fast Resume, CookPaddy, Okepoint, Snapbum, and Finewine, I've realized that code is only a small part of the journey. Most of the important decisions happen long before I open my editor.

Today, when I get a new idea, I don't start building immediately. In fact, the first thing I do is write it down.

I usually create a sticky note or a quick memo explaining the idea to myself. The goal isn't to document every detail. I simply want to capture the problem, who might have it, and why I think it's worth exploring. Once I have that written down, I begin researching.

My research process is fairly simple. I visit SEMrush to look for keyword demand, then I check platforms like TikTok, Reddit, and Twitter to see if people are already discussing the problem. I'm not looking for compliments about the idea. I'm looking for evidence that people care enough about the problem to complain about it publicly.

This process has influenced several products I've built.

Okepoint came from a personal frustration. I wanted a better way to share my location with family during emergencies. Prioritize came from my own need for a task management system when I started college. I wanted something that could help me organize classes, assignments, and personal tasks in one place. Fast Resume started when I noticed friends struggling with job applications and resumes. The more I paid attention, the more I realized how many people were facing the same challenge.

A pattern started to emerge.

The best ideas were rarely the most creative ones. They were usually connected to a real problem that either I or someone around me was already experiencing.

That lesson became even clearer after some of my failures.

One of the biggest mistakes I've made was building products without properly understanding the market. Snapbum is probably the best example. I spent months building features and expanding the product, but I wasn't spending enough time understanding the people who would actually use it. At one point, I had added social media features, posts, comments, and reactions because I thought they would make the product better.

Looking back, I was building features I found interesting rather than features users actually needed.

I made a similar mistake with Finewine. I was building quickly and adding functionality, but eventually realized I was solving the wrong problem. The project became a perfect example of founder-driven development, where the founder's assumptions become more important than actual user needs.

Those experiences changed how I validate ideas.

Today, before I commit to building anything, I try to speak with real people. The conversations are usually informal. I talk to friends, family members, or anyone who might be affected by the problem. Instead of asking whether they like the idea, I ask how they currently solve the problem and what frustrations they face.

Sometimes these conversations completely change the direction of a product.

While working on Snapbum, I spoke with someone involved in the beauty pageant industry. She explained how the industry actually worked, what organizers cared about, and what challenges existed. That conversation immediately exposed several incorrect assumptions I had made. Had I spoken to her earlier, I could have saved months of unnecessary work.

Research doesn't stop with users.

One thing I do much more today than I did years ago is study competitors. Whenever I find a product idea worth exploring, I download competing apps, use their products, and take notes. I pay attention to how they onboard users, how they structure features, and what problems they appear to have solved already.

I don't do this to copy them.

I do it because many of these companies have spent years learning lessons that I haven't learned yet. Ignoring that knowledge simply means I'll repeat mistakes they've already solved.

Once I feel confident that a problem is worth solving, I move into planning.

My planning process usually starts with notes, paper sketches, and FigJam diagrams. I map user journeys, create flowcharts, think through the database structure, and define the core functionality of the product. After that, I create milestones and issues so I have a clear path forward.

One of the biggest changes in my process is that I now write PRDs for nearly every project. In the past, I would jump directly into development because I was excited about the idea. While that approach felt productive, it often led to scope creep, unnecessary features, and products that drifted away from their original purpose.

A PRD forces me to stay focused on what actually matters.

Before I decide whether an idea deserves my weekends and evenings, I ask myself a few questions. Does it solve a real problem? Is there evidence that people want it? Can a solo engineer realistically build and maintain it? Does it require complicated licenses, regulations, or approvals? Most importantly, do I care enough about the problem to spend months working on it?

If the answer is yes, then I move forward.

If not, I let the idea go.

The biggest lesson I've learned from building software alone is that ideas are rarely the difficult part. Execution is harder, but distribution is harder still. A great product with no users is still a failed product.

That's why I spend much more time researching, validating, and planning today than I did when I started. It might look slower from the outside, but I've found that a few days of thinking can save months of building the wrong thing.

In Part 2, I'll walk through what happens next: choosing the technology stack, building the MVP, using AI as part of my workflow, and taking a product from planning to launch.