Why the record is a database, not a folder of spreadsheets

The job folder was fourteen files. Estimate, SOV, the GC's billing template, the change log, three versions of the budget, timecards by week, and a tab somewhere called rates DO NOT EDIT. Every number on the job was in there. Most of them were in there twice. I've run work out of that folder and I'm not going to tell you it doesn't work — it works right up until the week you're too busy to keep the copies in agreement, and that's always the week something is due. STrOp keeps the record in a relational database instead. Here's what that word means and what it buys you, in jobsite terms.

"Relational," in one paragraph

A database is a set of tables, and each table holds one kind of thing: jobs, workers, cost codes, timecards, change orders. Every row has an ID, and when one row needs another, it carries that ID — a timecard points at a worker, a job, and a cost code by ID, not by name. That pointer is the relation. It's the difference between a spreadsheet that says J. Serrano in column C and a record that is Serrano's, wherever his name shows up. Everything below falls out of that one idea.

One fact, one place

The contract value on a job is a single number, and in a spreadsheet shop it lives in the estimate, the SOV, the proposal, the budget tab, and the G703 template the GC sent you. Change it in four of the five and the fifth is the one AP catches on the 25th. In a database the number lives once. The pay app builds from the SOV; the budget reads approved timecards and received POs; the certified payroll run reads the same timecards. Nothing is copied between tabs, because there are no tabs. When a number is wrong it is wrong in one place, and you fix it there.

Links you can't mistype

A spreadsheet relates things by whatever you typed. Spell a cost code 09-250 on one sheet and 09250 on the next and that labor just left the job cost — no error, no flag, a budget that reads healthy and isn't. A database refuses the row. A timecard can't point at a worker who doesn't exist, a change order can't attach to a job that isn't there, and when you bring a file in from the old system, a name that doesn't match an existing record stops at the review step and asks you, instead of landing quietly with a dropped link.

A lock that holds for everyone

Every shop has a DO NOT EDIT tab, and every shop has a story about who edited it. A spreadsheet lock is a request. In STrOp a locked baseline, an approved estimate, and a signed lien waiver are locked by the database itself — the rule sits under the app, not in it, so it holds for the PM, the admin, a bulk import, and for us. Unlocking is a deliberate act by someone with the role to do it, and it's recorded. The estimate you bid stays the estimate you bid.

Who changed what, and when

budget_FINAL_v3_real.xlsx is a version history. It just isn't a good one. Every write in STrOp — an approval, an edit, a status change, a role change — is recorded with who, when, and the before and after of each field that moved, and an org admin reads it under Settings → Audit Log. When a number looks wrong in March, "who changed this and when" takes a minute, not a hunt through email attachments for whoever's laptop has the newest copy.

Everyone in it at once, each seeing their side

A foreman on a phone at 6:40, a PM in the trailer, a controller at her desk: three people, three devices, one record, the same second. A shared spreadsheet either locks the second person out or forks into two files that someone merges later by eye. And a spreadsheet is all-or-nothing — send the file and you've sent the billing, the rates, and everyone's pay along with it. The database shows each role its own side of the same shop: Serrano's phone shows Tuesday, not your margin, and the bookkeeper sees billing without the field's notes. One record, drawn from different sides.

The question you haven't asked yet

A spreadsheet answers the question it was built for. Your bid sheet knows this job's cost per square foot; it doesn't know your cost per square foot across the last nine jobs, by GC, by building type, with and without the change orders. Those nine jobs were nine folders. Because every timecard in STrOp carries a worker, a job, a cost code, and the quantity installed, the shop's productivity rates are a query, not a project — and the rate your estimator pulls on the next bid comes from what your crews actually did on the last one. The record compounds. A folder of spreadsheets starts over on every job.

Backed up, walled off, and not on a laptop

The record lives in Postgres, encrypted at rest and in transit, backed up on a schedule that isn't anyone's Friday chore. Every row carries the ID of the organization it belongs to, and the database itself enforces that line — your data is walled off from every other company's underneath the app, not by the app remembering to filter. A spreadsheet is as safe as the laptop it's on and as current as the last email it was attached to.

What spreadsheets are still for

I still think in spreadsheets. So does every estimator and controller I know, and STrOp isn't going to change that. The what-if on a bid, the one-off analysis, the pivot you want sorted six ways in the next ten minutes — that's a spreadsheet, and it's the right tool. So every list in STrOp carries an Export CSV button that hands you exactly the rows on your screen, filtered and sorted the way you left them, and the whole record goes out the door with you from Settings → Data & Privacy any time you ask. The spreadsheet is where you think. The database is where the shop remembers. Keep both — just don't make the one that forgets be the one that has to remember.