flowchart LR
A[Technical author<br/>Edit mode] --> B[Connect inputs<br/>build + validate Python]
B --> C[Save notebook +<br/>Open as: App preference]
C --> D[Share the same<br/>Excel workbook]
D --> E[Workbook user<br/>App mode]
E --> F[Change approved inputs<br/>and notebook controls]
F --> G[Review published results<br/>in Excel + App presentation]
Turn spreadsheets into software
Turn spreadsheets
into software
Build Python-powered applications without leaving Excel. Keep workbook inputs and review in the grid, move substantial logic into a reactive Python notebook, and hand off a focused App experience when another person needs to operate the workbook.
Demand & Inventory PlannerApp-mode operator view · mixed-integer planningTry live demo →
Used by professionals at organizations including…
Keep the workbook. Move the application logic.
When a spreadsheet starts behaving like software, put the multi-step Python work in one inspectable notebook while keeping Excel as the familiar input, review, and delivery surface.
1 · Move complex logic out of the grid
Keep Python, explanations, intermediate results, diagnostics, charts, and controls together in one reactive workspace instead of scattering application logic across cells and helper sheets.
2 · Keep Excel as the familiar interface
Use live workbook data as inputs, publish selected results back to cells, and expose reusable Python logic through BF.FUNCTION() for people who keep working in Excel.
3 · Build once, hand off a simpler experience
Authors work in Edit mode. When the analysis becomes a repeatable tool, App mode presents the same saved notebook as a focused operating surface for workbook users.
4 · Keep the logic inspectable
The notebook is represented as Python source, so application logic can be reviewed, diffed, backed up, and version controlled when your workflow calls for normal software practices.
Build in Edit mode. Hand off in App mode.
The differentiator is not only where Python runs. It is the path from a technical workbook owner to another person who needs to use the result without maintaining the implementation.
Build and maintain the application
Connect worksheet inputs, write and test Python, inspect diagnostics, add controls and charts, publish workbook-facing results, then save the notebook with the workbook.
Operate the saved application
Open the workbook, change approved worksheet assumptions or notebook controls, review results, and use the focused App presentation without needing the full authoring surface.
The same workbook moves through the handoff; the authoring surface changes, but the saved Python application logic remains with the file.
Validate the handoff: close and reopen the workbook, verify the intended App presentation, change a representative worksheet input, and have a second user complete the operating task without author intervention. Use the Inventory Planner as the reference application →
App mode is a presentation choice, not a permissions or source-protection boundary. Shared workbooks still contain executable Python and should be reviewed and trusted accordingly.
Start with applications that are available now.
The public catalog remains intentionally focused while the application patterns are being tested. These examples are published finance and operations applications rather than placeholders for future coverage.
Cash-flow and liquidity planning
Forecast receipts and payments, apply visible management scenarios, and review ending cash, downside headroom, and liquidity-threshold warnings in the workbook.
Demand forecasting with backtests
Compare transparent forecast baselines with rolling-origin evaluation before publishing the selected forward plan and prediction bands back to Excel.
Volume-to-staffing planning
Forecast short-horizon workload, keep productivity and shrinkage assumptions visible in Excel, and translate demand into staffed-shift requirements.
Write the complex calculation once in Python. Call it from Excel.
Publish notebook functions and keep ordinary worksheet formulas as the interface your workbook users already understand.
def project_arr(monthly_revenue, monthly_growth):
return monthly_revenue * (1 + monthly_growth) ** 12
bf.publish(functions={"project_arr": project_arr})
Worksheet use: =BF.FUNCTION(“project_arr”, A1, B1)
Know where the code and data go.
Browser execution by default
Boardflare’s Python runtime runs in the browser by default. Authored notebook code can still make external requests when browser and service policies allow them, so review network behavior as part of the application.
App mode is not a security boundary
The saved notebook source travels with the workbook. Treat a notebook-enabled workbook as executable code and verify who authored it, what data it reads, and which services it contacts.
AI is a separate data path
Notebook AI helps draft, revise, explain, and debug source. It cannot directly read arbitrary workbook cells or execute the notebook unless relevant information is supplied through the authoring context.
Notebook or worksheet cells?
Both approaches can be useful. The important choice is where the Python program should live.
Python in worksheet cells
Python formulas live in the workbook grid and execute in Microsoft’s managed cloud environment. This is a natural fit when the code is part of the worksheet calculation surface.
Python in a reactive notebook
The notebook is the primary home for code, explanation, intermediate results, charts, controls, and reusable logic, while Excel remains connected to the work and can serve as the handoff surface.
Neither model is universally better. They organize the Python work differently. Compare the approaches →
Focused tools for specific spreadsheet workflows.
Try a real workbook application.
Open the inventory planner, change worksheet planning assumptions, and see the same workbook drive a reactive Python optimization model.