What Drives the Cost of Turning a Spreadsheet into a Custom Internal Tool

Five things decide most of the budget for a custom internal tool. The number of rows in the spreadsheet is not one of them. A database handles fifty thousand records as easily as five hundred. What costs time is the behavior wrapped around those records.

How many roles need a different view

A workbook shows everyone everything. A real application decides who sees which records and who can change them. One role with full access is simple. Seven role types, each with its own screens and data scope, is a different build. We treat roles as architecture, not a settings screen, because retrofitting access rules later is where projects get expensive.

How much logic is hiding in the workbook

The visible columns are the easy part. The cost lives in nested formulas, macros, lookup tabs, and the manual steps someone does every Monday before the numbers are right. Every one of those has to be found, named, and turned into a rule the application enforces. A clean workbook with documented logic moves fast. A ten-year-old workbook with three authors takes longer to read than to rebuild.

Integrations

If the spreadsheet is fed by copy and paste from other systems, the new tool can either keep a manual import or connect to those systems directly. Each connection to an ERP, CRM, accounting system, or data warehouse adds design, testing, and long-term maintenance. Starting with imports and adding integrations later is often the cheaper path, and it lets you see which connections actually save time before paying for them.

Audit and history requirements

Some teams only need the current numbers. Others need to know who changed a record, what it was before, and why. Change logs, notes on edits, and recoverable snapshots are standard in the tools we build, but how deep that history goes is a real scope decision. A note field on each edit is light. A full point-in-time view of every record for auditors is not.

What the tool has to produce

Screens are one thing. Generated PDFs, branded documents, exports, scheduled reports, and a second tool for field staff or customers on the same data all add scope. They are also often where the biggest time savings come from, so they deserve a line in the budget rather than a cut.

A spreadsheet replacement follows the same process as any application we build, with a few steps that matter more here. It mirrors how we run operations software engagements.

Map the objects

We start by putting the spreadsheets on the table and naming what is actually being tracked: products, accounts, forecasts, contracts, locations. That becomes the data model. Most of the surprises, and most of the cost risk, surface here, which is why it comes first.

Decide the roles before the screens

Who enters data, who approves it, who only reads it, and who should never see it. Settling this early keeps the build from being reworked later, because every screen and every query depends on the answer.

Ship working software in slices

People use real screens early, in short sprint cycles, instead of waiting for a big reveal. Each phase starts only after you have signed off on the one before, and scope changes are written down before any extra work begins. That is how the budget stays a budget.

Keep the spreadsheet running until the new tool matches it

The workbook does not get switched off on day one. The team keeps using it while the new tool is checked against its numbers, and the cutover happens when the two agree. Nobody has to trust the new system on faith.

The code. Our internal tools are built on a conventional React and TypeScript stack, documented on our tech stack page, so any capable engineer can pick it up. You get the repository, types, and runbooks. From there you choose a full handoff to your own team, or an ongoing release cadence with us.

We plan every tool for a five-year horizon, because a system of record should outlast the people who first asked for it. That shapes decisions you never see in a demo: how the data model handles a new product line, how roles extend when the team grows, and how the next developer finds their way around.

“A system of record should outlast the people who first asked for it.”

Off-the-shelf software is worth checking first. If it fits your process without bending it, buy it. Low-code platforms are cheaper in year one, and for a small, short-lived tool they are often the right call.

For a core tool used by more than a few dozen people over several years, per-seat licensing tends to add up to more than a custom build, and you never own the result. We walk through the full math in Custom Web Apps vs Low-Code Platforms: A 5-Year TCO Comparison.

Alcon: from an hour-long recalculation to seconds

Alcon’s internal sales teams forecast revenue in large shared Excel workbooks, where a single change could take 30 to 60 minutes to process. Working with Alcon’s data science team, we moved the models into a structured database behind a role-scoped web application. Each person sees only their own data, can update estimates with a note explaining the change, and can generate forecasts up to five years out on demand.

What once meant waiting an hour for a shared file to recalculate now happens in seconds. Read the Alcon case study.

MJEC: one system for 125+ manufacturer lines

MJEC, a Texas manufacturers’ representative, tracked more than 125 manufacturers and partners across spreadsheets and disconnected tools, and every brochure meant a request to marketing and a multi-day wait. We built an internal app for the records, with an audit log of every edit and rolling seven-day snapshots, plus a public directory that generates branded PDF brochures from live data.

Field staff now produce a brochure in seconds. MJEC and our team still review usage and ship improvements every quarter. Read the MJEC case study.

If one person uses it, the stakes are low, and the logic rarely changes, keep the spreadsheet. A custom tool earns its cost when several people depend on the same data, when mistakes are expensive, or when the process has become part of how the business makes money.

If your process is the product, build. If it is not, spend the money elsewhere.

Can we keep using Excel while you build?

Yes. The spreadsheet stays in use until the new tool has been checked against it, and the cutover happens once the numbers agree.

Do we need our own developers after launch?

No. You can hand the tool to an in-house team, since it is built on a stack they can hire for, or keep shipping improvements with us on a regular release cadence.

Can the same data power a tool for field staff or customers?

Yes. MJEC’s public directory and brochure tool run on the same database and access layer as the internal app.

How do you scope it?

It starts with a conversation and the spreadsheet itself. We scope quickly after that first call, then turn the requirements into a written design and a prioritized backlog before any sprint starts. You can get a head start with our project blueprint.