Spike the seam before you schedule the build
The notes from a discovery workshop look thorough. Problem statement, happy-path flows, a backlog, a stack recommendation. What they often lack is contact with the one place the project will actually fail: the seam with someone else's system, someone else's data, or someone else's device. We have learned to put a short technical spike inside scoping — before the schedule hardens — so the estimate is arguing with evidence instead of with a whiteboard.
The seam is the project
Most of the builds we take on are not greenfield platforms floating in isolation. They sit against Shopify webhooks, Stripe payment methods, Vision handwriting recognition, vendor PDFs that never look the same twice, or a printer sitting in a workroom. The screens are real work. The seam is where the calendar slips.
Al's Flowers is a clean example. Taking an order is not the hard part. Getting a reliable kitchen ticket out of a webhook that can arrive twice, late, or not at all is. If discovery only maps the customer journey and never sends a test order through PrintNode, the plan is still a story about commerce rather than a plan about operations.
The same pattern shows up in document automation. Parsing a purchase order with a model in an afternoon is easy to demo. Surviving the next vendor's layout is the actual project. Scoping that as "AI parsing" without opening a folder of messy real PDFs is how you schedule a demo and call it a delivery.
What a spike is allowed to be
A scoping spike is not a prototype of the product. It is a narrow experiment aimed at the assumption that would hurt most if it were wrong. One integration path. One failure mode. One afternoon or a couple of days, capped on purpose so it cannot quietly become the build.
For Endeo, that meant proving that PencilKit strokes and a live transcript could share a clock before we treated "linked notes" as a feature on a roadmap. For BuilderHelp payments, it meant touching Financial Connections and a second provider early enough that "we can swap" was a tested claim, not a slide. For RuleCaddie, it meant grounding answers in a citable rules corpus before anyone argued about chat UI polish.
The output is boring on purpose: a short write-up of what worked, what broke, what the API actually returned, and which assumptions died. If the spike needs a polished interface to be understandable, it was aimed at the wrong thing.
What we refuse to leave as a workshop guess
Auth and account boundaries when the product has more than one kind of user. On BuilderHelp the project manager, homeowner, and field crew are not three skins on one screen — they are different access patterns sitting on one record. Discovering that in a workshop is useful. Confirming it against the data model with a thin spike is what keeps month four from becoming a permissions rewrite.
Offline and degraded network when the brief says "it should work in the field." Airplane mode is the easy case. One bar of signal with a request that neither succeeds nor fails is the case that reaches users. If that constraint is real, scoping without a device in that state is fiction.
Any path where a wrong answer has an operational cost: a mistyped part number, a payment that looks successful and is not, a transcript linked to the wrong minute. Those paths need a conservative design early. A spike is how you find out whether the platform you chose even lets you be conservative.
How the spike changes the schedule
Sometimes the spike shrinks the work. The platform already handles the ugly case, and the build can stay thin. That is a good outcome, and it only shows up if you touch the seam.
Sometimes it relocates the work. The UI was never the long pole; reconciliation, idempotency, or a human review step was. The calendar should say that out loud before anyone paints screens for three weeks.
Sometimes it ends the conversation. The integration cannot do what the brief assumed, or the input quality makes the proposed automation unsafe without a review loop nobody wanted to staff. Better to learn that while the plan is still paper. We would rather redraw the smallest useful version than invent confidence.
Keep the workshop — just do not stop there
Workshops are still where we learn who is holding the product, what it has to be true for, and what is explicitly out of scope. Those answers shape architecture. They do not substitute for evidence about the seam.
The practice is simple enough to defend in a kickoff: list the assumptions that would force a rewrite if false, pick the top one or two, and spend a short fixed window making them fail in public. Write down what you learned. Then schedule the build.
If a plan has never been embarrassed by a real payload, a real device, or a real third-party response, it is not finished discovery. It is a confident outline waiting for production to do the teaching.