Build an App or a workflow? A key decision that drives Enterprise AI ROI/TCO
Most enterprises are picking an "AI strategy" org-wide but they should be picking per business outcome. There are two scenarios, governance regimes, and cost structures that need to be mapped out...
With the advent of Agentic tooling, enterprises are facing another dimension in the buy vs build decision matrix when opting to build: using coding agents to create a complete application to do the actual work; or using coding agents themselves to do the actual work via targeted workflows, skills, MCPs, hooks, etc.
The two scenarios are clean and simple, even though the operating models are very different.
“Full App”: Use coding harnesses to build deterministic software. Claude Code (or Codex, or Pi) helps your engineers ship traditional software faster. The harness disappears at deploy. The customer never sees an agent. This is the most common scenario today in the enterprise, and it's the one most engineering teams default to without thinking about it because that's all they've ever shipped. The agent is a build-time tool. Your engineers point Claude Code at a problem, the agent helps produce React, Terraform, Python, SQL, whatever, and then the agent goes away. What you ship is traditional software that runs without an agent in the loop.
“Agentic Workflow”: Use coding harnesses to build workflows with skills, MCPs, hooks, etc. IMO this is the scenario I think that creates the biggest market opportunity for the next 3 years. The deliverable IS the workflow and there is no traditional app to ship. What you deliver to the customer is a Git repo with a CLAUDE.md/AGENT.md, a handful of skills, maybe some hooks, maybe a couple of MCP servers exposing the customer’s data sources. The operator opens Claude Code (or a wrapper), types a slash command, the work happens inside the harness itself. Claude Code IS the runtime. This is a perfect match for the majority of internal enterprise workflows.... quarterly close prep, competitive monitoring, internal audit spot-checks, vendor renewal review, customer onboarding configuration, compliance evidence gathering, sales discovery, ops investigation, dealer parser changes, audit anomaly review. All of this work today either gets crammed into a traditional app (expensive, slow, often abandoned), or it falls into Excel + email + SharePoint (cheap, fast, ungoverned shadow IT). We now have an option that didn’t exist before: the speed of Excel-and-email with the governance of a real app.
One size does not fit all...
The decision between a full app and workflow is NOT a strategic positioning decision for the company. It is a per-initiative decision, and any large enterprise will end up with a portfolio that has both scenarios in it.
Concrete example portfolio for a typical large enterprise:
Customer support automation → CC workflow run by ops team, or embedded inside the existing support webapp
Internal compliance auditing → compliance officer opens Claude Code, runs an audit skill, gets a findings report
Engineering productivity for net-new microservices → Codex / Claude Code writes the code, deploys as traditional SW, agent leaves
Regulated patient-facing healthcare app → Full app with NARROW agentic workflows embedded for the perception layer
Sales discovery workflow → SE opens Claude Code, runs a discovery skill, hands the output to the customer
High-volume document processing pipeline → Claude Code writes a deterministic pipeline, deploys as traditional batch infra
When do you need a full app?
There are some requirements where a workflow simply does not work. If your business outcome hits any of these, you are building an app, period.
The good news is that most internal enterprise workflows don't hit any of these ceilings.
When a workflow is the right call...
For everything else you’ve got room to actually make a decision. Here’s a sample scoring sheet we’ve run when deciding whether a given outcome should be a workflow.
The costs compared...
The cost shapes of the two options are different curves entirely.
An app has high build cost, high day-2 cost, and near-zero cost-per-execution. Once you’ve paid the build tax and you’re paying the ops tax, the marginal cost of one more run is basically free... i.e. the entire reason SaaS exists.
A workflow is the inverse: very low build cost and very low day-2 cost but REAL cost-per-execution because every run hits the model, every run consumes tokens, every run is metered. The cost scales LINEARLY with volume in a way that an app doesn’t.
It’s important to look at this holistically and not just the build cost (a workflow is 100x cheaper to build) and stop right there. The cost curves cross over at some volume threshold and it’s important to forecast that against anticipated usage.
Useful pattern: start the modeling as a workflow and only refactor to an app if you cross a hard ceiling. Don’t build apps speculatively for enterprise processes!
Where workflows break...
Workflows aren’t free, and the failure modes are different from anything an SDLC team has seen before. What shows up most often in production:
Model drift. When the underlying model changes behavior (Anthropic ships Sonnet 4.7, your prompts that worked on 4.6 now produce subtly different outputs), you discover the drift via a confused user unless you have a frozen eval set that runs on every model release.
Versioning and rollback pain. Skills evolve, hooks change, prompts get tuned. Without disciplined Git workflow and the ability to roll back to a known-good skill version, you’ll find yourself unable to reproduce yesterday’s correct output for a customer asking why the report looks different. Treat skills exactly like code: branches, PRs, versioning, rollback procedures, the works.
Knowledge concentration risk. AI workflows are only as maintainable as their artifacts. Because they are often designed and tuned by a single person or small team (via CLAUDE.md, custom skills, prompts, etc.), institutional knowledge becomes heavily concentrated. When that individual rotates off or leaves, the workflow turns into a black box for anyone who inherits it.
None of these are showstoppers, but all three need to be baked into the overall strategy.
The “sale” is the business outcome!
In every enterprise I’ve sold into, internal IT projects fall into two silos:
Build a real internal app. Expensive, slow, requires a team, infrastructure, ongoing ops. Half of these get abandoned before launch, and the other half ship and then nobody loves them. This is basically Scenario 1 today, applied to internal tooling.
Do it in Excel + email + SharePoint. Cheap, fast, completely ungoverned, shadow IT hell. The lifeblood of every Fortune 500 and also their biggest compliance risk.
Almost every enterprise workflow that actually matters but isn’t strategic enough to justify a full app falls into the “ungoverned shadow IT hell” bucket by default. This is a MASSIVE pile of stuff! Quarterly close prep, competitive monitoring, internal audit spot-checks, vendor renewal review, customer onboarding configuration, compliance evidence gathering, the list is endless and it dominates the actual work-hours in every enterprise.
Hard to size precisely but the order of magnitude is staggering. A typical F500 has thousands of these workflows running across every department, each consuming a few hours to several dozen hours per week of skilled labor. McKinsey-style estimates put 30-40% of knowledge worker time on tasks that fit this description: structured-but-unautomated work that an attentive analyst handles in spreadsheets and email because nobody is going to greenlight a real internal app for it. That’s hundreds of thousands of person-hours per year per company that today flow through ungoverned shadow IT. Multiply by the number of large enterprises in the world and the addressable opportunity is in the hundreds of billions of dollars of labor cost. Almost none of it is on any AI vendor’s roadmap today.
IME most people pitching “enterprise AI agents” today don’t understand this yet. They keep trying to build full apps with AI duct-taped onto them. The actual opportunity is to eat “shadow IT hell” alive with governed workflows.