From a shared inbox to a product other companies can buy

Project Overview

Before any of this, there was an inbox. Always Tile & Stone — now Always Flooring — ran their bidding by hand. Someone opened every email, worked out whether it was a genuine invitation to bid, downloaded the plans from whichever contractor portal had sent them, filed them into the right Drive folder and typed the job into a spreadsheet. Then they did it again for the next one. The work was not difficult. It was endless, and a missed email was a missed bid.

So we built them a system that did it for them. It read the incoming mail, told real bid invitations from noise, created the project folder, fetched the plans, assigned an estimator and kept the bid board current without anyone typing a row. The spreadsheets stopped being the system of record. The team got their hours back.

That system did exactly one job for exactly one company. It knew their inbox, their folder names, the way they named a job. Which was fine — until the client said out loud what we had been thinking. Every other flooring and specialty subcontractor in the country runs the same daily grind. Not one of them could use a line of it.

So, at their request, we built it a second time — as a product.

StruxaOps is that same intelligence, redesigned so any subcontractor can sign up and use it. The bid inbox, the project folders, the estimating and proposal tools, the follow-ups — all of it now serves many companies at once, each with their own data, their own storage and their own settings, kept firmly apart.

The hard part was never the new platform

It was moving a live business onto it without interrupting a single working day. So there was no big-bang switch-over. There were four steps, in this order, and the order was the whole point.

Run both, quietly

Every bid the old system created copied itself into the new one — same statuses, same estimators, and the existing folders reused rather than recreated. Information moved in one direction only, so there was never a question of which system was right.

Move the work across

Once the records matched, the day-to-day automations moved over one at a time — status changes, notifications, follow-ups, proposals. Each was proven in its new home before being switched off in the old one.

Cut over on an agreed date

The old system stopped watching the inbox and StruxaOps picked it up, with everyone told well in advance exactly when it would happen.

Freeze, then retire

The legacy application was locked to read-only and kept as a safety net for an agreed window — then shut down for good.

Today Always Flooring works entirely in the StruxaOps portal — a tenant on the platform now, rather than the owner of a system only they could use. Their old application is switched off. The manual routine that started all this is two systems behind them. And what began as one company’s internal tool is now something other subcontractors are being onboarded to, with sign-up, payment and setup taking minutes instead of a months-long custom build.

Having built every stage of it ourselves, this is the part we would pass on. In a legacy migration the rewrite is rarely the risk; the cutover is. You survive it by running old and new side by side until it is boring, keeping the data moving one way, and always leaving yourself a way back.

Built for one customer, software is a cost. Built to be shared, it is a business.