Creuto is now an OpenAI Select Partner Read More
Build vs buy enterprise software in 2026: 56% still prefer to build. Which SaaS layers are cheaper to own, which to keep buying, and how to decide.

The build vs buy enterprise software question has stopped being about platforms. Futurum's survey of 830 IT decision-makers found that 56.0% prefer to build most applications in-house, almost unchanged from 56.6% six months earlier. What has moved is scope: teams now replace thin SaaS layers such as admin tools and workflow automations, and keep buying the hard ones.
By the end of this post you will have a layer-by-layer verdict on which subscriptions are cheaper to own and which to keep paying for. You will also have four questions that settle the call for any single tool, and a clear view of when building is the wrong answer. That matters if you have been asked to cut software spend without breaking the operations that run on it.
Futurum published its 1H 2026 Enterprise Software Decision Maker Survey on 17 June 2026, drawing on January 2026 data. The share preferring to build most applications internally, and buy only when needed, was 56.0%, against 56.6% in the second half of 2025. Futurum itself calls it "near-zero movement."
That stability is the useful part. Between the two survey waves, AI coding tools did not push the build preference up, and SaaS vendors adding AI features did not push it down. The open question is no longer whether to build, but which layers.
The same release shows who is doing the building. In the survey, 53.3% of organizations say 20-40% of their non-IT workforce uses no-code, low-code or natural-language tools to create or modify applications, and another 22.3% put that share at 40-60%. Building is no longer something only your engineering team does. That changes the risk profile of "build" as much as its cost.
The other widely quoted dataset is Retool's 2026 build vs buy report, published on 17 February 2026. Read it knowing who wrote it. Retool sells a platform for building internal tools, and the survey covers "817 builders, including Retool customers," surveyed in late 2025. Software engineers made up 36% of respondents and IT staff 6%. A sample built around one vendor's users will lean toward building, so treat its figures as an upper bound on enthusiasm.
Three figures from it get repeated most. According to Retool, 35% of teams "have already replaced functionality of at least one SaaS tool," 78% plan to build more custom tools in 2026, and 60% of builders built something outside IT oversight in the past year.
Read the 35% carefully. Replacing the functionality of a tool is not the same as cancelling a subscription. A team that rebuilt one report from a BI product counts, even if the contract renewed. It is easy to compress that into "35% replaced a SaaS tool," which overstates what was asked.
The category breakdown has the same problem. Retool's chart is titled "SaaS tools at risk for replacement," and the page does not give the question wording or the base. These are categories under pressure, not confirmed replacements.
| SaaS category | Share citing replacement risk (Retool) |
|---|---|
| Workflow automations | 35% |
| Internal admin tools | 33% |
| BI tools | 29% |
| CRMs and form builders | 25% |
| Project management | 23% |
| Customer support | 21% |
Even with the vendor bias, the order is informative. The categories at the top are narrow, internal and shaped around how one company works. The ones further down serve more people or touch customers. That gradient is the basis of the framework below.
Treat your SaaS estate as layers, not products. A 250-person firm rarely needs to decide whether to build "a CRM" or "an ERP." It needs to decide whether the approval flow, the ops dashboard or the admin panel sitting on top of those systems is worth owning.
| Layer | Verdict | Why |
|---|---|---|
| Internal admin tools and back-office panels | Own | Internal users only, sits on your own data, narrow scope |
| Workflow automations and approvals | Own, when the workflow is yours | Generic tools force your process into their model; the logic is specific |
| Operational dashboards | Own the fixed views | Questions you ask every week; keep an analytics tool for ad hoc work |
| CRM | Do the seat maths | Turns on user count, pricing tier and how custom the sales process is |
| ERP core | Depends on fit | Worth building when departments cannot share one source of truth on a packaged product |
| Security, identity and compliance controls | Keep buying | Vendors test these across far more environments than you can |
| Workflows that cross into other companies | Keep buying | Futurum names cross-company workflows and third-party integrations as vendor strengths |
The CRM row turns on arithmetic. Our breakdown of HubSpot vs custom CRM seat maths shows how the answer flips with headcount and tier. ERP has a similar threshold, covered in our post on what Odoo really costs against a custom ERP.
Custom software is cheaper than SaaS when you are paying for seats and features you do not use on a tool whose workflow is narrow and internal. Total cost of ownership is the comparison that matters, and the SaaS side is often worse than the invoice suggests.
Zylo, which sells SaaS management software and so has its own interest in this number, reports in its 2026 SaaS Management Index a median SaaS spend of $9,455 per employee. The same index finds organizations leave an average of 36% of their SaaS licenses unused and add an average of 21 applications per month, while overall application counts stay largely flat. The data comes from more than 40 million licenses and $75 billion in spend under management.
That churn of new apps is SaaS sprawl in motion: tools come in, overlap, and rarely leave. A firm with a dozen overlapping subscriptions is often paying several times over for the same three capabilities, a form, a queue and an approval.
The other side of the ledger is ownership. A custom build carries hosting, security patching, changes when the process changes, and someone who understands the code two years from now. Retool's own customer story says ClickUp cut $200K per year in automation software by building its own tools, a real result but one picked by the vendor to showcase. Your own numbers should come from your own invoices and a scoped estimate, not from a case study.
The best argument for buying comes from the same Futurum release that reported the 56%. It lists four places where SaaS vendors keep an edge: designing workflows across organizational boundaries, owning the maintenance and upgrade lifecycle, security and data privacy controls tested across "thousands of enterprise environments," and managing third-party integrations. It also says vendors that cut implementation from months to weeks can still win build-first buyers.
Those are real costs, and they fall hardest on companies of 50-500 people with small platform teams. A custom tool that handles personal data needs the same access control, audit and patching discipline as the product it replaced. Building is the wrong choice if the tool is regulated, shared with outside parties, or would be owned by one person who might leave.
The shadow IT figure points to a second risk. If 60% of Retool's builders shipped something outside IT oversight, many companies already own custom software they do not know about. Before you commission a new build, find the ones you already have. A build that nobody maintains carries the costs of ownership without any of the control.
Two of our projects sit on either side of this framework. We built a workflow management system for enterprise workflow automation, with task boards, a collaboration engine, a reporting suite and a full task audit trail. That is the workflow automation layer from the table, built as its own product rather than bolted onto a generic tool.
The second was a custom ERP for a large-scale industrial client that unified HR, CRM, inventory and finance in one browser-based platform. Four departments moved onto one source of truth, with no data silos after launch. The value there was the unification. When the cost you are fighting is the joins between tools rather than any one subscription, the ERP core becomes a build candidate.
Neither project argues for replacing everything. One is a single layer, the other is the core, and the framework above is how you tell which one you are looking at.
Start with an export of every subscription, its seat count and its renewal date. Mark each one against the four questions above. The first build candidate is usually the tool with the most unused seats, a workflow only your company runs, and no outside users. Leave security, identity and partner-facing tools on the buy list.
Then build that one layer, measure it against the renewal you skipped, and decide on the next from evidence. If you are weighing which SaaS subscription to replace first, our custom software development team can scope that single layer against your current spend. A focused MVP typically takes us 6-10 weeks, so you can see a working result before most annual renewals come around.
Most enterprises still lean toward building: Futurum's survey of 830 IT decision-makers found 56.0% prefer to build most applications in-house. The practical answer for a mid-sized firm is to build narrow internal layers such as admin tools and workflow automations, and keep buying security, identity and partner-facing tools.
Retool's 2026 report, a vendor survey of 817 builders, lists workflow automations (35%), internal admin tools (33%), BI tools (29%) and CRMs and form builders (25%) as the categories most at risk of replacement. Those figures describe pressure on a category, not confirmed cancellations of subscriptions.
Custom software tends to be cheaper than SaaS when a company pays for seats and features it does not use on a tool with a narrow, internal workflow. Zylo's 2026 index reports organizations leave 36% of SaaS licenses unused, but any build also has to carry hosting, patching and long-term maintenance.
Keeping a SaaS product is usually the right call when the tool is regulated, shared with suppliers or customers, or depends on many third-party integrations. Futurum names cross-company workflows, maintenance, security controls and integrations as areas where vendors keep an edge over internal teams.
Replacing a single SaaS layer with a custom build is usually scoped as a focused MVP, which typically takes Creuto 6-10 weeks. A larger enterprise platform such as a custom ERP typically takes 3-6 months, depending on complexity, integrations and scope.
Ready to take the first step towards unlocking opportunities, realizing goals, and embracing innovation? We're here and eager to connect.