I’ve published a weekly newsletter every Monday for the past 4 years that showcases content from the tech community. The sole purpose of all 221 issues has been to highlight creators who educate the community and teach you a thing or two every week.

Writing it for so long has tuned me into creators, content styles, trends, and outputs of the greater tech community. And lately it feels like thoughtful technical writing has become harder to find.

Which is odd, I haven’t seen this kind of behavior from the community before. But it hit me the other day as I was scrolling through LinkedIn. Everyone is launching solo-SaaS products. Hyper-specialized web apps built to solve a niche problem, now wrapped in pricing pages and marketed as a service.

Developers are spending their time launching these micro-SaaS apps instead of writing about what they learn. We’re seeing Product Hunt launches and marketing pages with colorful gradients where the blog posts used to be.

What happened?

AI. AI happened.

Specifically coding agents removed barriers preventing us from launching products in our free time. The time it would have taken to research, build, tinker, polish, rebuild, and polish some more has been replaced with a plain-text “Make it do this” and walking away from our laptops (or cell phones 🤯).

Don’t get me wrong, I love how easy coding with AI agents is. But all-too-often I’m seeing developers be too trusting and building something they don’t truly understand and moving on before lessons are absorbed.

It’s all very cool and I still have a hard time believing this is real life. I’ve had times where I’m on my phone using a website I built, notice something I don’t like, open the Claude app and describe the change I want, and 5 minutes later merge the PR from the GitHub app and it’s live.

But it’s having a ripple effect that might be hurting the tech community more than we realize.

Building like a SaaS isn’t the same as running one

Throughout my career, I’ve been tempted to turn one of my projects into a fully-functioning SaaS. Every time I start down that path, I am quickly reminded that I romanticize running my own business.

Building like you’re shipping a SaaS is one of the best things you can do for your career. Multi-tenancy as a design principle teaches you data isolation, auth, data modeling, and observability. All skills you need at your day job. You should absolutely build that way (please do!).

Taking it to production is a whole different ballgame. You need a business strategy, marketing, pricing, support SLAs, and about 40 other things that aren’t engineering related. The stuff that we as developers conveniently forget when we tell ourselves “All I need is 100 users at $50 a month and I’m set.” The stuff that takes ongoing commitment. Even on days you don’t feel like supporting it, somebody else is depending on it.

My friend Elias Brange is a fantastic engineer. The kind of dev who builds with care and intentionality. He launched a game called Daily Wars on Product Hunt last week and posted this after:

Getting the code out the door was easy, thanks to AI. Getting someone to use it was the hard part.

The moment you decide others will use your game/site/service/thing, the design changes too. You can’t hardcode your preferences. You add configuration pages, customizable timers, a place to dynamically store credentials. That 10/10 solution for your problem becomes maybe an 8/10 for everyone because it has to “just work” for use cases that aren’t yours.

Then (maybe) users start showing up. Ten of them. Heck, let’s say fifteen. They have questions you didn’t anticipate. One of them gets locked out at 2 AM on a Sunday and emails you about it. Someone else hammers your API with thousands of requests per second because of a bug in their code while integrating. You’re checking your dashboard between meetings at your day job.

And just like that your fun side project goes from a hobby to a job you didn’t apply for.

Remember Saturday mornings spent tinkering, trying to figure out how to center a div without asking AI? Those days are gone.

Build for yourself

Instead of trying to launch your first, second, or Nth micro-SaaS, why don’t you build for yourself? Make it something that serves an audience of one (you) but build it in a way where you still get meaningful practice in software engineering.

Open source the code. Keeping it open allows for a level of transparency that a fast-shipped SaaS app doesn’t have. You’re not signing up to maintain a project forever or triage issues from strangers. Treat it as a type of receipt. “Here’s where the lesson came from. Clone it if you want, but I’m not your support engineer 😅.”

Then write about what you learned. Honestly, this is the part you learn from the most. Writing a blog post or creating a video that teaches something you learned the hard way forces you to really understand what you encountered. And the best part? It costs nothing to maintain. It doesn’t page you on a Sunday morning. And it lands you back in the seat you used to sit in, as a peer in the community instead of a vendor pitching to one.

Not everything needs to make you money

As a millennial, I grew up under the “monetize your passion” life advice and it’s a conscious effort to not do it. It’s terrible advice. I remember the first time I heard the phrase not everything you do needs to make you money and felt like a huge weight was lifted off my shoulders. Doing something for fun instead of doing it to earn beer money is liberating. With AI agents making the coding part of SaaS building trivial, it’s harder than ever to simply build for the fun of it.

I suggest a new mantra for developers for 2026: not everything you build needs users.

The engineering you do for yourself still counts for something. The system you architect well still goes a long way. The hobby that produces nothing more than a blog post and an excited conversation is doing more for the community than the micro-SaaS that produces revenue from twelve strangers.

The next time you finish a side project, write the post before you write the pricing page. You might find that it was the output you were after all along.

Happy coding!