Federico Seco
MenuClose

02 / Operational B2B product

Preserve extra-work evidence before the context disappears.

A phone-first workflow that carries one request from field capture through requester acknowledgment, actuals, pricing, outcome, and a printable evidence packet.

Product brief

Product
Extra Work Capture
Status
Portfolio demo
Target user
Specialty subcontractor field teams and the office staff responsible for turning extra work into a reviewable commercial record.
My role
Product definition, interaction design, domain modeling, frontend architecture, implementation, verification, and documentation.

The problem

Extra work often begins in a conversation, photo, or hurried field note. When acknowledgment, actuals, and pricing live in different places, the evidence weakens before anyone can resolve the outcome.

Live workflow demo ↗All work →

01 / Workflow

The product, end to end.

Follow the product from first input to a reviewable outcome.

Extra Work Capture product flow
  1. 01Capture field evidence
  2. 02Request acknowledgment
  3. 03Record actuals
  4. 04Prepare pricing
  5. 05Resolve outcome
  6. 06Print evidence packet

02 / Product surface

The interface carries the evidence.

Owned, locally generated product assets—no client screenshots or borrowed logos.

Mobile extra-work field capture form
Field capture keeps the first evidence entry short enough for the jobsite.
Desktop queue of extra-work requests
The office queue exposes status, ownership, and what requires attention.
Mobile requester acknowledgment screen
The requester sees a bounded acknowledgment—not a claim that commercial approval is complete.
Desktop pricing and evidence workbench
Actuals, evidence, pricing, and resolution stay in one reviewable record.

03 / Decisions

Architecture with a reason.

Next.js · React · TypeScript · Vitest · Playwright · GitHub Actions

01

One bounded ticket

The demo proves a single commercial workflow end to end instead of simulating an entire construction platform.

02

History is append-only

Mutations create reviewable events; they do not silently rewrite the story of what happened.

03

Retries are product states

Deterministic failures and idempotency make recovery visible without duplicating a commercial action.

Failure paths

What can go wrong is part of the product.

  • Requester link expired or already used
  • Mutation interrupted after the server accepted it
  • Required evidence missing before pricing
  • Printable packet generated from incomplete data

Verification

What supports the claim.

  • Domain transition tests
  • Idempotency and replay coverage
  • Responsive browser review
  • Continuous integration checks

Portfolio boundary

Complete enough to review. Honest enough to trust.