Every software project starts with a discovery phase: goals, stakeholders, requirements, architecture, a rough roadmap. In practice it lives in slide decks, Google Docs and call transcripts, and someone has to turn that pile into one coherent document.
I built Discovery Phase AI to do the first draft of that work. You upload your source files, review what the model proposes, and export a report.
What it does
- Takes decks, docs, transcripts and images and drafts the discovery stages: background, executive summary, problem statement, stakeholders, goals and metrics, users and journeys, requirements, architecture, roadmap.
- Lets you review every proposal before anything is saved. Nothing the model writes is stored until you accept it.
- Keeps an "improve with AI" chat on each stage, with a quality score and suggestions anchored to the text.
- Checks the impact of a change across stages, so an edited requirement shows which goals, diagrams or milestones may now be out of date.
- Exports the report as PDF, Word, PowerPoint or Markdown, with Mermaid diagrams drawn as images.
How it's built
- Backend: Go modular monolith (chi, pgx, no ORM, hand-written SQL). Every module follows repository → service → handler, and modules never import each other's internals.
- Frontend: React + TypeScript on Vite, Tiptap for the rich-text stages, Mermaid for diagrams.
- Database: Postgres, with all state in the database so several instances can run side by side.
- AI: Claude models. The model has no tools: its output is only parsed JSON, and every record id it mentions is checked against the database before it can touch anything.
Things I learned
Treat everything you send to the model as untrusted. Uploaded files, other stages' text and chat history are all wrapped as untrusted data, and a suggested change can only reference records that exist in the same project.
Make the AI output reviewable, not final. Typed operations (add, update, remove) that the user applies one by one are much easier to trust than a rewritten document.
Meter AI usage from day one. Each call reserves credits before it runs and settles afterwards, so parallel requests cannot overspend.
Try it
There is a free plan, and you can open a full sample report without signing up: example report (the project in it is invented).
I'd love to hear how you run discovery today, and what you would want a tool like this to do differently.
Top comments (1)
"Nothing the model writes is stored until you accept it" is the design choice I'd copy. Typed add/update/remove operations also leave you a clean history of who accepted what, which is exactly what a client asks for when a requirement changes late.
I'm a Staff SDET, and I pointed my automated checks at the site while reading. It scored 89/100, a B, and the landing page and example report look solid. The thing I'd fix first is missing-page handling on the app routes: a stale or mistyped link like /pricing/old-plan comes back as a 200 and renders a completely blank screen, with no nav and no "page not found" message. You already ship a noindex tag on that shell, so search engines are covered, but a visitor arriving from an old link just sees an empty page and leaves. Your /blog paths already return a proper 404, so a catch-all route in the React router that shows a real not-found view (with a 404 status if your host lets you set one) would close the gap.
There were 12 other smaller items in the same pass. How does the cross-stage impact check work under the hood: do you have the model compare stage text, or do you follow links between record ids?