The Starting Point

The client was a logistics startup. The founder had been running a freight brokerage manually — spreadsheets, email chains, phone calls — and wanted to turn the process into a software product for other freight brokers. She had a detailed understanding of the domain, a clear list of the problems she wanted to solve, and one hard constraint: she had a conference where she wanted to demo the product in 6 weeks.

The scope from our initial kickoff: a web app that let freight brokers manage loads (jobs), assign carriers, track status updates, generate quotes, and send documents to customers. Standard CRUD workflows wrapped around a domain model we needed to understand quickly.

This is, on paper, a reasonable 12-week project. We committed to 6.

Week 1: Discovery Under Pressure

The instinct in a compressed timeline is to skip discovery and start building. This is almost always a mistake, and it was the first thing we had to resist.

We spent 4 days in discovery. Two product designers sat on three separate Zoom calls with the founder walking through her actual daily workflow. We screen-recorded her using her existing spreadsheets. We asked dumb questions: "Why is this field here?" "What happens if you get this information before that information?" "When does this process break down?"

By day 4, we had a domain model that captured the core entities (Load, Carrier, Customer, Document, Quote) and the relationships between them. We also had a scope agreement: what was in the MVP, what was a stretch goal, and what was explicitly out.

The scope agreement was the most important document of the project. We referenced it nine times in the next five weeks when feature requests came in.

Weeks 2–3: Foundation and Core Flows

Stack decision was made in the discovery phase: Next.js, Postgres via Supabase, Prisma for the ORM, Clerk for auth. No debate. We'd shipped this stack successfully for similar projects.

The first two engineering weeks focused on the data model and the two most critical flows: creating a load and assigning a carrier to it. Everything else depended on these. We didn't touch the document generation, quote calculation, or reporting features until these worked end-to-end.

What almost broke us in week 2: a schema decision we made too fast. We modeled the carrier assignment as a direct foreign key relationship, but discovered on day 9 that carriers could be partially assigned (covering specific legs of a load, not the whole load). Refactoring this took a day we didn't have budgeted.

The lesson: even under time pressure, the data model deserves a second review before you build on top of it. The domain expert knows things they haven't told you yet. Ask explicitly: "Are there cases where this relationship isn't simple?"

Weeks 4–5: The Hard Stuff

Weeks 4 and 5 were when the project got tight. Document generation (PDF quotes and load confirmations) took longer than estimated — the client's document requirements were more precise than the spec captured, and we went through three rounds of layout adjustment. This is the work that looked "simple" on the scope but wasn't.

We made a decision at the end of week 4 that felt uncomfortable: we told the client that the reporting dashboard was not going to make the launch. The choice was: ship everything at 70%, or ship 85% of the scope at 95% quality. We chose depth over breadth.

This conversation is always uncomfortable. Clients hear "we're not shipping everything we planned" as "the project is failing." The framing we used: "The core product is solid. We're making a choice to not rush the reporting module and ship it properly two weeks after launch rather than ship it broken at launch." She agreed. She was disappointed. But she agreed.

Week 6: Testing and Real Users

The last week was dedicated to bug fixing and a controlled preview with 3 users the client recruited from her network — other freight brokers who'd agreed to give feedback.

This was the most valuable week. In two 1-hour sessions watching brokers use the product, we found 6 usability issues we never would have found internally: two dropdown interactions that were confusing, a date picker that didn't handle time zones correctly, and three instances where the status labels didn't match the terminology the industry used.

These were fixable in days. But they would have been embarrassing in a conference demo. Real user testing in the week before launch is non-negotiable.

The Launch and What Happened After

Day 42: the product was live. The founder demoed it at the conference. Two people signed up for beta access on the spot. The reporting dashboard shipped 12 days later.

Three months post-launch: 7 paying customers, one feature request that became a significant addition to the scope, and one user complaint that revealed a bug in the quote calculation we fixed in 48 hours.

What We'd Do Differently

More schema review time. The carrier assignment refactor cost us a day. A second domain expert review session on day 3 would have prevented it.

Earlier document generation prototyping. PDFs are always harder than they look. Prototyping the document layout in week 1 — before we had the rest of the app — would have surfaced the complexity earlier.

Set launch expectations in the contract. The scope adjustment conversation in week 4 wouldn't have been uncomfortable if we'd explicitly agreed in the contract that scope adjustments are possible when timeline is fixed. Document this upfront.

6 weeks is aggressive. It's achievable with a clear domain, a good discovery process, a focused team, and a founder who trusts you to make calls. It's not achievable if any of those conditions are absent.