CASE STUDY · LOW-CODE / NO-CODE PLATFORM DEVELOPMENT
Building a no-code internal tools platform that replaced 12 spreadsheets.
- 1212 spreadsheets retired
- 60%Data-entry errors down about 60%
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market B2B services company. Name withheld under confidentiality.
An internal app with roles, approvals and an audit trail. Staff enter work once. Managers approve in the app instead of by email. Finance sees the same data without asking for a copy of the file.
- 1Operations ran across 12 spreadsheets.
- 2Each one had an owner, a few hidden tabs and its own habits.
- 3Job intake, scheduling, approvals and billing prep all passed through them, copied by hand from one file to the next.
- 4Nobody could say which sheet was current.
- 5Mistakes surfaced late, usually when a customer complained.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01During the parallel run, totals in the new app did not match the old sheets
The cause was not a bug. Two team leads had been applying an unwritten rounding and adjustment rule in their own files. We sat with them, wrote the rule down, got it approved by the sponsor and built it into the app.
- PROBLEM 02After that we added a reconciliation report so any future mismatch would be visible straight away
- PROBLEM 03A second problem came after go-live
Some staff kept a private copy of their old sheet "just in case", and a few edited it instead of the app. We did not argue. We asked why.
- PROBLEM 04They did not trust that a change would save, because the first version gave no confirmation
We added clear save messages and a visible "last changed by" line on each record. We then asked team leads to stop accepting data from private sheets, and the copies faded within a few weeks.
03 · THE PROCESS
How we ran it.
- 01Discovery, first two weeks
we interviewed the people who owned each sheet and traced how data moved between them. We found duplicated fields, undocumented rules and several sheets that only existed to fix another sheet.
- 02Build, in weekly cycles
a demo every Friday with the operations team. Each cycle added one area: intake, then approvals, then reporting.
- 03Parallel run
the old sheets and the new app ran together for a short period while we reconciled the data.
- 04Cut-over
sheets were locked to read-only one by one, not all at once.
- 05Step 5
We met the sponsor weekly and kept a short change log everyone could read.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
New requests go into the app, not into someone's file. There is no longer a "my version" of the data.
- NOW 02
Approvals happen in one place, and the history is there when an auditor or a customer asks.
- NOW 03
Changes to rules go through a named owner and a short review, rather than a quiet edit to a formula.
- NOW 04
The operations team can request small changes and see them released in days.
- 12
12 spreadsheets retired
- 60%
Data-entry errors down about 60%
05 · WHAT WE BUILT
How it works.
- A low-code platform chosen for its role model, audit features and ability to connect to the company's database.
- A single data model replacing the overlapping sheet structures, with validation at the point of entry.
- Role-based access: staff, team leads, finance and admins each see only what they need.
- Approval flows defined as configuration, with every state change logged with user and time.
- Single sign-on through the company's identity provider, and separate test and production environments.
- Scheduled exports so finance could keep their reporting routines during the transition.
- Handover and controls
- We wrote a short admin guide covering roles, approval rules and how to add a field. Two people from operations were trained as platform admins, so everyday changes did not depend on us. We set up a monthly review of user access, and an alert when an approval sat untouched for too long. Finance kept a read-only export for month end. Support from us moved to an as-needed basis once the first quarter closed without a reconciliation dispute.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- Operations ran across 12 spreadsheets. Each one had an owner, a few hidden tabs and its own habits. Job intake, scheduling, approvals and billing prep all passed through them, copied by hand from one file to the next. Nobody could say which sheet was current. Mistakes surfaced late, usually when a customer complained. Managers had no record of who changed or approved anything.
- What did Brandsmashers build?
- An internal app with roles, approvals and an audit trail. Staff enter work once. Managers approve in the app instead of by email. Finance sees the same data without asking for a copy of the file.
- What were the results?
- 12 spreadsheets retired; data-entry errors down about 60%.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
