wGrow
menu
Field note · Migrated 2026-04-04 · 5 min

When Excel VBA is still the right answer.

Our 2023 case study built a sales-order management system in Excel VBA because the client's IT compliance gate was 12 months and Excel was already approved. The pattern still applies — and shows up more often in the AI era, not less.

In 2022 we built a sales-order management system in Microsoft Excel with VBA and Forms for a European MNC’s Singapore office. The reason was not aesthetic. The client’s group IT compliance check for any new custom application took 12+ months. Excel was already on the approved-tools list. We delivered in three months. The system is still running.

We wrote it up in 2023 (Team-Notes #62) as a case in appropriate-tool selection. Three years later, the lesson holds — and shows up more often in our work, not less. Here is the rewrite.

What the original got right

  • Compliance is part of the architecture. A 12-month compliance gate is an architectural constraint, the same way a firewall posture or a database licence is.
  • The right tool is the one you can ship now. A custom .NET application that’s perfect-on-paper but stuck in compliance review for a year is, in product terms, worse than an Excel workbook delivered in three months.
  • Honest about limits. The 2023 article listed the trade-offs: limited concurrent users, performance issues past ~100K rows, Windows-only, hard to scale. Those still apply.

Why this pattern shows up more in 2026, not less

We expected, when we wrote the original, that the rise of low-code platforms (Power Apps, AppSheet, Retool) would eat this category. To some extent it has. But two things have pushed the Excel-VBA pattern back into our work:

1. AI-generated VBA is now usable

Three years ago, hand-writing VBA was tedious, but it was the cost of admission. In 2026, our drafter agent writes most of the VBA we ship. The agent is dramatically better at VBA than we ever wanted to be ourselves; it knows the deprecated APIs, the locale quirks, the version differences across Excel 2016 / 2019 / 365. We spend our time specifying the workbook structure, not typing Range.Offset(0, 1).Value.

This has shifted the math. A workbook that was a 6-week build in 2022 is a 1–2 week build in 2026. The pattern is more attractive than it was.

2. Compliance gates haven’t gotten faster

If anything, the gates have lengthened. Every new compliance question added by IMDA, MAS, PDPC, or a parent group’s risk team is one more box to tick before a custom app is approved. Meanwhile, the approved-tools list still contains Excel. We have shipped more “Excel-shaped solutions” in 2025 than in 2022, for exactly this reason.

When the pattern is wrong

We refuse the Excel-VBA pattern in three cases:

  1. More than ~50 concurrent users on the same workbook. SharePoint co-authoring helps but the corruption / locking surface is real.
  2. Workbooks larger than ~100K rows in any active sheet, or with heavy cross-sheet formula chains. Performance falls off a cliff.
  3. Anything that needs a real audit trail of who changed what, when, with grounded after-the-fact reconstruction. Excel’s change-tracking is not audit-grade.

If any of those apply, we push back to the client and propose an alternative — even if compliance takes longer.

What we’d add to the 2023 design today

A small Power Automate flow as the bus

Where the workbook needs to talk to other systems (email, a SharePoint list, a vendor API), we now use Power Automate as the integration bus rather than VBA’s MSXML2.ServerXMLHTTP. Less brittle, easier to log, and the IT team usually already has it in the approved tooling.

Workbook protection by role

We use Excel’s sheet protection + workbook structure protection by role group. Combined with SharePoint’s permissions, you can get a usable role-based access pattern from a single shared workbook. Not a substitute for a real auth system, but enough for many internal workflows.

Version control through Office Scripts (where allowed)

For estates that have Office Scripts (Excel TypeScript automation) enabled, we are slowly migrating new automation off VBA onto Office Scripts. They version cleanly in source control, run sandboxed, and survive the eventual “we’re moving to Mac” conversation that always happens five years later. VBA still ships when the client estate is Windows-pinned and the workbook is staying on-prem.

The agent-era footnote

A pattern we have started using: the workbook calls out (via Power Automate) to a small in-house agent that handles the one piece of cognitive work the workbook can’t reasonably do — categorising a free-text field, generating a draft email, summarising a customer note. The workbook stays the system of record. The agent does the bit that VBA can’t.

This is how we’d build that 2022 sales-order workbook today. The agent would not be the architecture. It would be a sub-component the workbook calls when it needs to think about a free-text field.

What we cut from the original

  • The implied apology for using Excel. There is no apology to make. The Excel-VBA pattern is correct, often, in 2026.

What carries over unchanged

The lesson. Match the tool to the constraint. The constraint includes compliance, the team’s existing skills, and the timeline — not just the technical fit.

— wGrow studio · migrated from Team-Notes #62