SaaS vs Open Source in the Age of AI Coding

Introduction

I wanted a webhook testing tool. Found people selling it as a service and thought: why pay for this? I can build it.

So I built it. Took me a few hours with AI assistance. And that's when the question hit me: if I can spin this up in an afternoon, why would anyone pay a monthly subscription for it?

More to the point, why would anyone build it as a SaaS in 2026?

This is the reality of software in 2026. The code part has been commoditised. A competent developer with AI assistance can rebuild 40% of most SaaS MVPs in a few weeks. So if you're a software engineer thinking about what to build (whether that's to grow your career, establish a profile, or generate side income), you need to reconsider the question before you start writing a line of code.

The question used to be "can I build this?" Now it's "should I build this, and in what form?"

The AI 40% Test

Before deciding whether to go the SaaS route or contribute to open source, run this test: could a competent developer use AI to recreate 40% or more of your core features in under two weeks?

If yes, you're building a commodity. The code itself isn't the moat.

This rules out most general-purpose tools: link shorteners, webhook testers, basic API wrappers, simple CMS dashboards. These were reasonable SaaS businesses in 2019. In 2026, they're projects, not businesses. Someone will spin up a clone next month, and someone else will open-source it the month after.

The tools that still work as SaaS are the ones where the code is almost incidental. The moat is the domain knowledge, the workflow integrations, the compliance certifications, the customer relationships. "Time Tracker for Law Firm Billing" isn't a commodity even if you could clone the code in a week, because the value isn't the time tracker. It's the billable hour compliance rules, the integration with legal practice software, the trust of firms who've used it for three years.

When Open Source Wins

If you're building a horizontal developer tool (one that any developer could use, regardless of industry), open source is usually the right choice.

The benefit you get from releasing it as SaaS is marginal. The benefit you get from releasing it as open source is substantial.

When you open source something well built, you demonstrate something AI can't fake: architectural judgement. Anyone can prompt Claude to write code. Not everyone can design a system that other engineers trust enough to run in production, contribute to, and depend on.

There's also a trust angle. If your tool touches sensitive user data and you want developers to use it, open source removes a significant barrier. They can read the code and verify it doesn't do anything surprising. SaaS asks for blind trust. Open source doesn't.

And there's a practical one: open source lets you focus entirely on the product. Running a SaaS means dealing with payments, refunds, billing disputes, domain renewals, hosting costs, logging, alerting, monitoring, and customer support. None of that is building the thing. With open source you ship the code and you're done. The people who run it handle the infrastructure. You get to spend your time on the part that's actually interesting.

What Open Source Does for Your Career

If AI can write the code, the question employers and clients are now asking is: what can you do that AI can't?

The signals that mattered five years ago (can you ship working code, do you know the standard patterns, can you pick up a new framework) are table stakes now. Anyone with a decent prompt can produce that. What still requires a human is judgement: knowing what to build, how to structure it for the long term, what to leave out, when to say no to a feature request.

Open source is one of the clearest ways to demonstrate that judgement publicly. Not the volume of repos you have, but the quality of one or two well-maintained ones. Employers and clients can read the commit history. They can see whether you write coherent documentation, whether you handle issues thoughtfully, whether the architecture makes sense. A well-run open source project shows system design thinking in a way a portfolio website never can.

As software engineering shifts toward judgement over implementation, a strong GitHub profile carries more weight than it used to. The specific things worth demonstrating:

• System design over implementation. Show that you made deliberate architectural choices, not just that you made it work.
• Documentation. Writing clear docs is genuinely hard and most developers avoid it. A well-documented project stands out immediately.
• Code review quality. How you respond to pull requests and issues shows how you think about quality and collaboration.
• Maintenance over time. Shipping is easy. Keeping something stable, secure, and relevant over 12 months is not.

AI actually makes this easier to demonstrate. You can build something substantial faster, which means the design decisions, the trade-offs, the ongoing stewardship take up more of your time, not less.

The Hidden Cost Nobody Talks About

When developers think about building SaaS, they picture the product. They don't picture everything underneath it.

The code is the bit above the waterline. Below it: payment processing edge cases, billing disputes, transactional email deliverability, 24/7 uptime monitoring, customer support queues, security reviews, GDPR compliance documentation, and the slow accumulation of technical debt from shipping fast to keep customers happy.

These are real responsibilities, and they compound. Each customer you add is another expectation of reliability. Each outage is a support thread. Each feature request is a product decision. You're not just building software any more. You're running a service business that happens to involve software.

Open source sidesteps most of this. Your responsibilities shift from operational to reputational. If someone files a good pull request, you review it. If someone opens a well-reasoned issue, you engage. You still have obligations, but the nature of them is different.

When SaaS Still Makes Sense

SaaS isn't dead. It's just moved upmarket.

If you're building for a specific vertical with genuine domain complexity, the code is only part of what you're selling. You're selling the promise of a result: "We'll handle your webhook logging so you don't have to." You're also selling convenience, support, reliability guarantees, and the peace of mind of not having to maintain yet another self-hosted tool.

The convenience argument is underrated. Non-technical users or busy engineering teams don't want to clone a repo, configure environment variables, set up a database, and maintain a deployment. They'll pay £25 a month to not deal with that. Time is the scarcest thing in most teams.

SaaS also wins when switching costs are real. If your tool integrates deeply into a company's existing workflows, their data, their team habits, and their other software, the "just clone the open source version" option is rarely exercised. The friction is too high. That's not a cynical observation. It's why most enterprise software sales are driven by integration and workflow fit, not raw feature sets.

The Decision You're Actually Making

When you choose SaaS or open source, you're not really choosing a business model. You're choosing what to optimise for.

Open source builds credibility and reach. You build something useful, put it out in the world, and let it accumulate stars, issues, forks, and contributors. Done well, this does more for your engineering reputation than a portfolio website ever could.

SaaS is about outcome ownership. You're building something with a price tag, a renewal, a P&L. There's more operational overhead, but there's also direct financial return if it works.

My Take

If I were starting fresh in 2026, I'd lean toward open source for anything horizontal and technical, and only pursue SaaS if I had genuine vertical expertise or domain knowledge to sell alongside the code.

The reason is straightforward. AI has lowered the cost of writing code, but it hasn't lowered the cost of maintaining trust, building integrations, or navigating domain complexity. Open source demonstrates the first kind of value. Vertical SaaS captures the second.

If you're primarily a software engineer looking to grow your profile and credibility, open source is probably the move. If you're prepared to become a business operator who happens to write code, SaaS in a specialised niche still has legs.

The mistake is building a generic SaaS in 2026 and expecting the code to carry it. It won't.