The company runs on a file that one person knows how to use.
A spreadsheet that grew into a system is not a mistake — it is how most real processes start. It becomes a problem the day the business cannot afford to lose it.
Does this sound familiar?
- The file takes a minute to open, and everyone has learned to wait.
- Two people edit it, and you keep finding versions that disagree.
- Someone rebuilds the same report by hand every single month.
- There is no history — you cannot tell who changed a number, or when.
- When that person is on holiday, part of the business waits for them.
How we approach it
01 — Read
Treat the spreadsheet as source code
Because it is. The formulas carry years of business rules that were never written down anywhere else. We extract them before we design anything.
02 — Model
Give the data a real structure
A proper database, with the constraints a spreadsheet could never enforce. This is where the duplicate customers and impossible dates stop being possible.
03 — Build
An interface around the actual work
Designed around what people do every day, not around the shape of the tables. If it is slower than the spreadsheet, nobody will use it.
04 — Switch
Both run until the numbers match
The spreadsheet stays alive in parallel. Only when the two agree, month after month, does it get retired.
What you get
- The business rules that were hidden in the formulas, written down.
- A modelled database, with the validation the file never had.
- The application in production, built around how people work.
- History and audit — who changed what, and when.
- Reports generated instead of rebuilt by hand.
Technologies
Bradesco
Scattered reporting turned into a 200-table data warehouse and a BI system built from nothing.
Read the case →Tell us what you are trying to fix.
A tangled integration, a slow database, a system nobody understands any more. The first conversation is 30 minutes and costs nothing.