Turning a Spreadsheet into an Operations Platform
I turned a spreadsheet-based workflow for legacy clients into a focused internal operations platform that imported existing data, launched in roughly 2–3 weeks, and saved Operations approximately 295 hours of manual entry every month.
The spreadsheet was not the real product. It was an operational bridge for clients still running on legacy systems that had not yet integrated with the newer platform. Operations depended on it because no dedicated workflow application existed. Over time, that workaround became a recurring source of manual entry and maintenance, so Operations asked Engineering for a purpose-built tool.
Operational leverage at a glance
From spreadsheet dependency to a purpose-built operations platform
Before
A spreadsheet carried the workflow
- Legacy-client data
- Manual search
- Repeated entry and updates
- Spreadsheet-based state tracking
After
A focused operations platform
- Import existing spreadsheet data
- Search records
- Update structured fields
- Advance workflow transitions
Delivery path
Discovery to operational use in roughly 2–3 weeks
- 01ListenMeet with Operations and understand the manual bridge.
- 02SketchShape the search, update, field, and transition needs.
- 03PrioritizePartner with Product to move the work into the sprint.
- 04BuildWrite stories and implement the React and Node.js application.
- 05TransitionImport existing spreadsheet data and put the tool into use.
Measured impact
hours saved every month
The savings appeared in the first month of use and continued afterward.
Engineering philosophy
The goal was not to ship the most software. It was to return the most useful time to the people doing the work.
The impact path
Inherited
Clients on legacy systems had not yet integrated with the newer platform, so Operations relied on a spreadsheet-based process to bridge the gap.
Owned
I met with Operations to understand the existing process and sketch the initial workflow requirements.
Changed
I treated Operations as the product user, grounding the solution in how they searched, reviewed, updated, and advanced records through the workflow.
Result
295 hours/month — Manual entry eliminated
What I inherited
The problem and the reality around it
The problem
- Clients on legacy systems had not yet integrated with the newer platform, so Operations relied on a spreadsheet-based process to bridge the gap.
- The spreadsheet had become a recurring operational dependency that required significant manual entry and updates.
- A new tool needed to preserve the existing data and familiar workflow rather than forcing Operations to start over.
The constraints
- The exact legacy fields and edge cases varied across records.
- The current spreadsheet data needed to be ingested into the new application.
- The solution had to be small enough to deliver quickly but structured enough to support search, updates, fields, and workflow transitions.
- Only verified implementation details are included; supporting libraries and the exact number of users are intentionally omitted.
What I owned
My responsibility in the work
I met with Operations to understand the existing process and sketch the initial workflow requirements.
I worked with Product to move the work into the sprint and translated the workflow into implementation-ready user stories.
I implemented the purpose-built internal application from scratch using React and Node.js.
I designed the transition so the application could ingest the existing spreadsheet data and preserve active operational work.
How I approached it
Decisions, tradeoffs, and delivery
I met directly with Operations, sketched the initial requirements, and focused on the work they actually needed to perform: find a record, review it, update structured fields, and move it through a defined transition. I partnered with Product to prioritize the work, wrote the user stories, and implemented the application from scratch using React and Node.js. Just as importantly, I designed the new workflow to ingest the existing spreadsheet data. Operations did not have to abandon active work or manually recreate records in order to adopt the tool.
- I treated Operations as the product user, grounding the solution in how they searched, reviewed, updated, and advanced records through the workflow.
- I replaced repeated spreadsheet handling with a searchable update form containing structured fields and workflow transitions.
- I added spreadsheet ingestion so existing records could move into the new application without manual re-entry.
- I moved the idea from stakeholder conversation to requirements, sprint planning, user stories, implementation, and adoption in approximately 2–3 weeks.
- I measured success through the time returned to Operations rather than through the amount of software shipped.
How I led
The team and stakeholder system
Operations supplied the process knowledge and clarified where the manual burden lived. I translated that understanding into a small, buildable product, worked with Product to fit it into the sprint, and then carried the solution through implementation. The project was intentionally focused: it did not try to solve every future integration problem. It solved the immediate operational problem well enough to be useful within roughly two to three weeks.
Results
What changed
295 hours/month
Manual entry eliminated
Operations saved approximately 295 hours of manual entry in the first month of use and continued realizing that savings each month afterward. · Shared outcome
2–3 weeks
Time to operational use
The focused internal application moved from initial Operations discussions to use in roughly two to three weeks. · My contribution
Existing data
Operational work preserved
The tool ingested the existing spreadsheet data so Operations could move into the new workflow without starting over. · My contribution
Leadership evidence
How I moved the people system
- — I connected an Operations request to a focused product plan rather than treating it as a vague automation ask.
- — I moved fluidly across stakeholder discovery, product prioritization, user-story writing, and hands-on implementation.
- — I defined success in measurable business impact: time returned to the people doing the work.
Technical evidence
How I moved the product system
- — Purpose-built React and Node.js internal application created from scratch.
- — Spreadsheet ingestion that preserved existing operational data.
- — Searchable record-update form with structured fields and workflow transitions.
- — Rapid delivery from discovery to operational use in approximately 2–3 weeks.
Technical footprint
Technologies and system areas
What I took from it
The lesson I carry forward
What I am most proud of is the measurable business impact. In the first month of use, Operations saved approximately 295 hours of manual entry, and that savings continued every month afterward. The project reinforced that valuable engineering is not measured by technical complexity. Sometimes the highest-leverage solution is a focused internal tool that gives people hundreds of hours back to spend on work that actually requires their judgment.
Related work · Automation