Side Income Ideas That Actually Work for Engineers

Not dropshipping. Not crypto. Not another generic SaaS tutorial.

Every time I see “side income ideas for developers” content, it’s the same list. Build a SaaS. Sell a course. Start dropshipping. I tried none of that. Instead, I’m going to share the three paths that actually worked for me, from a side project that grew into a seven-figure company, to consulting that evolved into products, to a newsletter that opened doors I didn’t expect.

None of it came from following trends. It came from solving problems I could already see.

Here’s the thing: engineers have an advantage most people don’t. You build things. You see how systems break. You understand which problems are worth solving. Your day job isn’t just a paycheck. It’s a research lab for your next income stream.

It Doesn’t Have to Be a Leap

Most engineers I talk to think starting something on the side means eventually going all-in. Quitting the job, the whole founder arc. That thought alone is enough to kill the idea before it starts.

But that’s not how it worked for me. The real path looks more like this: you notice a problem, you build something small, it starts generating value, and then you decide how far to take it. Side project becomes side income. Side income becomes a side company. And if you want, the side company becomes the main thing. It’s not a cliff. It’s a drift. You choose where you stop.

Path 1: The Side Project That Becomes a Company

While I was still at Criteo, a colleague and I kept noticing the same gap in how educators, teachers, and coaches operate their education business. Teachers and students needed better tools, and nobody was building them well. We weren’t planning to start a company. We just started building something that solved it.

That became TinyWhale, an edtech platform. It started small, stayed small for a while, then grew into a real company with a seven-figure annual run rate. Eventually it was acquired. The whole thing began as two people solving a problem they understood because they were close enough to see it.

You don’t need to build an edtech company. But if you work in fintech, you probably see broken onboarding flows every day. If you’re in logistics, you know which manual processes are begging to be automated. The product idea isn’t somewhere out there. It’s in the Slack channel where your team keeps complaining about the same thing.

The pattern: domain knowledge + builder skills + someone from your network who sees the same problem. Most engineers already have all three. They’re just not looking at their day job as the source.

Path 2: Sell Your Expertise Before You Build Anything

FusionOne started as consulting. Technical strategy and cloud architecture for startups. No product, no platform, just me advising founders on decisions I’d already made dozens of times in my career. Straightforward. Bill for your expertise.

This is the most underrated path for engineers. You’ve spent years solving hard problems. Startups and smaller companies face those exact same problems right now, and they’ll pay someone who’s already been through it. Freelance technical audits, architecture reviews, migration planning, system design advisory. These aren’t hypothetical. Companies need them today.

The beauty of consulting is you start earning immediately. No product to build, no users to acquire. Just your experience, packaged as advice. Start with one client from your network. See where it goes.

For me, it evolved further. I started building products from the problems I’d seen firsthand. But that was a natural evolution, not the plan from day one.

The pattern: every job you take deepens the expertise that someone else will pay for. Consulting is the fastest path from engineer to side income, because you’re monetizing what you already know.

Path 3: Content and Audience

This one surprised me. MacroStack started as a way to share what I was learning, not as a business. But building an audience and writing consistently compounds. It opens doors to partnerships, mentorship, and credibility that feeds everything else.

You don’t need to be famous. You just need to be useful to a specific group of people. Engineers writing for engineers is one of the highest-trust content relationships out there.

This doesn’t have to be a newsletter. A niche technical blog, a YouTube channel walking through real architecture decisions, a paid community around a specific domain. The format matters less than the specificity. “DevOps tips” is noise. “Kubernetes cost optimization for mid-size SaaS companies” is a business.

The AI Multiplier

Here’s what changed everything: AI collapsed the barrier between “I have an idea” and “I have a product.” What used to require a team of three to five people, I now build alone in days. You don’t need to hire anyone to test an idea anymore. You just need a weekend and the right tools.

What Doesn’t Work

Building a SaaS with no domain knowledge. You’ll build something nobody wants. Dropshipping, crypto trading, anything that doesn’t leverage the fact that you’re an engineer. If you’re competing with non-engineers on a non-engineering idea, you’ve already lost your biggest advantage.

The generic advice is generic for a reason. It works for everyone a little. It works for no one a lot.

The Question

Every engineer I know complains about something at work. A broken process. A manual task that should be automated. A workflow that wastes hours every week.

That’s not a complaint. That’s a business.

What pain do you see every day that nobody’s solving?

If this resonated, I write about engineering, leverage, and building beyond code every week at MacroStack. Subscribe if you want more like this.