Excel Add-in vs Web App for an AI Finance Tool

For an AI finance tool, build the Excel add-in first and the web app second. Finance people work in the spreadsheet, so a tool that lives inside Excel gets used, and a tool that asks them to leave Excel gets compared with Excel and loses.

This matters more than it looks, because the choice is usually made early by a founder who thinks in his own product. He wants a place where the AI can show everything it does, so he builds a web app. His buyer does not want a new place. She wants her own workbook to get faster, and she will pick the thinner tool that gives her that.

The Export to Excel button nobody meant to make the main feature

Picture an FP&A tool for finance teams at companies of a few hundred people. A controller signs up for a pilot. The first screen says Upload your model and takes an .xlsx file. She drops in the operating model she has kept for three years, the one with fourteen tabs and a Board tab at the end.

The next screen is called Map your sheets. It lists every tab down the left and asks her to tag each one as Revenue, Headcount, Opex or Ignore. Then it asks her to rebuild her cases as Scenarios, with a Base and a Downside, by picking drivers from a dropdown. Twenty minutes in, the product shows a clean variance chart and a paragraph of AI commentary that is honestly good.

Then she needs it in the board pack, which is a workbook. She clicks Export to Excel. What comes back is a new file with values pasted in, no formulas, her number formats gone, and none of her cell comments. She copies the commentary into her own Board tab by hand. By the third week the Export to Excel button is the most clicked control in the whole product, and she has stopped opening the dashboards.

The 350 pixel pane that won the pilot

Now picture a competitor with a smaller model and fewer features. It is an Excel add-in. It opens as a task pane on the right side of her own workbook. Microsoft's own sizing guide puts that pane at about 350 by 378 pixels in Excel at a common laptop resolution. That is small, and it does not matter.

She selects the range with actuals and budget on her Opex tab and clicks Explain variance. The pane writes three short lines of commentary into column N, next to the rows they describe. Where it proposes a new line, it writes a formula that points at her cells, not a pasted number. Her formats stay. Her Board tab still links to everything. She never uploaded anything or learned what a Scenario is.

The first product is better at analysis. The second one is inside the only interface her job runs on, and it wins the pilot. This is the pattern finance buyers repeat: they do not choose the stronger model. They choose the one that did not ask them to move.

What the founder of the web app sees in his logs

The founder of the first product demos it on every sales call, and the demos go well. He uploads a clean sample model, clicks through Scenarios, and the room nods. His pilots start well too. Uploads spike on Monday of week one.

Then the logs go quiet. He can see sessions shrink to a login, an Export to Excel, and a logout. His response is to make exporting better. He adds CSV, then Google Sheets, then a setting to keep number formats. Each release closes a ticket and nothing else moves. When a prospect asks whether it works inside Excel, he calls the add-in a distribution channel and puts it on the roadmap for next year.

He knows his product, and to him the web app is obviously the product. His buyer knows her workbook, and to her the web app is a detour. Nobody on her side will say that in a churn survey. She just returns to the file she trusts.

Why build the web app first, add Excel later is backwards

Most advice on this choice says the same thing. Build your real product as a web app, because that is where you control the experience, then ship a thin add-in later to feed people into it. That advice is fine for tools where the spreadsheet is one of many inputs. It is wrong for finance, where the spreadsheet is the interface and also the deliverable.

A controller does not finish her work in your product. She finishes it in a workbook that goes to her CFO and then to the board. Every step you add between her data and that workbook is a step she has to repeat every month close. So for a finance buyer, a web app is not a neutral home. It is a second place to keep in sync, and she already has a place that works.

There is a money reason too. Product-led benchmarks, measured on SaaS rather than AI companies, put activation at 20 to 40 percent for most products. If your activation event is a finished variance explanation, a flow that needs an upload, a mapping step and a rebuild will lose people at each one. And each abandoned upload was still processed. Measured on AI companies, gross margin sits around 52 percent against 70 to 80 for traditional software, because inference lands in cost of goods. You pay to model a workbook nobody comes back to.

What an Excel add-in can and cannot show

The honest case for an add-in rests on what Office.js actually allows. Microsoft's Excel add-in overview says an add-in can read and write workbook data, including ranges, tables and charts. It can add ribbon and context menu commands, open a task pane, and open a dialog box for sign-in or a confirmation. The same add-in runs in Excel on the web, Windows, Mac and iPad.

It can also add custom functions that people type into a cell just like SUM, with your namespace in front. For finance this is the quiet win. A function that returns a forecast or a flagged variance lives in her model, recalculates with it, and survives being copied into next month's file. One caveat from the same page: custom functions are not supported on Office for iPad.

What an add-in cannot give you is room. A narrow pane is a poor place for a wide chart, a long approval thread, or a comparison of six scenarios side by side. It also sees one workbook at a time. If your product needs to hold twelve subsidiaries' files together, or show who changed which assumption across a team, the pane is the wrong surface for that part.

Writing into her cells without breaking her trust

Being inside Excel is a privilege, and one bad write ends it. A finance user who finds a hard coded number where a formula used to be will uninstall the add-in the same afternoon. Design the write path before anything else.

• Write formulas that reference her cells, never pasted values, unless she asks for values.

• Write into new cells or a clearly named new column. Never overwrite a cell that already has content without showing the old and new value first.

• Group each action so one Ctrl+Z reverses it. Excel's JavaScript API supports undo grouping through mergeUndoGroup, so a three line commentary is one undo, not three.

• Avoid the calls that break undo. The same Microsoft page lists APIs that clear the undo stack, including deleting or copying a worksheet. If an action needs one, ask for confirmation in plain words first.

• Mark what the AI wrote. A cell note or a light fill tells her CFO which lines came from the model, which matters in a review.

When a web app earns its place, and how to hand off

A web app is still the right surface for some jobs. Keep it for work that has no single workbook to live in: consolidating many entities, approval flows with several people, an audit trail of every change, and the admin screens where someone connects the ERP and sets permissions. These are often a different person from the controller, so they can live in a different place.

The handoff is where most two surface products fall apart. The rule is that each surface links to the exact spot in the other. A pane message that says a variance needs approval should open the web app on that approval, not on a home dashboard. A web app item that came from a cell should show the file and cell address and a button that opens that workbook. This is the same thinking as placing prompts in context in feature adoption work: send people to the place the work is.

If you already have a copilot inside your own web app, the question of panel versus inline suggestions is a different one, covered in our post on copilot sidebars and inline suggestions. This post is about the step before that, which is whether to live in your screen or someone else's.

A decision you can make this week

You do not need a rebuild to answer this. You need a few days with your own logs and three customers.

• Count how often each session ends in Export to Excel, copy, or download. If it is the most common last action, your users are telling you where they work.

• Write down your activation event as a finished piece of her work, such as a variance explained in her board file. Then count the steps from signup to that event on each surface.

• Watch three controllers do a real month end task with your product. Note every time they switch back to Excel and what they carry across.

• Pick one job that ends in a cell, and prototype it as a task pane with a single button. Write formulas, group the undo, and mark what the AI wrote.

• List what the pane cannot hold. Whatever needs many workbooks or many people stays in the web app, with deep links both ways.

If you are comparing outside help for this, the list of product design agencies for AI fintech startups shows what to ask them about add-in work.

Studio Maydit is a product design studio for AI founders, and the surface question comes up often in our work with finance and data products. The model is usually strong. The flow around it was drawn by a founder who is happy to open a new tab, for a buyer who is not. We map where the work ends, design the pane and the write path into the user's own file, and keep the web app for the jobs a grid cannot hold. Fixed-scope projects run three to four weeks and end with a diagnosis of what is leaking in the product. If your pilots keep ending in an export, book a 30-minute call with Studio Maydit.