Creuto is now an OpenAI Select Partner Read More

Custom Software Development

Build vs buy enterprise software: which SaaS layers to own

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.

Build vs buy enterprise software: which SaaS layers to own

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.

The 56% build preference is flat, and that is the finding

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.

What Retool's 817 builders said, read closely

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.

Which SaaS tools are companies replacing with custom builds?

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 categoryShare citing replacement risk (Retool)
Workflow automations35%
Internal admin tools33%
BI tools29%
CRMs and form builders25%
Project management23%
Customer support21%

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.

A build vs buy enterprise software framework: price the layer, not the platform

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.

LayerVerdictWhy
Internal admin tools and back-office panelsOwnInternal users only, sits on your own data, narrow scope
Workflow automations and approvalsOwn, when the workflow is yoursGeneric tools force your process into their model; the logic is specific
Operational dashboardsOwn the fixed viewsQuestions you ask every week; keep an analytics tool for ad hoc work
CRMDo the seat mathsTurns on user count, pricing tier and how custom the sales process is
ERP coreDepends on fitWorth building when departments cannot share one source of truth on a packaged product
Security, identity and compliance controlsKeep buyingVendors test these across far more environments than you can
Workflows that cross into other companiesKeep buyingFuturum 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.

How do you decide build vs buy for software? Four questions

  1. Does the tool cross organizational boundaries? Futurum names workflows that span organizations as an area where internal teams struggle to match vendors. If suppliers, customers or auditors log in, lean toward buying.
  2. Who will own maintenance and upgrades? Futurum lists owning the maintenance and upgrade lifecycle as a vendor advantage, and 26% of Retool's respondents cite maintenance burden as a blocker to AI automation. If nobody is named, do not build.
  3. How many of the seats are used? Unused licenses are the cheapest savings to find and the strongest argument for replacing a narrow tool.
  4. Is the workflow how you compete, or how everyone works? Payroll compliance rules apply to every employer in a jurisdiction. Your dispatch rules or your quote approval chain probably are not.

When is custom software cheaper than SaaS?

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 strongest case for buying

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.

What we have seen building workflow and ERP layers

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.

Should we build or buy enterprise software? Start with one layer

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.

Frequently asked questions

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.

Written by

Akash Mohapatra

Akash Mohapatra

Co Founder & Director

28 Oct 2026

·

9 min read

Share

LET'S CONNECT

Connect with Creuto!

Ready to take the first step towards unlocking opportunities, realizing goals, and embracing innovation? We're here and eager to connect.