SRE — Software Requirement Bot
Conversational requirements gathering that ends in a structured, downloadable SRS
Visit live project- Pipeline
- Chat → PDF
- AI providers
- 2
- Persistence
- Postgres
- Frontend
- React 18
Overview
SRE turns the step most software projects skip — writing down what is actually being built — into a guided conversation. A React 18 and TypeScript dashboard walks a team through requirements gathering, an AI layer with provider failover compiles the conversation into a structured specification, and the server composes that specification into a downloadable SRS PDF. Projects, conversations and generated summaries all persist in PostgreSQL.
The challenge
The person who knows what the software must do is rarely the person who can write a specification
Most small teams begin building from a chat thread and a rough deck. A requirements document would prevent half the rework that follows, but a blank SRS template is intimidating, the section structure is unfamiliar, and the domain expert is usually not the technical writer. So the document never gets written, and the ambiguity surfaces later as scope disputes.
SRE inverts the interaction: instead of asking someone to fill in a document, it asks them questions and produces the document.
- A blank template is a far worse prompt than a conversation
- The output has to be a real deliverable — a structured SRS, not an exported chat log
- AI providers rate-limit, time out and change; a single-provider dependency makes the product unavailable
- Conversations and generated specifications must survive a refresh, a device change and a week away
What we built
A chat front end, a structured-JSON AI layer with provider failover, and server-side document composition
The system is a three-stage pipeline: conversation, then structured summary, then document. The chat interface persists every message to PostgreSQL as it is sent, so the transcript the summary is built from is exactly the transcript the user saw — no optimistic local state that can diverge from the server.
When a summary is requested, the server re-aggregates the full conversation plus project metadata and asks the model for structured JSON against a fixed shape rather than for prose. That JSON is stored on the project row and rendered by the UI as discrete sections. The report endpoint then composes the PDF from the same object with pdf-lib — title page and sections built server-side, so every export is identical regardless of who triggered it or what browser they used.
AI calls run Gemini-first with a ChatGPT-compatible fallback in the same endpoint, so a degraded provider is a latency event rather than an outage.
What we delivered
Guided requirements conversation
The model asks, the user answers in plain language. Domain knowledge goes in as speech rather than as document structure, which is the entire reason the specification gets written at all.
Structured summary generation
The server aggregates the conversation and project metadata and requests structured JSON against a fixed schema. The result is persisted to the project row, so it survives refreshes and can be re-rendered or re-exported without another model call.
Server-side SRS export
pdf-lib composes a title page and sectioned document from the stored summary object. Identical output for every user, with no dependency on browser font availability or client-side rendering quirks.
Project workspace
Multiple projects per account, each with its own conversation history, stored summary and export path — so a team can run several specifications in parallel without them bleeding into each other.
AI provider failover
Gemini as primary with a ChatGPT-compatible fallback in the same request path, and an explicit readable error when both fail rather than a silent empty response.
Accounts with OTP verification
Signup, OTP email verification and password reset, with bcryptjs hashing on stored credentials.
Admin controls
Administrative views over users and projects for platform oversight.
Reproducible database setup
A scripted initialisation step provisions the full schema, so standing up a new environment is one command rather than a migration archaeology exercise.
Engineering challenges
The problems that took real work to solve. Tap any one to read how.
Problem
Asking a model for "a requirements document" returns prose that renders differently on every run, cannot be edited section by section, and cannot be reliably parsed into a PDF layout.
Solution
The summary endpoint requests structured JSON against a fixed shape and persists it to the project row. The UI renders sections from that object and the PDF composer reads the same object — one structure, three consumers, and re-export costs nothing.
Security posture
Password storage
bcryptjs hashing on signup and password reset — salted and adaptive, not a fast hash
Account verification
OTP email flow covering both signup and password recovery
SQL injection
Parameterized queries throughout via node-postgres placeholder binding — no string-concatenated SQL anywhere
Provider credentials
All AI provider calls are issued from server-side API endpoints; the browser never talks to a model vendor directly
Configuration
Environment-driven configuration with a committed example file and no credentials in source
Results
Chat → PDF
End-to-End Pipeline
Conversation, structured summary and composed document
Gemini → GPT
Provider Failover
Automatic fallback when the primary provider fails
Server-side
PDF Composition
pdf-lib — identical output for every user, every browser
Parameterized
Every SQL Query
Injection-safe access through node-postgres
Outcomes
- A working pipeline from empty project to downloadable SRS, with the conversation, the structured summary and the export all persisted and re-runnable.
- Provider failover that keeps the product usable when a single AI vendor is degraded or rate-limiting.
- A single structured summary object acting as the source of truth for both the on-screen view and the generated document.
- Security fundamentals in the right places: hashed credentials, OTP verification and parameterized queries on every database call.
- A defined hardening path ahead of a multi-tenant release — server-only credential naming, per-user rate limiting on AI endpoints, request-size caps, and containerised CI deployment.
Want something like SRE — Software Requirement Bot?
Share your goals and we will come back with a clear plan and estimate.