Most warehouses don't have one broken system. They have forty small ones: a spreadsheet for consumables, an inbox rule for arrival reports, a clipboard for equipment checkout, a person who knows which box is empty. None of it talks. All of it is load-bearing.
Built for a contract-logistics operation running a returns and reverse-logistics program for a single large customer.
One module at a time, on a platform built to take the next one cheaply. A single Flask and SQL Server application replaced spreadsheets, inbox rules and clipboards; each capability is a self-contained module registered in the database and grantable at once, and each old system retired on the day its module shipped, with no cutover day.
The site was profitable and the operation worked, which is exactly why nobody had ever stopped to fix it. Every department had built its own workaround over the years. The warehouse system held inventory but couldn't answer operational questions, so the answers lived in spreadsheets on individual laptops. Getting them out meant spreadsheets moved onto a real database, one department at a time.
That pattern has a predictable failure mode: the work is fine until the person who owns the spreadsheet takes a week off.
A single web application the whole site logs into, with role-based access down to the individual screen. Fifty-odd operational pages sit on top of a shared services layer, and a scheduler runs the recurring work that used to be somebody's morning routine. It belongs to the family of internal tools that replace the spreadsheet a company depends on, at the scale of a whole site.
The architectural decision that mattered most was making the platform extensible without redeployment planning. New capability is added as a self-contained module and registered in the database; it becomes callable and grantable immediately. That is why the system grew to cover the whole floor instead of stalling at version one — shipping the eightieth feature costs about what the eighth did.
| What the floor ran on | What it carried | Module that replaced it |
|---|---|---|
| A spreadsheet | Consumables | Consumables |
| An inbox rule | Arrival reports, re-keyed by hand | Arrivals |
| A clipboard | Equipment checkout | Equipment |
| A survey tool | Audits, with no reporting | Audits |
| One person's routine | Recurring work | Scheduled jobs |
An internal tool that everyone depends on is production software, whether or not anyone calls it that. It was built accordingly.
Background automations coordinate through database-level leader election, so exactly one process in the fleet runs each scheduled job no matter how many servers are online. Every request is timed and recorded, because measuring response times before changing anything beats guessing. Console output from anywhere in the codebase is captured, levelled and streamed to an operator screen — which is the difference between diagnosing a floor problem in minutes and asking someone to reproduce it.
The operation runs on one system that its own users extend. Work that lived in individual routines is now scheduled, logged and visible. When something breaks, there is a screen that says so. That is what spreadsheets turned into real systems looks like from the floor.
The honest lesson from this build is that the hard part was never any single feature. It was making the fortieth feature as cheap to add as the fourth.
Through database-level leader election. The background automations coordinate in the database, so exactly one process in the fleet runs each scheduled job no matter how many servers are online. Every request is timed and recorded, and a safe mode boots the application with every automation disabled.
Because the two together say what a typical request and the slowest ones take, which an average blurs into one number. The platform reports latency as median and 95th percentile, never as an average, measures human page views separately from background traffic, and keeps client errors apart from server errors, so a 404 is never read as an outage.
Yes. New capability is added as a self-contained module and registered in the database, which makes it callable and grantable immediately, with role-based access down to the individual screen. That is why the platform grew to cover the whole floor instead of stalling at version one: shipping the eightieth feature costs about what the eighth did.
Client, location, system names and volumes are withheld deliberately. We're happy to go deeper on architecture and approach on a call.
Bring decades-old systems into the modern era without a risky rip-and-replace.
See Legacy Modernization & Migrations →Connect aging systems to modern APIs, data platforms, and SaaS tools.
See System Integration →The Do-Engine is the operations app we built to run our own business: a task board, a client book, a document vault, invoicing, a help desk and a mail client in one page, with a single XP ledger scoring everything that gets finished.
Read the story →A damage or count discrepancy is a claim, and a claim is worth whatever evidence is attached to it. We built the casework — photo capture at the point of discovery, a case that assigns and escalates itself, and a PDF report that goes out with the pictures already in it.
Read the story →Internal software requests arrived by email and were approved in conversation. We built an intake form, a board and a three-role approval gate where the votes move the card — and gave requesters a private link so they can follow and edit their own request without an account.
Read the story →List the spreadsheets, inbox rules and clipboards the floor runs on. Free assessment.
Call 832-598-8234 or email msco@stoneagesoftware.com. Houston, Texas — serving Houston, The Woodlands, Conroe, Sugar Land, Katy, Pearland, and the Greater Houston metro.
We read your message, an engineer replies with questions or a straight answer, and if a call would help, we book one. From the first reply on, you're talking to the people who'd do the work.
