Retrospective

Quick Stats

• Time spent: 343 hours
• Money spent: $300 (rough estimation)
• Revenue: $0

Quick Summary

• got better at design, marketing, writing, and tech stack
• got better at prioritizing and making product decisions
• learned how to track product metrics and employ a data driven approach

Takeaways:

• don't build anything that doesn't have users from day one
• ask for money early
• payments are the only true validation
• make data driven decisions
• fail or pivot faster
• be brutally realistic about time and scope

The Good

To start, let's celebrate the good.

I learned a lot, had fun, and spent time productively.

I learned marketable skills which will help me in future projects and in my software engineering career.

I'll reap the benefits for years to come, and consider the project to be a net success.

Marketing

I gained some experience with various marketing tools and got a general idea on how to generate some traffic.

Reddit has proven to be an amazing source of traffic, but marketing on Reddit requires you to be clever. The paid ads don't do very well, and posting ads in communities will get you banned quickly. You need to be genuinely helpful and/or mask your ads so they look like organic content.

My blog has also been a decent source of traffic. I didn't invest any time into it during the project, but I did put a lot of effort in years ago. It yielded results, but whether it's worth investing time into it probably depends on the project.

There is so much more to learn, especially in regards to actually converting the traffic into sales, but I feel like I got a good taste of what tools are available and how to use them.

Design

I got better at designing apps.

Before Code Interactive, I had no idea how to make anything look remotely decent. I had never built a fully featured landing page. Now, I feel like I can put together a presentable website, using tools familiar to me.

I'm still working on my design skills, developing taste and a personal style, and have invested some time into it lately. Building Code Interactive has definitely been the spark that I needed to start.

Tech Stack

I got comfortable with Go, which is a big plus as I recently switched to it for my new job.

I figured out how to set up my own infrastructure and mostly automated it with hatch. I control it, understand it, and have no fear of surprise bills and rate limits.

I got more comfortable with the frontend. I moved away from NextJS to a simpler setup (plain React and Astro for landing/marketing) that I understand and can work with. I'm still learning, but I feel much more comfortable.

Linux

I learned a lot about Linux.

Experimenting with Firecracker, working extensively with Docker, and building my own orchestrator meant that I spent most of my time in either WSL or docker containers.

This, in the end, pushed me to switch to Linux completely. It has been one of the biggest productivity boosts for me and has reignited the joy of working with computers that I had as a kid.

Journaling

As a way to stay motivated and on top of things, I started journaling.

After a few months, I realized how powerful this was, and decided to share it publicly. It has been a great way of keeping myself accountable and sharing my process.

I ended up building devjourney.io for it, as it was outgrowing my personal website.

I've also started journaling at my day job because of it, and it has been a game changer for me.

The Bad

I made a lot of mistakes. Not all of it was in vain though, as I've learned a lot and came out of the project with rich experience and some actionable takeaways.

I'll go through the main ones.

I Lost the Founder-Product Fit

This, I feel, is the biggest one: I lost the founder-product fit.

When I decided I wanted to build Code Interactive, I was a decently experienced .NET developer. I had been blogging for some time, my following was growing exponentially and I was getting 10k+ monthly views on my blog. I knew the domain, I had an audience, and I loved it. At that time, and even more so now, boot.dev was growing rapidly, and I wanted to build something like that, but for .NET. The project ticked all the boxes and made sense at the time.

Fast forward fall 2024 - suddenly I'm no longer writing .NET. at work or at home. I'm no longer thinking about design patterns, libraries and nicely packaged utilities. I'm all up in Linux, Go, infrastructure and observability.

I decided to stick it out, partly due to sunk cost fallacy, but also due to a desire to finish something and gain experience past the tinkering and MVP phase. It was also kind of useful, as I was still writing infrastructure code at the time and was learning actual skills that I ended up using at my day job.

As soon as the infrastructure was good enough and it was time to focus on content - I hit a wall.

Somewhere in April 2025 I estimated that I would have to put in at least 200-300 more hours of writing .NET content - something that just didn't make sense to do. It wasn't improving my marketable skills and it wasn't fun.

This, added with constant battle against bad actors and alerts, eventually pushed me to shut the project down.

In the future, before starting any project, I will ask: Do I see myself working on this 2 years from now? If the answer is no, this is not a project for me.

Poor Validation / Product Market Fit

Now this is the one that's hard for me to gauge. There was definitely some demand, and my stats show that. People messaged me and signed up for updates. But most of these dropped because there simply wasn't enough content.

There's a competing, validated product really similar to mine. The only difference is the content niche.

I probably shouldn't have gone with a new niche for my first real product. A copy of an existing product with a big market would've been a better choice, as it would've eliminated the risk of validation and product market fit, and helped me learn the ropes and make my first sale.

Also, I never asked for money, so I never validated if the product is actually needed - I just validated that there's some interest.

Whenever I shared the project in niche communities of my target audience I got lukewarm responses or none at all. If I had a product-market fit, users would be swarming me. This should've been my main cue.

Finding product-market fit is the hardest thing for me at this stage, but also for many other founders. It is a foundational skill, and something I will have to put more focus on.

In the future, I will do actual validation. I will ask for money as soon as possible, and not spend too much time on things users don't actually want. I will not build anything that doesn't have at least 1 user from day 1. Building for myself, or building alternatives of existing products helps, but there is no validation without payment.

Poor Feedback Loops

To keep a momentum going, I have found, requires good feedback loops - I create something, make a change, I get feedback. Actionable feedback.

My courses were far from finished, and the users didn't stick for too long, so I wasn't getting a lot of feedback. My idea that users will willingly leave feedback did not result in much - the feedback was mostly bot spam.

In the future, I will focus on getting a few users that I will maintain a relationship with and ask for feedback frequently. Ideally, I would use the product myself from day one.

Failed Focus

I focused too much on what I thought was interesting, instead of what users actually wanted to do. My first course, Testing in .NET, ended up being among the least favorite courses clicked on the website.

I eventually decided to take a data driven approach and actually track which courses are favorites, which helped me focus, but by that time I had wasted a lot of time and effort for basically nothing.

This is probably the most valuable lesson I've learned.

In the future, I will take a data driven approach with everything I do. I will make experiments, test my assumptions and fail or succeed as soon as possible.

Unrealistic expectations

I need to be more realistic with what I can achieve.

Everything I imagined to do with Code Interactive was possible and I would've achieved it given more time. But that's the catch - I don't have more time.

I have about 10 hours a week, sometimes less, so I need to plan accordingly.

I can either:

• get more resources (time, money)
• cut quality
• cut scope

Resources are out of the question at this point in my life.

Quality can be cut in some ways, but in the end, the most realistic approach is:

• reducing the scope drastically
• doing what's left really well

Conclusion

I tried, I failed, I learned.

I'm looking forward to my next project, Barelytics, which will probably fail too. That's fine, because every failure gets me closer to success - however far away that may be.