Metro Testing + Engineering

Software overview & direction

The report software: where it stands, where it's going

A look at how the system works today, the three workflow options we weighed, the reasoning behind the one we chose, and what we'd like to build next. Written for both the technical and the non-technical side of the table.

Prepared for
Joseph & Yakub
Prepared by
Saam
Status
Working software + roadmap

Confidential. Metro Testing & Engineering internal document.

The goal we're building toward

It all comes back to one thing. Cut Metro's cost and turnaround time, get reports to clients faster, and let clients see and pull their own reports whenever they want. Everything in this document is judged against that goal, and nothing else.

1
Options weighed

The three versions

We designed and actually built two different engines for this, then settled on one. Here is each one: what it does, who touches a report along the way, and where it is strong or weak.

A · The original flow

One reviewer, fewest steps, fastest to the client
In use now
Technician
Prepare & fill report
Reviewer
Approve & sign
System
Locked signed PDF
Client
Downloads in portal

Two people touch a report before the client has it.

Pros

  • The fastest way to get a report to a client. The fewest hand-offs, so the fewest places it can get stuck.
  • Cheapest to build, run, and train people on.
  • Clients get and view their reports right away, on their own.
  • It is the closest to the lean process a Six Sigma project is actually trying to reach.

Cons

  • Only one approval checkpoint, so one quality gate.
  • It does not show the lab's internal departments on screen.
  • Less detail on exactly who did what and when than the full pipeline gives.

B · Yakub's version, the full deployment workflow

Mirrors the Functional Deployment Diagram, two quality gates
More steps
Client
Requests testing
Coordinator
Create & schedule
Dispatcher
Assign technician
Field tech
Collect samples
Laboratory
Run the test
Gate 1
Lab supervisor
Approve lab data
Engineer
Write report
Report coord.
Technical review
Gate 2
Quality mgr
Final sign-off
Client
Downloads in portal

Up to nine people touch a report before the client has it. Scroll to see the whole chain.

Pros

  • It mirrors how Metro actually works today, so the screen matches the real process.
  • Two separate quality checks, the lab data first and then the final report, which is strong protection for engineering liability.
  • It records a timestamp at every hand-off, which gives precise accountability and the lead-time data a Six Sigma project needs.

Cons

  • Slower to the client. Every stage is a spot where the report sits waiting for the next person to act.
  • More to build and keep running, and more people who have to log in and do their part.
  • More training and more change for staff to get used to.
  • It risks locking in the current slowness that the project is meant to remove.

C · Where we landed

We built B, compared it to A, and went back to A
= Version A

The software you have right now is Version A. We fully built the Version B engine, tested it end to end, then put the two side by side against the goal and went back to the lean flow. We kept the code cleanups that came out of building B. The next part explains the reasoning.

2
The decision

Side by side, and the call

Here is the fact that matters most. A client cannot tell the two apart. Same portal, same signed PDF. Everything that is different happens inside Metro, in how many people touch a report first.

 A · Original (in use)B · Full workflow
Steps before the client2 touchpointsUp to 9 touchpoints
Speed to clientFastest, few places to stallSlower, waits at each stage
Cost to build, run, trainLowHigh
Client experiencePortal, self-serveIdentical, same portal
Quality gatesOne approvalTwo, data then final
Accountability & KPI dataAudit log of key eventsTimestamp at every stage
Best when the goal is…Speed, cost, client accessMaximum QC and rigor

The recommendation

For the goal Metro set, which is less money, less time, and clients getting and seeing their reports, Version A wins, and the client never notices the difference. The extra seven stages in Version B buy internal rigor, not speed, and that is a different goal.

There is one idea from B worth keeping in our back pocket. If liability ever calls for it, we can add a single final sign-off to the fast flow later, without rebuilding the whole nine-stage pipeline.

3
For Joseph

Under the hood

This is the stack the prototype runs on today, and the thinking behind each choice. On the left is the piece in plain terms, on the right is what it is technically.

Read this first: the backend here is a prototype

Everything in this section is how the prototype is put together right now. Once Metro decides where this actually lives, whether it goes onto MTRS or somewhere else, the backend can change. In particular, bringing each client's old records across from MTRS into this software, so clients can see their historical data too, will shape a lot of these choices. So please treat the stack below as the prototype foundation we are testing with, not the final production setup.

The app
Framework
One codebase runs both the pages people see and the logic behind them.
Next.js 16 · React · TypeScript · server actions for writes
The database
Data store
All reports, users, and clients live in one database on Canadian infrastructure, so the lab data never leaves the country or goes to a third-party cloud.
PostgreSQL 16 · self-hosted · Prisma 7 ORM
Login
Authentication
Everyone signs in with their own Metro email and password, on Metro's own system rather than Microsoft. Passwords are stored scrambled so even Metro cannot read them.
Better Auth · argon2id password hashing · session cookies
Data isolation
Security
A client can only ever see their own approved reports. That rule lives in the database itself, so a mistake in the app cannot get around it.
PostgreSQL Row-Level Security (RLS) · per-request identity context · restricted DB role
Report & PDF
Output
Approved reports become a locked, official PDF that cannot be edited, with an automatic file name and full revision history.
Puppeteer render · qpdf read-only lock · versioned revisions retained
Signatures
Sign-off
Reviewers draw their signature once, and it gets re-applied automatically on every approval and stamped into the PDF.
Captured signature image · snapshotted onto the revision at approval

A note on hosting: in production this lives within MTRS

For the prototype, the data sits on its own self-hosted database in Canada. In the real deployment, all of it, the reports, the clients, and their history, will live within MTRS on Metro's own infrastructure, handled the same way Metro already handles the rest of its systems. What carries over either way is the principle behind it. The rule about who can see what should be enforced at the data layer, the strongest place to put it, rather than left to the app to remember, wherever the data ends up living.

4
Roadmap

What’s next

Three things on the roadmap. Each one has a clear idea behind it, and each one is still early. They need more planning and some input from your side before we build.

Invoicing

Early stage, design only
In plain terms

Right now, billing a client means someone goes through every one of that client's reports for the month by hand, works out which test each one is, tallies them up, and applies that client's agreed prices. That takes about two weeks, so invoices go out on the 15th instead of the 1st.

The idea is that each client's monthly reports bundle up on their own, and one click produces an itemized invoice at that client's prices. The invoicing team checks it, emails the official invoice, and a read-only copy stays in the client's portal. No payments run through it. It is a document, not a checkout.

Technical & theory

A per-client rate card sets the price for each test type, controlled by an admin, and every report inherits its client's price. An invoice is simply an automatic pull of that client's issued reports for a month. The prices get frozen onto the invoice at the moment it is generated, so a later price change never re-prices an old invoice. It is the same idea as locking a report once it is signed.

To build it: a few new Postgres tables, the same TypeScript on the server, the same data isolation as the reports, and the existing PDF pipeline reused. The backend details may shift once we know where this lives.

  1. An admin sets each client's rate card, meaning their price per test.
  2. Reports pick up their client's price as they are issued.
  3. At month end, the system gathers that client's issued reports into one invoice.
  4. The prices freeze onto the invoice, the team checks it, emails it, and files a copy in the portal.

Where it stands: we have a solid design, but it is not built yet. Before building, I would need to sit down with the invoicing department directly to understand how the process truly works today, since they are the ones who know the real details the design has to match. Still to sort out with Metro: which date decides a report's billing month, whether the invoice needs to show tax such as GST and PST, and the real data source, since most reports live on MTRS today rather than in this app. That last one is the real dependency to figure out first.

A downloadable app, not just a website

Early stage, idea & structure only
In plain terms

Navid raised this one, and it is a good one. The software does not have to stay a website only. We can also offer it as an app people download onto their phone or tablet.

There are two reasons it is worth doing. First, it is another way to market Metro. Second, and bigger, it helps technicians out in the field. They can punch in their test results and take photos right there on the spot, instead of driving back to the office or going home to type up their reports later. That gets results in faster and saves real time for the techs.

Technical & theory

At this point this is just the idea and the shape of it, nothing is built. The same app can be delivered to phones and tablets alongside the website, with an on-site mode for entering results and capturing photos.

How the backend handles this, syncing, offline capture, storage, is a conversation for later. For now it is theory and structure, with no backend behind it yet.

Where it stands: concept only, based on what Navid walked me through. Worth planning properly once the core is settled.

Client test-recommendation assistant

Early stage, concept
In plain terms

Most clients do not know which test they actually need. They know the problem, for example the city wants durability proof for a slab, but not that it maps to a specific ASTM or CSA test. Today that is a phone call to an engineer.

The idea is a guided assistant inside the portal. A client describes their situation in plain words, and it recommends the right test or tests and points them to the right engineer. Faster for the client, less phone time for Metro, and it catches prospects who might otherwise drift away.

Technical & theory

The assistant has to be grounded in real requirements, not in the model's guesses. For it to recommend accurately, its memory needs the actual requirements behind each test, taken from the bodies that set them. So we read and pull the requirements out of the governing documents, then store them as something the assistant can search.

When a client asks, the assistant looks up the real requirement first and then answers, so every recommendation traces back to an actual spec. Because Metro carries liability, answers are framed as a suggestion that a Metro engineer confirms, and a person always stays in the loop.

  1. Collect the governing requirement documents and Metro's own list of tests.
  2. Read them and pull out each test's requirements and the situations that call for it, into a knowledge base.
  3. A client describes their project, and the assistant matches it to the real requirement and recommends the test.
  4. It points them to the right engineer and flags Metro to follow up, and the engineer confirms before anything is final.

Where it stands: concept and approach only, not built. It depends on getting the source requirement documents and the engineers' sense of which situation calls for which test. Accuracy is everything here, since a wrong recommendation on a structural decision is a real risk, which is exactly why it has to be built on the real requirements and not left to guess.

All three of these are early stages

The thinking is sound and the designs are real, but none of the three is built, and each one needs more planning and specific input from Metro before we commit to building. The next section lays out exactly what we need to get moving.

5
To get moving

What we need to move forward

Two concrete things would unblock the next stretch of work, one for each of you.

For YakubThe rest of the report templates

To build out more tests, I need the report templates, and for each one I need three things spelled out. Where the user types in their values, meaning the input fields. The formulas, for the reports that calculate a result. And the pass or fail limits, the constraints, so the system can flag when a value falls outside them and warn that something is wrong with that report.

The HAV and RCP reports are the model here. I have already shared RCP-REF.xls and HAV REF.xlsx in previous emails, so the same format works: the cells highlighted in yellow are the user input. That is exactly what I need marked on the rest.

I know there are a lot of these, so if either of you finds a faster or easier way to get them shared, Joseph especially, please let us know. And ideally the most commonly used and most active tests first, so we can do a test run with real historical data behind it and see how the software actually performs, the way we talked about in the meeting. If sending them all at once is too much, the active ones are the priority.

For JosephAccess to the MOT files and booklets

Once we start on the assistant, I need access to the MOT files and booklets. Those are what tell me the requirements behind each test, so I can turn them into a set of requirements the assistant checks against when a client describes their situation.

This is the route Yakub and I landed on in our meeting. If there is a better source than MOT for those test requirements, let me know, since MOT is just what the two of us came up with.