The backend was three weeks late. We shipped the frontend anyway.
A concrete sprint diary: one OpenAPI file drove a local mock with latency and error overrides, a four-step checkout scenario with an HTML report, live docs, derived database tables and a hosted MCP endpoint while the real API did not exist yet.
The checkout service slipped three weeks on a Monday. Instead of freezing the web and mobile teams, we spent the week working against one OpenAPI document. This is what each day actually looked like in Powerduck.
Monday: turn a skeleton into a contract
We had a rough YAML with eight endpoints. I asked the assistant to add the missing order and payment operations. Each proposal arrived as a patch card listing the exact JSON Patch operations; nothing touched the file until I clicked Apply. Broad requests get staged automatically — a clarifying question first, then cards of two to five operations — so the document grew in reviewable chunks instead of one unmanageable dump. By evening the spec described the whole checkout flow.
Tuesday: start a mock that behaves like production’s worst day
I started a local mock straight from the chat; the app confirmed the address it was serving on. The mock is not a static 200 machine:
latencyMsset to 250 to feel like a real network;- response overrides for the cases the frontend must handle:
402for an expired card,429for a rate limit, a declined 3DS result — up to 100 overrides per mock; - a
basePathmatching our gateway, and a chosen port; - multiple mocks at once, one per open document, listable and stoppable individually.
The mock also records the requests it receives. Querying that log settled the first integration argument immediately: yes, the mobile client really was posting to v1 instead of v2.
Wednesday: encode the business flow as a scenario
A single request proves one call; the checkout is a workflow. I built a scenario with four ordered steps: create order, take the returned id, create payment against it, then fetch the order and assert it is paid. Data passing between steps, assertions on status codes and response fields, and step order are first-class — the runner never silently drops an assertion. Runs execute through the local CLI engine, progress streams step by step, and a long run can be cancelled.
Thursday: hand over evidence and the database plan
I exported a self-contained HTML report of the scenario for the release ticket. Reports come in ten languages, redact credentials automatically, and fold large payloads, so the file is safe to attach as-is.
The backend team got a head start too: the Data model surface derived every table, column, foreign key and the many-to-many join tables from the schemas, and produced one idempotent CREATE TABLE IF NOT EXISTS script in foreign-key order with secondary indexes. SQL is generated for review and never executed against a database from the app.
Friday: publish docs and MCP without exposing internals
The spec went to Powerduck Cloud. Rendered documentation switched on immediately; the MCP endpoint stayed off until I enabled it. In the exposed-operations workspace I toggled the internal admin endpoints off individually — the source file is never modified — and protected the docs with a view password while the contractor links were live.
| Old tab | What actually replaced it this week |
|---|---|
| Mock SaaS | Local mock from the spec, with latency and 100 possible overrides |
| Test tool | Ordered scenario with data passing and assertions |
| Report builder | One-click standalone HTML report, credentials redacted |
| Schema whiteboard | Derived tables, join tables and forward-only SQL |
| Docs generator + agent glue | Hosted docs and managed MCP from the same version |
The backend shipped on the Thursday of week four. The frontend merged on time, against a contract that had not drifted once. Start with the mock server guide if this is the week you are in.