How we shipped a full payroll workspace in six weeks.

The operator

SteadFast Transportation Inc. is a federally awarded USPS route contractor operating out of Plentywood, Montana. They run mail-transport routes across rural Montana and North Dakota with a rotating roster of independent day-rate contractors. The problem they came to Doyel Labs with was simple to describe: the SCA compliance side of their payroll had outgrown spreadsheets, and no off-the-shelf payroll SaaS understood the Service Contract Act at the level a DOL inspector would ask about.

What they needed: a workspace built specifically for SCA payroll, with wage-determination lookups from SAM.gov, day-rate floor checks on every draft, and an audit trail an inspector could read on the first request. What they did not need: tax filing, direct deposit, or a $600/month payroll SaaS bill. Their bank already paid the money; they just needed the compliance record right.

Week 0 · Read the statute first

Before we wrote a line of code, we read 41 U.S.C. §§ 6701–6707 and the FAR clauses that implement it. AI helped us skim; a human confirmed the specific fields the operator's USPS solicitation named. The rule that ended up driving the whole product is small enough to fit on a napkin:

For every SCA-covered day of work, the day rate must be at least (base wage + H&W fringe) × 8, where the base wage and H&W fringe come from the wage determination for the contractor's county on SAM.gov. Every pay stub has to name the WD number, the base wage, the H&W fringe, and the resulting floor.

That single sentence became the north star for the whole workspace. Every screen, every draft, every stub had to carry those four facts. When we got tempted to build a cleverer feature, we asked: does this help the operator hit that floor, or prove they hit it? If not, cut it.

Week 1 · Wireframe, schema, UI in one loop

Instead of the spec-then-design-then-build sequence, we did all three in parallel. AI drafted a Firestore-shaped data model, a migration SQL script, and the register UI form at the same time. Humans read every diff, kept the parts that matched the statute, threw out the parts that didn't, and pointed the AI at the next piece.

By day 3 the contractor register was live: name, SSN (encrypted at rest), state, WD number, contract number, day rate, minimum wage, H&W fringe, vacation handling under §4.173, YTD gross, YTD deductions. On day 4 the SCA floor check went in. By day 5 we ran the operator's real pay period — with redacted contractor data first, then live — and started shipping bug fixes the same day.

Week 2 · Batch pay run + stub email

Once the single-draft path worked, we built the batch. Pick a period. Pick contractors. The app runs the SCA check on every row, produces the batch of PDF stubs in one action, and (optionally) emails each stub to the contractor from the operator's own domain via Resend.

A small but important detail: Doyel Labs is never on the email header. The from-address is [email protected]. The reply-to is the operator's inbox. If a contractor has a question about their stub, they email SteadFast, not a software vendor they've never heard of.

Weeks 3 – 4 · Harden the audit trail

With the pay path stable, we hardened the audit log. Every state change in the app now leaves a row: every stub generated, every stub emailed, every rate change, every WD lookup, every blocked SCA-short draft, every sign-in, every password change, every passkey enrolment.

The audit table has a CSV export button. Retention is 180 days in the app; the operator is expected to keep the CSV locally for the SCA's 3-year rule. When an inspector asks for the pay records, the operator exports a CSV, hands them a stub PDF for any contractor + period, and points at the WD number on the header. Nothing is behind an accountant.

Week 5 · Sign-in, backups, ops

Passkey enrolment via WebAuthn, with a password fallback (PBKDF2, rate-limited lockout). A dashboard for the operator to see WD revision dates, upcoming pay periods, and the current audit count. Backup exports: full JSON, formatted DOCX, one-click restore that merges without overwriting.

These are the boring, high-leverage features that make software actually usable a year after launch. Passkeys mean the operator doesn't lose access when a laptop breaks. Backups mean if we vanished tomorrow, the operator still has their bytes.

Week 6 · Live and quiet

By week six the workspace was running weekly pay periods without our intervention. That's the outcome we aim for: the operator opens the app, does the pay run, and closes it. Doyel Labs stays on for maintenance under a monthly retainer — dependency updates, small feature adds, same-week response on anything broken — but the operator doesn't need us to run their business.

What we'd change

The SCA statute reading in week 0 was worth 3× its time. The next SCA build will start from the same rulebook, with the SCA floor formula literally in the top comment of the pay-draft file. That single formula drives the whole product surface.

We'd also invest a little more, earlier, in the backup + restore flow. Once the operator has a month of data, backups are the difference between "a broken laptop is an inconvenience" and "a broken laptop is a compliance emergency." It got there — it just could have gotten there in week 2 instead of week 5.

What's in the box today

Start a project

Tell us the contract type, the counties your contractors work in, and a rough headcount. Written scope and fixed price back to you within one business day.