Answer the discovery well

The discovery writes its questions from your brief and your references, so the best way to get good questions is a good brief. When the card arrives, answer as the production system will run, not as the demo will run.

• Give links. Every URL in the brief is read, screenshotted on desktop and phone and measured (fonts, sizes, colours, grid) before the first question. A reference you name is the design the frontend is built and judged against; say whether it is there for the look, the behaviour, or both.
• Name the products. “HubSpot + the finance Postgres” beats “a CRM”. Named systems become integrations in the summary; unnamed ones become assumptions.
• Say where it must live. Cloud, region and data residency are lock rules: a stack that cannot honour them is rejected, not discussed.
• Pick the load you will actually hit in year one. “Dozens of rooms with up to eight viewers each” is a better answer than a traffic bucket.
• Say who operates it. “Citeaxis operates it” is a different stack from “we have a platform team”.
• Budget is monthly infrastructure, not the project fee.
• Availability: be honest. “Never down” is expensive and the estimate will say so.

Use “something else” whenever the options miss your case; the agent reads free text as well as a pick. Skip what you truly do not know: the summary states the assumption the agent makes, and you can correct it before you confirm.