AI is awesome - it can help people build things faster than ever before.
On the other hand, it’s also convincing some CTOs that they can build versions of their SaaS tools internally, saving money and avoiding the pesky problems that come with having to deal with anything outside of their fiefdom.
This is crazy.
Whether this approach is a power grab, hubris, or something else, it’s almost never a good idea. As a rule, you should only be replacing your SaaS products with internal tools if you’re FAANG-sized or if you can replace the tools with a spreadsheet.
Let’s talk about why.
The Bed Is Made
Meet CTO Bob. Bob is an AI believer. He saw someone use Replit to launch a full website in 4 hours.
He also has a terrible case of Not-Built-Here Syndrome.
He also doesn’t invest the time to properly integrate or use his SaaS tools and then regularly complains about them not working.
Nice to meet you Bob.
Well, Bob asked his team to cut costs and his engineers said it would take 18 months to implement something that might reduce their storage footprint.
Bob doesn’t want to wait 18 months. Bob wants to save money now. Bob wants to replace all of his SaaS tools with internal tools. Bob talked to his C level peers, and they said what they do with these tools, and he can totally find someone to replicate that with AI super fast.
How hard can it be? Half these SaaS tools are just glorified fucking forms!
It Begins
So Bob gets permission to rebuild a tool internally. He gets 2 engineers and a mountain of AI tools to start the project.
Right off the bat, Bob is dedicating about $400,000 of headcount to replace $200,000 of SaaS tooling. But let’s not confuse Bob with these details. The headcount is already budgeted for and he doesn’t think of it that way. It’ll pay off in the long run.
OK so we’re gonna get some engineers who are interested in focusing on greenfield development. But we can’t have our best engineers do this, because these are just lame tools. So Bob gets 2 mid engineers to build this project.
Alright well we need a database, we need hosting, we need authentication, we need some business logic. The AI tools probably help with all of that right?
Maybe, Bob, maybe.
Say you get through that, now you have to rebuild a mature piece of software from scratch.
Well, your team only does a few things with these tools, and only uses a few features, so let’s just build them.
OK, well we’ve built a shitty version of a CRM, done and dusted. And it only took about 6 months!
Uh oh Bob, it turns out there’s some bugs and some missing features. Just asking your internal partners to kind of vibe-check what they do wasn’t really great product management. More to be done!
Alright, 9 months in, v2 is done! Here you go suckers, money saved!
It Breaks
Dammit Bob, the thing just broke at 2am and our EU team relies on it! You need a 24/7 on-call for this tool. Well, this is awkward because we only have two people. Are they on 24/7 work every other week? Or do we ask another team to support the on-call. Ehh just get these 2 people to go on-call and we’ll figure it out later!
OK we have 24/7 on-call of two very nervous engineers who wonder when they’ll get more help, but we’re ready!
Bob, it broke again in the middle of the night and it turns out your 2 mid engineers couldn’t fix the Postgres issue that was happening. These AI tools helped us build something but they’re not expert debuggers! Gah!
OK, we have now declared that any long running incident on these tools has to bring in people from other teams. That won’t be a morale issue at all!
Ok we’re 12 months in but feeling good about this.
Fuck. Bob, one of the engineers just quit. They don’t like being on a non-core product team. This last performance round you told them that their problem space wasn’t complex enough to ever get to staff engineer because it was just a dumb SaaS tool that AI mostly built.
Hurry Bob, replace them with some other sucker!
OK, we’re 15 months in and hired a new person on our mini SaaS product team. The old SaaS product just released a great new feature and your internal users want it plus 5 other things that their product already has.
You told them it’s going to take 6 months. Fuck Bob! If we had the old tool we’d have it now. You said you’d have parity!
But wait, there’s more! The 200 engineers at the SaaS company also have AI tools. Turns out you don’t have a monopoly on talent and technology. They’re building super fast now! Bob! What! The! Fuck!
But wait, there’s more! That SaaS company is finding more efficiencies. They just cut their unit pricing. Our 2-person team has no idea how to leverage the new AWS server types to get these savings. Buying off the shelf would now be cheaper!
Bye Bye Bob
It turns out, underneath it all, spending $400k to replace a $200k tool didn’t make a lot of sense for the business. This was just a long line of problems that Bob had. Bob just got a new CTO job and his LinkedIn says he successfully replaced a bunch of SaaS products with internal tools.
What happens next is slow death.
Your internal product can’t keep up with the SaaS product.
Every new feature request takes months (when those tools already have them)
You continue to struggle to staff a B team. These are teams to nowhere. They’ll never justify a major investment and lots of promotions, but now they’re a critical part of your stack.
You continue to have major outages and annoy other teams that have to support that team.
You sow friction with other departments because you’re providing a bad product and it’s causing issues. Ouch!
The Lessons
It turns out that writing greenfield demos of simple business logic (something AI is good at) and doing full scale product development are two very different things.
It turns out that engineers and PMs cost a lot of money, even more than SaaS products.
It turns out that developing deep expertise in an area lets SaaS products build effectively and thoughtfully.
It turns out that having lots of customers lets SaaS products build for what you need and what you might need eventually - a product for multiple stages of maturity.
So listen, CTOs, if AI is so fucking great, use it to make your product so good that you have enough money to buy the best SaaS products out there. You wouldn’t try to replace your laptop with an in-house laptop built by AI tools. You wouldn’t rebuild your own IDE in house.
Stop trying to rebuild your SaaS products.
Epilogue 1: Don’t Cheap Out
A related thing that’s happening right now is people trying to save 40% on their SaaS bills by moving to cheaper, worse alternatives.
This is also pretty dumb.
Your CEO says every department has to save $100,000. So instead of reworking the usage of best-in-class tools to avoid overages, or firing Tim who is a long-standing low performer, you start a 12 month procurement cycle to get a cheaper version of a SaaS tool. After spending 1000 hours evaluating, testing, migrating, and onboarding to a new tool, you now are stuck with a crappy tool.
But hey, you can tell your CEO you saved money right, so it’s not your head on the chopping block? Nevermind that you spent more than $100,000 in salary-hours doing the migration. Nevermind that while you were busy replacing great with shit your competitors were building new functionality.
This would be like if a CTO decided to move their entire department to worse computers, because they found out most people almost never use all of their CPU. If you find yourself saying “but wait, maybe that’s actually a good idea”, please remind me not to invest in your company.
Epilogue 2: None Of This Is New
Tech teams shitting on SaaS products is not new. Since the beginning of time, it’s been major recreation for some tech teams to dunk on every SaaS tool out there, lamenting how such garbage products have such successful businesses. Then they try to in-house stuff to empire build. Then things fall apart and they blame everything but themselves.
People making short-sighted tooling decisions is also not new.
Neither of these are new, AI and high interest rates are the just great catalysts for giving in to our worst instincts. And we know that’s happening in other areas as well.