Everything in-house: when you replace a platform, you replace the operation that came with it
35% of Retool's respondents already replaced a SaaS tool. What gets replaced is not just software but the operation around it. How to decide what to build.
Ignacio Puig Moreno
Co-founder · Business
When a company replaces a platform with software of its own, it does not replace only the software. It replaces the operation that came with it: making sure emails reach the inbox, following the channel's rules, and having somebody answer in the middle of the night when something breaks. Build in-house what is specific to your business, and keep buying the infrastructure.
"Everything in-house," the CTO of a fast-growing regional fintech told me (a rockstar, by the way). He was talking about replacing the support and messaging platforms that cost them a lot today with software of their own. I told him I did not agree.
I understand where he is coming from. The math he is doing is true. What is missing is the other half.
Why does building everything look obvious today?
Because building got a lot cheaper with AI. Retool, which sells a platform for building internal tools (so, exactly this), surveyed 817 people who build software and published how many already did it.
35%
already replaced functionality of at least one SaaS tool with a custom build
78%
expect to build more tools of their own in 2026
26%
name the maintenance burden among what holds them back from automating more
It has to be read knowing who ran it: the respondents are customers and users of the platform that sells the tool. Even so the figure is useful, because it confirms what any technical team already feels. Making a prototype that replaces a tool is a matter of days. The report also puts customer support tools among the categories under pressure to be replaced, at 21%.
The third figure is the one that tends to stay out of the conversation. It is in the same report, and the report says it plainly: the time saved on one task can be lost to maintenance.
What did Klarna do, the case cited to say "everything in-house"?
It dropped Salesforce's CRM around 2024, and when the news went viral its CEO had to clarify what had happened.
We did not replace SaaS with an LLM.
According to TechCrunch, what they did was take the data that lived in several SaaS systems and consolidate it into infrastructure of their own, with a Neo4j graph database, so their internal AI could use it. And the same CEO said he doubts most companies will choose to build their own software end to end.
It is a case about owning your data, not proof that replacing messaging and support platforms pays off. Citing it as the signal that everything gets built in-house is reading it backwards.
What do you replace when you replace a platform?
Five things that are not in the project estimate, because they are not software.
What comes with the platform
Emails that reach the inbox and not the spam folder. Following each channel's rules: on WhatsApp, the templates, the 24-hour window and a price Meta changed on October 1. Somebody answering at 2 in the morning. Security and audits, which weigh more at a fintech. And the updates every time an API or a vendor changes.
Building it takes days. Maintaining it is forever. And your best engineers end up looking after plumbing instead of improving the product.
We already did this math for AI agents: the cost shows up only at month fourteen, and an agent of your own competes with the product roadmap. The same goes for a support or messaging platform.
What is worth building in-house and what is worth continuing to buy?
My rule is short. What is very specific to your business gets built in-house. What is infrastructure keeps getting bought, and you build on top of it.
| Build it in-house | Keep buying it | |
|---|---|---|
| What it is | What sets your product apart | What your competitors need too |
| If you buy it | You hand a vendor what makes you different | You share a cost with everyone who uses it |
| If it fails | You lose what sets you apart | You lose time, and somebody outside is on call to fix it |
| Example | The logic you use to decide who you lend to | Email, the WhatsApp channel, the help desk |
The table does not say buying is always better. It says which question to ask before the math: whether what you are about to replace is yours or everybody's.
How do you do the math with your own numbers?
We sell a platform, so discount whatever you like from this article. That is why the tool below comes with no result decided in advance: every number is yours, the ones it opens with are an example, and sometimes the math comes out in favor of building.
It has two cumulative cost curves, buying and building, with the two things that are almost always forgotten: the license you keep paying until the replacement ships and a maintenance bill that never ends. Below them, the five jobs that come with the platform, so you can mark which ones already have a name on them in your team, and three questions about whether it is yours.
If you buy it
If you build it
Over 3 years, building it comes out USD 45,500 cheaper. Buy: USD 439,000. Build: USD 393,500.
When it pays for itself: From month 23. Until then, what you have spent building is still above what you would have spent buying.
Engineering that goes in: building and keeping it consumes 41 engineer-months inside the horizon. Buying it, 1. That time is not turned into dollars here, because that number would be ours: put your own price on whatever that team stopped building.
What comes with the platform and is not software
Replacing a platform means replacing the operation that came with it. Mark what already has somebody on your team, by name, who owns it.
5 of 5 with no owner. Each one is an on-call shift or a task with a name on it. The maintenance you entered (USD 8,500 a month) has to be enough to pay for them, or the saving on the curve does not exist.
Three questions the curve cannot answer
Cost answers one of the two questions. The other is whether this is yours or whether it is infrastructure. The first two yeses together are what make it yours; the third is not a reason to build, it is a condition for being able to.
It is a saving on paper. The curve favors building, but nothing you answered says it is yours. That saving exists only if maintenance stays where you put it, and it is paid in on-call shifts and in engineers who are not improving the product.
The model, in plain sight
Buying is the integration months times the cost of an engineer, plus the license for every month. Building is the engineers times their cost times the months of building, plus the license for those same months if you pay it today, plus the maintenance times its cost and what you pay outside, for every month from launch. Every value is yours and the opening ones are an example, not an average. We do not turn what that team would have built instead into dollars: that number would have to be yours.
How to read it
- The two curves do not start from the same point. The build curve rises from the first month because you keep paying for the platform until the replacement is in production. Switch that option off to see how much it weighs.
- Look at the slope of the build curve after the dotted line. If it is close to the buy curve, the saving never arrives: maintenance eats it.
- The sum alone does not decide. Move it until it favors building and answer the three questions: if the verdict turns into a saving on paper, the sum was lying by omission.
It also has a page of its own.
When is it worth building?
When three things hold together. It is what sets your product apart. No platform on the market solves your case. And a team has the on-call assigned by mandate and not as a favor.
If the third is missing, the math can come out in your favor and it is still a saving on paper: it exists only as long as maintenance stays where you put it. The question that settles it is not whether the team can build it, because almost always it can. It is who answers when something breaks at 2 in the morning, and with what budget.
If that question has an answer with a name on it, building is a reasonable decision. If it does not, you already bought an on-call shift and have not found out yet.
I would like to know who has been replacing platforms, which ones, and how the math is turning out against what it cost to buy them, maintenance and on-call included.
Frequently asked questions
Should you build your own support or messaging platform instead of buying one?
It depends on what it is. What is specific to your business and sets you apart is worth building in-house. Infrastructure your competitors need too, such as sending email, the WhatsApp channel or the help desk, is worth continuing to buy and building on top of. And even when the numbers favor building, somebody has to be assigned the on-call to carry it.
Which costs get forgotten when comparing build against buy?
Two, almost every time. The license you keep paying until the replacement is in production, and maintenance, which does not end at launch. After that come the ones that are not software: on-call at any hour, each channel's rules, email deliverability, security and the updates whenever an API changes.
What does the Retool survey say about replacing SaaS tools?
That 35% of the 817 people surveyed already replaced functionality of at least one SaaS tool with a custom build, and 78% expect to build more in 2026. They are customers and users of a platform for building internal tools, so it is worth reading it knowing who made it. The same report lists the maintenance burden among the things holding back more automation.
Ignacio Puig Moreno · Co-founder · Business, StudioChat
Want agents like these working for your team?
Talk to us now