SiliSuite

The Product

SiliSuite takes a client from "I have an idea" to a scoped, quoted, trackable project without a human analyst doing the requirements-gathering by hand. A conversational AI consultant extracts requirements, generates an IEEE 830-aligned SRS document, and hands off into a full project lifecycle, quotation, system design, development, testing, deployment with status tracking and a client-facing update/ticketing system throughout. SiliMind sits above it as the shared identity and billing layer, so the same login and billing relationship can eventually extend across a wider product suite, not just this one app.

The product is in active development, not yet shipped to production.

My Role

I'm the founding engineer, working across the full stack, Next.js/TypeScript frontend, FastAPI/Python backend built, and the product and architecture decisions in between. Design-before-implementation is a deliberate constraint I've held to: nothing gets built without a reviewed plan and, where the interface is being reworked, side-by-side comparisons of competing directions first.

The Hard Problems

Splitting the Consultation Prompt

The first version of the AI consultation flow used one large, monolithic prompt to handle everything: conversation, step tracking, readiness detection. That's brittle, it's hard to iterate on one part without risking regressions in another, and it makes the model's job harder than it needs to be. I'm restructuring this into two separate prompts with a clear handoff: a lean per-turn chat prompt that tracks conversation state and emits an explicit READY_FOR_SRS marker, and a separate, dedicated SRS-generation prompt that only fires once the backend detects that marker and validates readiness through a second guardrail check. Separating "have a conversation" from "produce a formal spec document" as distinct responsibilities, instead of asking one prompt to do both well.

Centralizing Auth and Billing

The backend inherited a dev-mode shortcut: JWTs were being decoded without signature or expiry verification, and auth/identity logic was duplicated across services with no single source of truth for billing. Rather than patch that in place, I'm designing SiliMind as the centralized auth and billing layer, issuing and validating JWTs, owning the User and Billing APIs, with every other service validating tokens via middleware and calling SiliMind's APIs instead of touching a shared database directly. It's the same identity/billing separation Google uses across its own product suite, and it's what makes a future multi-product ecosystem (not just this one app) actually viable instead of each service reinventing its own auth.