I embedded solo with a non-technical commodity broker to replace a paper register with production software — modeling a deal structure the paper never could, with no spec and no team.
The client is a commodity broker. Every deal — a "sauda" — is agreed between a seller and a buyer and can cover several commodities at once, each fulfilled not in one shipment but across multiple partial deliveries over days or weeks, each at its own price and bill number. That's a real hierarchy: a deal contains commodities, and each commodity contains deliveries — and none of it was structured on paper.
Kept by hand, that hierarchy collapses. There's no way to cleanly track which portion of a commodity has actually been delivered, at what price, against which bill — especially when a delivery's buyer or seller quietly differs from the deal's, which happens legitimately and needs to be visible, not silently lost. The single most time-consuming task built on top of this — annual billing — had ballooned to roughly two months of the owner's own effort every year, entirely by hand.
There was no requirements document, because there was no software to base one on. I extracted the actual data model by observing how deals really moved — where one commodity split into several deliveries, where a bill's party diverged from the deal's, where "complete" was a judgment call no formula could safely make. That shape became the schema before a single screen was designed.
I was the sole engineer across discovery, architecture, build, deployment, and now ongoing operations — the entire lifecycle, for one real client, alone.
A deal can hold several commodities, each fulfilled by several partial deliveries — modeled as a real three-level hierarchy, not flattened into one form. A whole deal loads in a single query.
Every field autosaves — no save button. Enter commits and advances to the next field. Built to feel like accounting software the broker already trusts, not a SaaS dashboard.
A delivery's seller or buyer can legitimately differ from the deal's own. The register marks that with a visible signal instead of silently overwriting or blocking it.
Every delivery already carries a computed amount and a snapshotted rate. Turning that into one-click annual bills is the current phase — the hard part, getting the numbers right, is already done.
Anyone can wire up a form. The engineering is in modeling a domain correctly — and staying responsible for that model even while building fast with AI assistance.
Each delivery snapshots the commodity's rate at the moment it's recorded, rather than referencing the commodity's current rate. Repricing a commodity later can never retroactively change an amount that's already been billed — a bug class the previous low-code tool had the exact opposite behavior for.
Quantity is tracked in Truck or Ton; deliveries are tracked in Bags. The two units aren't convertible, so no rule can safely decide when a commodity is finished — the system stores the operator's own mark, recomputed transactionally on every write so it can never silently drift from the data underneath it.
The original low-code backend couldn't express composite unique constraints, transactions, joins, or foreign-key integrity. "One commodity type per sauda" was an application-level guard with nothing underneath it, and a bill-number search took three sequential round trips. Migrating to PostgreSQL and Prisma turned that into one constraint and one query.
Google OAuth with a strict allowlist, checked again inside every server action — not just at the route layer. Server actions are directly-callable POST endpoints, so a route-only check leaves every mutation reachable without ever loading a page.
Built large parts of the system AI-assisted while retaining full architectural review — catching an authorization gap and a date-handling bug the AI introduced, both of which survived its own generated tests and documentation.
Separate UAT and live environments, versioned migrations applied deliberately, and real incidents diagnosed straight from logs — including a database host that only publishes an IPv6 address, and a CI step silently skipping the binary a schema migration needed.
This project is what convinced me forward-deployed engineering is where I belong — not because it was easy, but because modeling a real domain correctly, for a real person, with no spec and no one else to hand it off to, is a different kind of engineering than a ticket queue ever is.
I'm currently a software engineer at Equifax, working on the AWS-to-GCP migration of a real-time credit and fraud decisioning platform. I'm looking to bring the same ownership shown here — discovery through production, AI-assisted but never AI-abdicated — to a team building AI products for real customers.