Rebuilding the SaaS you hate just got cheap

Somewhere in your stack is a tool you would drop tomorrow. The vendor ships features nobody asked for and moves the billing to match, so the bill grows and what you get for it doesn’t. Leaving was never really on the table, because everyone has learned the thing and it’s wired into how the company works. Until recently the answer was to pay and grumble, because building a replacement was a project your team had no room for. Now an agent will give you a working version of the parts you actually use. Working out what a closed tool does is a token bill rather than a research project.

So the question stops being “can we” and becomes “should we”. The cost doesn’t disappear when you stop paying the invoice. It changes shape. The subscription line goes away. In its place you get hosting, a CVE feed, and a dependency bot somebody has to read. You also get training for everyone who knew the old tool, and a pager that now rings for you.

We don’t agree on where that line sits. Mattias would rebuild the tools from vendors who abuse their position, and thinks a normal team can now own the software behind what its company is good at. Andrey would build what makes money and buy the rest. Where we land matters less than which costs each of us is counting, and most build-versus-buy arguments go in circles because the two sides are counting different ones.

The first 80 percent is the easy part

Start with the thing that looks cheapest, which is the code.

How much of a SaaS product can you actually rebuild?

Most of it, and probably not the part that makes it good. You might reach something like 70 or 80 percent of what the tool needs to be useful, and the remaining work can be the hard part.

Then the tool exists, and the second bill starts. You’re self-hosting. You’re reading advisories for every library you pulled in. You’re the one who sees the alert about a known vulnerability, and the one who decides whether the upgrade breaks something.

The speed is real, though. We’ve seen a team replace a big platform inside a month or two. Two things have to be in place for that to be an option: people who can build it, and people who will keep building it after launch. Not every engineering team has that bench, and “the agent wrote it” doesn’t answer who owns it in month three.

Your own tool makes hiring and training your problem

The bench problem doesn’t stay inside the engineering team either.

What does a homegrown stack cost you in people?

Training, for every hire. Tools and workflows that exist only inside your company are ones each new recruit has to be taught. Hire someone who already knows Jira and your Git hosting, and a chunk of their onboarding happened before they arrived. Bring that same person into a homegrown stack and that part of onboarding is yours to run. Skills that transfer are worth money to the person who holds them. A candidate can tell from your job description whether a year with you leaves them more employable or less.

We disagree about how much weight that deserves. Mattias says that if your skill set is “I know Jira and I can’t use any other ticket system”, you should upgrade your skills. Paulina challenges the assumption that people adapt readily, and puts technical staff inside that challenge rather than outside it. Plenty of people on the operations side have settled into one particular way of doing one particular thing. A new release of the same system that moves something slightly is a genuine interruption. Outside engineering it’s sharper. People in accounting, insurance and administrative roles keep their own notes, with screenshots of which button comes next. Swap their tool wholesale and you’ve signed up for hand-holding that never appeared in the business case.

Build what you sell, buy what holds it up

None of that argues for buying everything. It argues for being precise about what you own.

Which software is worth owning outright?

The software your customers judge you on. Take a hypothetical car rental firm whose pitch is that its service desk beats the competition. If a rival can buy the same support suite off the same shelf, the thing the firm claims to be best at runs on software anyone can rent. That software is shaped to the vendor’s flow rather than the firm’s own. Build that layer yourself and the claim becomes testable. Mattias wants this for a selfish reason too, as a customer who’d like better service.

Here’s where we split. Andrey draws the line at the core: if it’s how you make money, build it, and rely on managed services underneath. The supporting products that revolve around the core stay bought. What’s the point of rebuilding Slack, or Git hosting, or your auth provider?

Mattias puts the line somewhere else. If support is your job, then the support stack is your core, and you should own it end to end rather than adapt to whatever the vendor shipped. We didn’t reach a common denominator on air and we won’t here. In a couple of years we’ll know which of us was counting the right costs.

Day two doesn’t disappear because AWS runs the box

The split matters most on the part nobody budgets for.

What does day two look like once the tool is yours?

It looks like the work the vendor was doing, moved onto your calendar. Hosting isn’t the hard part of that, and this is the strongest version of the rebuild case. Put the service on AWS or Firebase and keep the source on GitHub. Let an agent handle version bumps, and let Dependabot raise the security pull requests. The boxes, the database and the network were always going to be someone’s problem. You’ve cut out a vendor, not added a data centre.

The gap opens after the alert. Dependabot security updates try to open a pull request for every open alert that has an available patch. How far that reaches into your dependency tree depends on the ecosystem. For npm, Dependabot updates the explicitly defined dependency, which can mean moving the parent to reach a secure sub-dependency. For NuGet projects on PackageReference, it tries the parent first and otherwise adds a direct reference pinning the transitive package. For other ecosystems, and NuGet projects on packages.config, GitHub is blunt: Dependabot “can’t update an indirect or transitive dependency if doing so would also require updating the parent dependency.” And where the upgrade would disrupt the dependency graph, it reports an error on the alert instead of raising anything. Someone then has to read that error, decide, test the upgrade and ship it.

That’s the trade in one line. You can do all of it. While you’re doing it, you aren’t doing the work that pays for the company.

Vendor growth can make useful tools harder to use

That isn’t an argument that today’s vendors are safe.

Why do good tools turn into tools you want to replace?

Because commercial growth asks for features, and features rarely come back out. A tool arrives doing one thing very well. It gains users and takes a slice of the market. Then it starts listening to everyone. Over a few years the tool that did one thing well becomes a tool that does many things adequately, cramped with options nobody asked for. A newcomer shows up, rethinks the problem and takes the slice. That cycle is older than AI. What’s changed is how quickly the newcomer can appear, and that the newcomer might be your own team.

Software escapes the treadmill when it’s allowed to be finished. The Unix utilities are the usual illustration: ls and grep do roughly what they did decades ago, take bug fixes, and nobody has to monetise them this quarter. People still write replacements, eza for ls and ripgrep for grep, so the newcomer half of the cycle runs there too. What’s missing is the other half, the pressure to keep extracting revenue from the same product, and that pressure is what turns a good tool into a bloated one.

Adobe is the example we keep returning to, and it’s worth being fair about why. The products are good and people depend on them. The grievance is the position: a tool everyone needed, priced accordingly. Then the 2013 breach, which Krebs on Security reported hit at least 38 million users, Adobe IDs and encrypted passwords included. More than a decade later one of us still gets spam calls and mail, and suspects that leak is where the address came from, though nothing proves the link. Meanwhile the PDF work has drop-in replacements: we moved to PDFgear, no nonsense, and it has handled the job well. The lesson for anyone selling software is cheap to say and apparently hard to follow. Be friendly with your users. Don’t be rude to them.

What self-hosting a podcast actually costs

Fair question at this point: have we done this ourselves? Yes, with this show.

What does a podcast host actually do for you?

It serves one XML file and some audio, and sells you the convenience of ignoring both. Podcasting still works the way RSS did when people read blogs in Google Reader, which Google retired on 1 July 2013. You publish a feed at a URL, and each episode is an item in it with a title, a description and an <enclosure> pointing at the audio. Apple’s content requirements are worth reading first. Each episode needs an <enclosure> with a URL, a length and a type, plus a <guid> that stays fixed. Change that <guid> later and old episodes can resurface as new.

Our site runs on Hugo, so the feed is another output format in the same build. Generate the site, generate the feed, upload the audio, and the platforms pull it. The audio sits in Cloudflare R2. The free tier covers 10 GB-month of standard storage, 1 million Class A and 10 million Class B requests a month, and egress is free. An analytics prefix around the audio URL counts the downloads. OP3 is open source, needs no signup and stores no raw listener IP addresses. The platforms report their own numbers anyway.

So what is the hosting fee buying? One dashboard instead of three, and access to an ad network. The ad network is the real product, and we don’t sell ads, so for us it’s a convenience charge. There’s a second reason, nothing to do with money: if your audience only reaches you through a platform, that platform owns the relationship and can end it. We aren’t clean on that ourselves. The feed address we publish is still a Podbean one, and Podbean’s guidance for leaving is to set a 301 redirect to your new feed in its feed settings. The subscription is paid through May, everything needed to serve the feed ourselves already runs, and come May the platforms get pointed at our own feed. Whoever owns the address you publish has a hand in your exit.

That’s the rule applied honestly. The publishing scripts were built up over years, and AI made them faster to extend rather than free to own. We record, and then on publishing day there are tweaks and improvements: an hour or two, no more. A side project that quietly picks up a second job has stopped paying for itself.

AI multiplies the practices you already have

Underneath the whole argument sits an assumption worth testing: that an agent can carry a team that couldn’t do the work before.

Will an agent make a sloppy team faster?

It’ll make them sloppy faster. AI is a lever, and a lever needs something solid to push against. Where delivery practices are already in place, with CI running, tests that mean something and releases planned rather than improvised, agents accelerate that. Where they aren’t, you get more of what you already have, because the model copies the patterns it finds in your repository.

We’re back to the basics. That was the main thing we took away from talking to people at the Applied AI Conference in Saint Paul on 2 November, eight tracks and mostly leadership-oriented. It’s the same conversation the industry was having 15 years ago about agile and about CI/CD. Those changes also depended on sound processes and people who understood them. If your platform team is the bottleneck today, agents make the queue longer rather than the neck wider. Those fundamentals get established by people thinking about what they’re doing, and switching on an agent doesn’t skip that step.

Conferences are worth more to us now than they were a few years ago, which is its own signal. As the platforms fill up with agents, a room full of people gets more valuable, not less.

Where this is heading next

One recent release shows the same argument running a level up, against the suites almost nobody rebuilds. Anthropic launched Claude Whiteboards and Claude Sheets in beta on 10 November, on all paid plans. Claude Meetings started rolling out in beta to Team and Enterprise plans two days later. That’s Google Workspace and Microsoft 365 territory, entered from the AI side rather than the office-suite side. Moving an organisation off those suites is still slow work, because the directory and the integrations wired into it hold everything in place. Which is the point we keep landing on: what locks you in is rarely the feature list, it’s everything attached to the tool.

What this means for teams

The rebuild question isn’t ideological. It’s an allocation question, and attention only spends once. Right now there’s more you could build than you have weeks to build it in, so the discipline is choosing. Price the thing properly before the enthusiasm sets the schedule.

Four things worth doing this week:

• Take the SaaS tool your team complains about most. Write down what you’d owe after replacing it: hosting, patching, onboarding, and the name of the person who carries the pager. Compare that to the invoice, not to zero.
• Separate your core from your supporting cast on one page. If owning your version would show up in what the business earns, it’s defensible. If you can’t point at that contribution, weigh the rebuild against the maintenance you’d be signing for.
• Open your Dependabot alerts and read the ones with errors or no available patch. That’s one slice of the day-two backlog rather than the whole of it. Put an hour estimate against a few and see what the monthly number actually looks like.
• Set a maintenance budget before you start, and say the number out loud. Ours for the podcast publishing scripts is an hour or two on publishing day. Yours will be different, and a number you picked deliberately is what tells you when the project has taken a job you didn’t apply for.

Common questions, answered

How much does it cost to self-host a podcast instead of paying a host?

The infrastructure can be cheap, but your time is the larger line. Cloudflare R2’s free tier covers 10 GB-month of standard storage, 1 million Class A and 10 million Class B requests a month, and egress is free. The feed is an XML file your site build can generate. Apple wants a unique <enclosure> per episode and a <guid> that stays fixed, or old episodes can resurface as new ones. Budget the maintenance separately, as its own recurring hours.

Does Dependabot cover patching if we build our own internal tool?

Partly. It opens a pull request for alerts that have an available patch, and how deep into your dependency tree that reaches depends on the package ecosystem. Where the upgrade would disrupt the dependency graph, you get an error on the alert instead of a pull request. Reading that error, deciding what to do and testing the upgrade stays with your team for as long as the tool is in use.

How do we avoid getting locked into a SaaS vendor?

Check who owns the address your audience and your data arrive at, before you sign rather than after. For a podcast that address is the feed URL, and a feed published on your host’s domain means the move runs through that host’s redirect. Your own domain in front of anything a customer bookmarks keeps the move in your hands. None of this makes a migration effortless, but it decides who sets the terms of one.

Related episodes

• Episode 114, Fridge Hacks and Security by Obscurity is where the AI-assisted reverse engineering thread started, and why closed tools are less closed than they were.
• Episode 116, Hot Fridges, sshole and New Container Defenses is the heavier counterpart to this one, on container hardening and rebuilds as routine.
• Episode 104, When AI Coding Gets 10x More Expensive covers the billing change that puts a tool on the replacement list in the first place.
• Episode 107, Continuous Integration in 2026: What Still Matters is the detail behind having your house in order before you add agents.
• Episode 112, DevOps Careers: What Should You Learn Now? takes up the transferable-skills question from the engineer’s side rather than the employer’s.

Resources

• Apple Podcasts content requirements: what a self-hosted feed has to carry, including the enclosure and GUID rules that break old episodes when you get them wrong.
• Cloudflare R2 pricing: settles the 10 GB-month free tier, the operation allowances and the absence of egress fees.
• OP3, the Open Podcast Prefix Project: open-source download analytics via a URL prefix, with no signup and no stored raw IP addresses.
• Hugo output formats: how the RSS feed gets generated in the same build as the site.
• GitHub docs on Dependabot security updates: what it does with an indirect dependency in npm, in NuGet PackageReference projects and in everything else, and what happens when the upgrade would disrupt the dependency graph.
• Krebs on Security, Adobe breach impacted at least 38 million users: the figure Adobe gave for active users whose Adobe IDs and encrypted passwords the attackers took.
• Powering down Google Reader: Google’s own announcement, which fixes the shutdown date at 1 July 2013.