Product Engineering
From the conversation about why, through architecture and build, to the version that is still maintainable in year three.
SOLUTION · INTERNAL
Internal Business Applications
The spreadsheet that runs a critical process, turned into software that can be maintained.
TARGET PROFILE
Who this architecture is engineered for.
Built specifically for operational teams experiencing structural friction at scale.
The profile
For a team where something genuinely important — scheduling, stock, pricing, compliance tracking — runs on a workbook with fourteen tabs and a macro, maintained by one person, where the file is emailed around and everybody knows which copy is the real one only by asking.
The core bottleneck
Spreadsheets that run operations got there by being genuinely good at the job. They were fast to build, they matched how the work is actually done, and they never required a project. What they lack is everything that matters once other people depend on them: one authoritative copy, a record of who changed what, validation that stops a mistyped figure, and the ability for two people to work at once. The risk is concentrated rather than gradual — a formula edited by accident, a filtered view saved over the original, a version emailed on Tuesday that quietly diverges from the one used on Wednesday. And the whole arrangement usually depends on one person who understands it, which is a problem that only becomes visible when they are unavailable.
SYSTEM MODULES
What we build and integrate.
Every component is engineered for multi-tenant security, auditability, and zero-downtime maintenance.
A data model that reflects how the work is done, not how the tabs happened to be arranged
Validation at entry, so an implausible value is stopped rather than discovered downstream
Roles and permissions, so the people who read and the people who change are different sets
Change history on the records that matter, including who changed a value and when
Concurrent access, so the process does not depend on one person having the file open
The calculations, ported and tested against the existing workbook's outputs
Export back to a spreadsheet, because some genuinely good uses of one should continue
ARCHITECTURE
System composition & topology.
How the core modules, data boundaries, and integrations connect in production.
Node 01
Data model
The entities and relationships the process actually involves, with constraints making the invalid combinations the spreadsheet allowed impossible to enter.
Connects to
- app
- history
- calculations
Node 02
Application interface
Screens built for the way the task is performed, including keyboard-first entry for the high-volume parts. A form that is slower than the spreadsheet will lose to the spreadsheet.
Connects to
- permissions
- calculations
- exports
Node 03
Roles and permissions
Who may view, who may change, and who may approve, enforced by the system rather than by a convention about which copy of the file to edit.
Connects to
- history
Node 04
Calculation layer
The formulas, ported into tested code and verified against the workbook's own outputs across a range of real inputs before anything is trusted.
Connects to
- history
Node 05
Change history
Who changed which value, when, and what it was before. The question a spreadsheet can almost never answer, and the one asked whenever something looks wrong.
Connects to
- exports
Node 06
System connections
Links to the finance, resource planning, or scheduling systems the data is currently copied between by hand, removing the re-keying step and its transcription errors.
Connects to
- model
- history
Node 07
Exports and reporting
Spreadsheet export for the analysis people legitimately do that way, plus the standing reports currently rebuilt by hand each period.
Connects to
- model
TECHNOLOGY DEPTH
Technologies powering Internal Business Applications.
Standardized architecture frameworks and data components integrated in this solution.
Frontend
- Next.js
- React
- TypeScript
Backend
- .NET
- Node.js
Data
- PostgreSQL
- Microsoft SQL Server
Cloud
- Azure
QUESTIONS & ANSWERS
Questions regarding internal business applications.
Direct answers to common technical and engagement questions.
Frequently you should not, and we will say so. The case for replacing it appears when several people need it at once, when a mistake would be expensive and undetectable, when it needs to connect to another system, or when exactly one person understands it. If none of those apply, a spreadsheet is a reasonable piece of software.
We port the formulas into tested code and run both against the same range of real inputs, comparing results until they agree. Differences are usually informative — they often surface a case the workbook handled incorrectly, which then becomes an explicit decision rather than an inherited bug.
Only if it is at least as fast for the task they do most, which is why data entry gets more design attention than the reporting screens. The common failure in internal applications is a form that is careful, complete, and slower than the thing it replaced. People go back to the spreadsheet, and they are right to.
Usually, and that is often where most of the saving is. The manual copying between a workbook and a finance or resource planning system is both the slowest step and the one where transcription errors enter. Removing it tends to justify the project on its own.
Have something ambitious to build?
Tell us what you're working on. We'll tell you honestly whether we're the right team for it.