From a shared inbox to a product other companies can buy

Project Overview

Always Tile & Stone, now Always Flooring, handled bid invitations through email, contractor portals, Google Drive, and a spreadsheet. Staff reviewed each message, collected the documents, and entered the details before an estimator could assess the work.

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 estimating team received an organized record for review.

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. Other subcontractors could face similar intake work, but this application was built around one company’s processes.

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.

Planning the move from the old application

It was moving a live business onto it while the estimating team continued its work. 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.

Following the cutover, Always Flooring worked entirely in the StruxaOps portal — a tenant on the platform now, rather than the owner of a system only they could use. The old application was retired. 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 shared sign-up, payment, and setup processes.

The cutover plan kept old and new systems running together, moved data in one direction, and retained a recovery option during the transition.

A reusable platform brought new responsibilities: separating customer data, supporting configuration, and managing each company’s onboarding.**