There's a question rattling around every enterprise planning meeting right now: do we rip out our legacy systems and go all-in on AI-native platforms, or do we just wait for SAP, Workday, and Salesforce to catch up? Both options feel expensive. Both feel slow. And neither one gets your team any real results this quarter.
What's actually happening in companies that are ahead of the curve: they're doing neither. They're building small.
A recent WSJ piece captured the pattern bluntly. Tech leaders at large corporations are "vibe-coding" their own small, custom apps while simultaneously pressuring their software vendors to accelerate AI roadmaps. It sounds almost too simple.
What "Vibe-Coding" Actually Means in an Enterprise Context
The term comes from computer scientist Andrej Karpathy, who coined it in early 2025 to describe AI-assisted development where you describe what you want in plain language and let the AI generate the code. Non-technical users can spin up a working app in days instead of months. Development costs that once ran into the millions now run in the tens of thousands.
In a startup, that means a founder can build a product without a dev team. In an enterprise, it means a finance manager can commission a custom invoice-reconciliation app that sits on top of SAP without waiting for SAP's next major release, without an 18-month implementation project, and without touching the core system of record that the rest of the business depends on.
That's the move. Not replacing SAP. Not waiting for SAP. Building a thin layer on top that solves your specific workflow problem, right now.
The Dual-Track Strategy
What makes this interesting isn't just the build-small approach on its own. It's what companies are doing alongside it. They're running two tracks at once:
Track 1: Build a lightweight micro-app to solve the specific pain point that's slowing down a team today. Fast to build, cheap to run, easy to throw away if it doesn't work.
Track 2: Pressure your vendor to ship the AI features you need in the next 12-18 months. Use the micro-app as leverage: "we built this ourselves because you didn't move fast enough."
Running both tracks generates visible ROI while the vendor catches up. You also end up with a concrete benchmark for what "good" looks like — and a real negotiating chip at renewal time.
What This Looks Like in Practice
Take an accounts payable team running SAP. Traditional invoice reconciliation is a slog: manual matching, exception queues, month-end scrambles. SAP has been building AI capabilities into S/4HANA, and tools like SAP Build now let teams create AI-assisted workflows using natural language prompts. But getting a full SAP AI implementation live takes time and budget that most mid-market teams don't have on hand.
The vibe-coding play: build a lightweight app that pulls invoice data from SAP via API, runs an AI matching layer on top, flags exceptions, and writes results back to the system.
Total development time: a few weeks. The core SAP instance stays untouched. The AP team gets 40-60% of their manual reconciliation hours back.
Same story on the HR side. An HR operations team running Workday can't always wait for native agents to mature. So they build a scheduling and case-routing tool that reads from Workday's data layer and handles specific workflows — shift coverage requests, leave approvals, manager escalations — that the platform's out-of-the-box features don't handle elegantly yet.
The Window Is Real, But It's Closing
The window for "build small" is genuine, but the vendors are catching up faster than most people realize.
Workday just launched Sana, branded as "superintelligence for work," and it's not just a marketing headline. The platform includes 300+ HR and finance skills, a self-service agent that handles pay, time, and absence workflows end-to-end, and cross-system integration with Gmail, Salesforce, Slack, and SharePoint. Unlike 18 months ago, it's now available via Flex Credits without requiring a separate license purchase or an implementation project to unlock. That pricing shift alone changes the build-vs-wait calculus for a lot of mid-market teams.
Workday's argument is pointed: agents, copilots, and AI tools spread across disconnected systems fail to realize the impact of AI investments because they're outside the workflows that actually run the business. Their implicit critique of the vibe-coding approach is that scattered micro-apps have no context, no audit trail, and no compliance guardrails. They're not wrong about the risk.
Snowflake is coming from a different angle. Project SnowWork is an agentic execution platform that takes conversational prompts and turns them into governed, end-to-end business outputs: forecast materials for board presentations, churn analysis spreadsheets, supply chain bottleneck reports. It runs on your existing Snowflake data with full role-based access controls and audit logging baked in. Currently in limited preview, but if it ships on schedule, the line between your data warehouse and your workflow layer effectively disappears.
If you're in mid-market and your current Workday or Snowflake contract comes up for renewal in 18-24 months, the native AI capabilities inside those platforms are going to look a lot more capable than they do today.
The App Sprawl Problem Nobody Talks About
If every department starts spinning up their own micro-apps — finance has three, HR has two, operations built something last quarter that nobody documented — you end up with an AI sprawl problem that can be worse than the original workflow bottleneck.
A Torii report from early 2026 found that 61% of enterprise apps are already unmanaged as shadow IT, and AI is accelerating the problem, not solving it. Each micro-app is a new attack surface, a new data governance question, a new support burden for IT. Dimensional Research found that 23% of IT professionals had already seen AI agents tricked into revealing credentials.
The governance problem is real. And it's exactly what the Sana pitch is designed to exploit.
Build vs. Wait: Four Signals That Tell You Which Path to Take
The clearest signal for building a custom micro-app is a workflow gap that's costing measurable time or money right now, combined with a vendor roadmap that puts a native fix 12+ months out. Everything else — how specific the use case is, how tightly it can be scoped to one team and one success metric — is secondary to those two conditions.
Build when:
- The gap is real and expensive today, and the vendor timeline is 12+ months out
- The use case is genuinely unique to your organization: a custom approval routing logic, a proprietary data source, a regulatory quirk your vendor's standard product doesn't cover
Wait when:
- The native feature is 6-9 months out and your current workaround is tolerable
- The use case is standard — expense approvals, common HR policy lookups, routine analytics. Vendors have built those features and will keep improving them
- The vendor's compliance and audit framework would be expensive to replicate in a custom build
- You're already managing more micro-apps than your IT team can realistically monitor
Regardless of which path you take:
- Register every custom app in a central AI asset inventory, including quick prototypes. If IT doesn't know it exists, they can't govern it
- Define an ownership model: who maintains it and who shuts it down if it breaks
- Set a sunset date for each micro-app tied to a specific vendor feature milestone — when Workday ships native scheduling agents, retire the one your HR team built
- Treat API access to your ERP as a governance matter, not just a technical one
What to Do Before Your Next Vendor Renewal
The companies winning right now move fast on narrow, high-ROI problems, keep their systems of record intact, and actively manage vendor relationships to pull forward what's coming next. That combination is different from either extreme: ripping out your ERP or passively waiting for your vendor's roadmap to catch up.
Workday Sana and Snowflake SnowWork tell you exactly how much runway you have. Use it deliberately. Know what you're building, know why you're building it instead of waiting, and have a plan for retiring it when the native capability arrives.
The companies that come out ahead won't be the ones who built the most micro-apps. They'll be the ones who knew when to stop building them.