When Spreadsheets Stop Working: How to Replace Excel with a Custom Internal Tool

Excel and Google Sheets are fast, flexible, familiar, and often the right place to prove a process. A spreadsheet can capture a new workflow before an organization understands it well enough to specify software. Its formulas may hold years of hard-won business logic, exceptions, and reporting needs.

The workbook is not the mistake. It may be the clearest record of what users need. The problem starts when that useful model becomes a permanent multi-user application without the database, access controls, interface, audit history, or performance the process now requires. Replace the operating model, not the useful logic.

“The spreadsheet is not the mistake. Treating it as a permanent multi-user application is.”

A small, low-risk workbook does not need to become software. The line is crossed when concurrency, permissions, auditability, or business continuity become requirements. These are the signs we look for first.

1. Nobody can identify the current version. Copies live in email, shared drives, personal folders, or separate departmental workbooks.
2. One person’s update blocks everyone else. Recalculation, locked files, imports, or manual synchronization delay the next user.
3. The same data is entered more than once. People copy records across sheets and eventually create conflicts.
4. Access control depends on files and tabs. The organization cannot reliably limit records or fields by user, role, team, or region.
5. Reporting requires another manual process. Teams rebuild charts, presentations, or summaries from stale exports.
6. The process fails away from a desktop. Dense workbooks are difficult to use on phones and tablets.
7. There is no dependable history. It is hard to answer who changed a value, what it was before, or how to recover from a bad edit.

Splitting one workbook into several reduces file size but creates more synchronization work. Moving the files to a different shared drive does not create a single source of truth. More formulas and macros concentrate knowledge in one or two people. A dashboard connected to periodic exports may improve presentation while leaving the underlying workflow unchanged. Hidden tabs and separate files are not role-based access control.

You do not need to arrive with a polished software specification. The existing workbook is a useful starting point. We review the files and, more importantly, talk to the people who open them every day. Their shortcuts, exceptions, and workarounds reveal requirements that leadership may not know exist.

• Sheets, files, shared drives, and duplicate data
• Inputs, outputs, formulas, macros, and external references
• People who create, review, approve, and consume the data
• Roles, regions, departments, and record-level access rules
• Reports, charts, exports, and presentation requirements
• Integrations with a CRM, ERP, identity provider, or data warehouse
• Calculation time, update frequency, error rate, and other baseline measures

The first goal is not a generic dashboard. It is to identify the actual objects and decisions in the process: a product, territory, forecast version, employee, benefit election, contract date, or approval. That is where internal tools and dashboards work starts.

A good replacement preserves what the workbook proved and moves each part to the place it can work reliably. The data becomes a structured source of truth. Calculations become tested business rules. Roles become enforced authorization. Forms, tables, charts, and mobile screens let each person do the work without exposing every formula and every cell.

• One structured source of truth. Products, employees, forecasts, notes, history, and relationships live in a database designed for the data.
• Real-time updates where the workflow needs them. An authorized user saves a valid change once, and the people allowed to see it work from current data rather than waiting on a file refresh.
• Role-scoped interfaces. Employees, managers, finance, HR, and leadership get screens and records appropriate to their work.
• Reporting built into the process. Current data feeds interactive charts, scenario comparisons, filters, and exports without rebuilding a presentation.
• History and recovery. Change logs, notes, timestamps, and recoverable state make mistakes traceable and reversible.

The application stays browser-based, so the same workflow can be responsive on phones and tablets without a separate native build. That matters for field and leadership teams who need a number or approval now, not when they are back at a desk. See Mobile Web & Responsive for how we approach that surface.

Alcon needed an internal revenue forecasting system for sales teams working with products, sales history, revenue models, market data, and five-year projections. The existing shared Excel workbooks were not merely inconvenient. One change could require 30 to 60 minutes to process across users.

We worked alongside Alcon’s data science team to preserve and formalize the forecasting logic. Products, historical sales, revenue models, and market data moved into PostgreSQL. Staff received role-scoped views of their own data, could update estimated sales, attach notes explaining a change, and generate forecasts on demand.

The result is a current, purpose-built system. Work that once waited on an Excel recalculation happens in seconds. Interactive charts turn multi-year projection curves and scenario comparisons into a usable decision surface. Read the full Alcon revenue forecasting case study.

Slow calculations are only one reason a workbook process stops scaling. Rees-Jones Holdings came to us with compensation and benefits data spread across multiple spreadsheet workflows. The team needed a better presentation layer and a reliable way to limit sensitive data for different people.

We condensed those workflows into a user-friendly application backed by a real-time database. Employees, managers, directors, executives, HR, C-suite, and IT receive different interfaces and data scopes. Live dashboards and charts present annual compensation and benefits data clearly, while the access rules live in the application instead of in hidden tabs and separate files.

The platform supports more than 150 employee logins and continues to evolve in phases. That is the important shift: one current data source can keep improving without adding another spreadsheet to the process. This is a common pattern in operations software for forecasting teams, field organizations, and professional firms.

Custom software should not force people into an unfamiliar process just because a generic admin template happens to have the right widgets. The job is to preserve the useful parts of the system and remove the places where the tool gets in the way.

• Preserve proven calculations and the domain language the team already uses
• Keep familiar table-based views where they remain the fastest way to work
• Import historical records and validate totals before launch
• Retain exports for finance, auditors, partners, or downstream systems
• Add guardrails where they prevent errors or protect sensitive data
• Improve the workflow in stages instead of redesigning every step at once

MJEC is a useful example of what that ownership looks like after launch. Its internal application centralizes manufacturer records, notes, documents, contract dates, and sales data, with a change history and recoverable database snapshots. The same source powers a field tool that generates live-data PDFs. The platform continues on a quarterly review and release cadence.

For larger organizations, the replacement may need SSO, audit-log surfaces, CRM or ERP integrations, and a documented handoff to the internal team. Those are the concerns addressed through Enterprise Web Development.

Not every workbook needs a custom application. Keep the spreadsheet when one or two people use it, the data is low-risk, calculations are fast, updates are infrequent, and the process is still changing too quickly to model. A manual report can be perfectly reasonable when the stakes are low.

Consider a custom internal tool when the process is business-critical, many people need simultaneous access, different users must see different data, errors or stale copies have a measurable cost, or the workflow needs audit history and integrations for years to come.

A typical engagement begins with workflow discovery, data and role mapping, and a prototype of the critical job. We then build in working slices, validate calculations and migration against the existing system, and give the client the repository, infrastructure access, documentation, and an optional ongoing release cadence.