The spreadsheet that tracks every wafer batch is one corrupted file from a shutdown
Replacing the critical spreadsheets a Newport operation runs on with proper internal tools costs £25k to £90k over 2 to 6 months. Retool and Airtable get you a long way for simple back-office jobs. They hit a wall when the 'tool' is the master wafer-batch tracker that ten people edit at once, where a fat-fingered cell or a corrupted file can stall a shipment to a fab customer. At that point the spreadsheet is your most important system and your least reliable one.
Every Newport manufacturer has them: the macro-laden workbook that schedules the saw line, the shared sheet that tracks which wafer batch is where, the access database one person built in 2014 that nobody dares touch. They work until they don't. Two people edit the same row, a formula breaks silently, the file hits the size where it takes 40 seconds to save, and suddenly the team that runs a compound-semiconductor line is firefighting a spreadsheet instead of making product.
Retool and Airtable are the obvious next step, and for a simple approvals queue or a small back-office app they are the right answer. But they buckle when you need real-time concurrent editing across a shop floor, validation that physically prevents an impossible state, or integration with test equipment and your ERP (Enterprise Resource Planning). A low-code dashboard on top of a fragile data source just moves the fragility, it doesn't remove it.
The problems nobody warns you about
- The master wafer-batch tracker is a shared spreadsheet that ten people edit live, so concurrent edits silently overwrite each other
- A single corrupted or accidentally deleted file can halt despatch to a fab customer until it's rebuilt from email
- Critical scheduling logic is locked in VBA macros only one departed employee understood
- Retool dashboards sit on the same fragile spreadsheets, so they inherit every data-integrity problem rather than fixing it
The case for owning your internal tools
A purpose-built internal tool replaces the dangerous spreadsheet with a real application: a proper database that enforces valid states, concurrent multi-user editing without overwrites, an audit trail of who changed what, and validation that makes the impossible impossible. For a Newport line that means the wafer tracker can't lose a batch, the saw schedule can't double-book, and the test-data import can't silently drop rows. You build exactly the tool the team already runs the business on, minus the fragility.
Budgeting a internal tools build in Newport
| Project scope | Typical cost | Timeline |
|---|---|---|
| Single spreadsheet replaced by a focused web app | £25k to £45k | 2 to 3 months |
| Multi-user shop-floor tracker with validation and audit | £45k to £70k | 3 to 5 months |
| Suite of internal tools integrated with ERP and test rigs | £70k to £90k+ | 5 to 8 months |
What your build should include
What we build under internal tools in Newport
Everything an internal tools build here can cover: workflow automation, back-office software, operations tooling, approval workflows, internal portal and business process automation.
Exactly what you get
A real application replacing the spreadsheet your line secretly depends on: a proper database, concurrent editing without overwrites, validation that blocks impossible states, and an audit trail for traceability. It imports cleanly from your test rigs, syncs with your ERP and inventory systems, and gives operators, supervisors, and quality the right view each. You get the source, the schema, and the confidence that one stray keystroke can't stop a shipment.
How to choose a developer in Newport
Find a team that asks to see the actual spreadsheet first. The right partner will spot where concurrent edits corrupt data and where logic is trapped in macros, and will plan migration of your messy history into a clean schema. Ask them how they'll prevent an impossible state and what their backup strategy is. A good internal-tools developer is unglamorous and obsessed with data integrity, which is exactly what a fab line needs.
- !They propose another Retool layer on the same fragile spreadsheet; ask how they fix the underlying data integrity
- !No data-migration plan for your spreadsheet history; ask how legacy records move across
- !They skip validation rules; ask how the tool prevents an impossible wafer state
- !No mention of backups or hosting; ask who keeps it running after launch
- !They underestimate concurrency; ask how two operators editing one batch is handled
Most Newport teams pricing internal tools end up comparing notes on custom software, wordpress, accounting too; the systems share one data spine.
Rohan advises mid-market and enterprise teams on ERP, CRM and custom software, and has led delivery on dozens of business-software builds.
Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.
Frequently asked questions
Isn't Retool enough for our internal tools?
For simple back-office apps, yes. But if your tool sits on a fragile shared spreadsheet and needs concurrent editing, hard validation, and integration with test equipment, Retool inherits the underlying data problems. A bespoke tool with a proper database removes the fragility rather than dashboarding over it.
How risky is migrating years of spreadsheet data?
It's the part teams underestimate most. Real spreadsheets carry inconsistent formats, hidden tabs, and broken formulas. A good build budgets explicit time to clean and validate that history into the new schema, and runs the old and new systems in parallel briefly to catch gaps.
Can it stop two operators overwriting the same wafer batch?
Yes. A database-backed tool handles concurrent edits with record locking or conflict resolution, so two people can work simultaneously without silently destroying each other's changes, which is exactly what a shared spreadsheet cannot do.
Who hosts and maintains it?
You do, typically on a small cloud instance with automated backups, maintained via a retainer or in-house developer. That's the trade-off versus a spreadsheet: a little operational overhead in exchange for a tool that doesn't fall over.