01
Understand
Capture the client's real intent. Define scope. Mock up the solution. Get sign-off before any code is written.
1–4 weeks · scaled to project size
Dhwani RIS · AI-SDLC
From a client's idea
to a working product,
in weeks.
An end-to-end process for building social-impact software with AI — from the first client conversation to the weekly health report years later.
01 · How it works
Four steps. Every project. Same shape.
The process is the same whether a project takes a week or a quarter. What changes is depth — not direction.
02
Build
Design the architecture. Build with AI assistance. Tests written before code. Documentation lives alongside.
Most of the project time
03
Ship
Quality checks, security scans, performance tests — all automated. The release only goes live when every check passes.
A few days
04
Run
Production runs with monitoring on by default. Weekly health reports go out automatically. Issues are caught before clients call.
Forever
02 · The team
Three roles. Three team shapes.
Who plays which role flexes with project size. What gets checked along the way never does.
The three roles
PB
Product Builder
Drives requirements, design, and build. Talks to the AI most. Owns the technical drafting from intent to launch.
AR
Architect
Defines guardrails and signs off design. Reviewer and decision-maker, not implementer. Keeps quality consistent across projects.
AM
Account Manager
Owns the client relationship and the intent. Holds scope at kickoff and charter. Drives client sign-offs. Owns go-live handover.
Three team shapes — pick the right size
Solo · 1 person
Builder + AM = same person
One person plays both roles. Architect is shared with the portfolio. DevOps support is shared.
Best for: small features · ~5-day projects
Pair · 2–3 people
Builder + AM separate
Two distinct roles. Architect shared across a few projects. DevOps support shared. Sign-offs are separated cleanly.
Best for: ~2-week projects · customizations
Full team · 4+ people
Every role its own person
Dedicated Architect. Dedicated DevOps engineer for the duration. Multiple Builders possible.
Best for: ~4-week greenfield · government projects · regulated work
03 · What we shipped
Five AI assistants. One unified process.
Each role gets a packaged AI assistant — a tested set of prompts, skills, and review rules — so nobody starts from scratch on a new project.
Live on github.com/dhwani-ris as of 2026-05-17 · v0.1.0 / v0.2.0 across 9 repos.
For the Account Manager
Client Conversation Assistant
What it does: Helps the AM capture client intent, run discovery, draft the charter, and keep scope under control through the project.
What stakeholders see: Faster sign-offs. Fewer "that's not what I meant" moments later.
Repos · service-am-plugin · product-am-plugin (one per department · v0.1.0 live)
For the Architect
Architecture Assistant
What it does: Reviews technical designs against Dhwani's reference patterns. Catches drift before it ships.
What stakeholders see: Consistent quality across projects. No rogue architectures.
Repos · service-architect-plugin · product-architect-plugin (one per department · v0.2.0 live · 9 lifecycle skills each)
For Builder + Engineering
Code Building Assistant
What it does: Writes code with AI — but enforces tests-first, documentation-alongside, and proper review before merge.
What stakeholders see: Faster delivery without the quality drops you'd normally expect from speed.
Repos · service-builder-plugin · product-builder-plugin (one per department · v0.1.0 live · 4 sub-personas + 5 skills each)
For DevOps + Security
Quality & Delivery Assistant
What it does: Runs security scans, load tests, and the pre-release checklist automatically. Releases ship with a signed report.
What stakeholders see: No surprises in production. Every release has evidence.
Repo · ai-sdlc-devops-plugin (shared · v0.1.0 live · surface 1 of 2)
For DevOps (always-on)
Production Monitoring Assistant
What it does: Watches every live application — uptime, performance, security. Sends weekly health reports automatically.
What stakeholders see: Issues caught before clients call. Monthly reports in their inbox.
Repo · ai-sdlc-devops-plugin (shared · v0.1.0 live · surface 2 of 2)
Shared infrastructure
Nine repos total — all live on github.com/dhwani-ris. Each persona-facing assistant (AM, Architect, Builder) ships as two repos — one per department (service-* and product-*) — so each department can tune its plugin without colliding. The DevOps plugin is shared across departments. Plus the two shared infrastructure repos.
04 · What we need
Two engineers. A small budget. Four decisions.
Concrete, time-bound, and reviewable at each quarter boundary.
People
2 dedicated DevOps engineers · 4 quarters.
Engineer 1 · Quality & Delivery anchor
- Owns Stage C end-to-end (pre-go-live checks)
- Builds Kotwal CI integration
- Builds the Release Readiness Report pipeline
- Owns the
ai-sdlc-devops-pluginQuality & Delivery surface
Engineer 2 · Adoption & Operate anchor
- Builds the Day 1 starter template
- Builds inter-plugin bridge skills
- Owns Production Monitoring + the hub
- Owns the
ai-sdlc-devops-pluginMonitoring surface
Plus part-time support from each project's Tech Lead during their rollout window. No new permanent hires beyond what's already planned.
Tooling
Free for most things · small licence budget for the rest.
Free or already-licensed
GitHub (private) · Claude CLI · Mermaid · Google Stitch · Fireflies.ai · Kotwal · Mukhbir · Prometheus · Loki · Tempo · Grafana · Terraform · pre-commit · gitleaks
Needs a small budget
Paid security scanning tier (Semgrep / Snyk) · production status page (Better Uptime or Instatus) · self-service deployment portal — Backstage (OSS, build effort) or paid (Port / Cortex)
Exact annual licence estimate refined in the Q0 inventory phase — before the spend commitment is made.
Decisions
Four standards calls only leadership can make.
-
Front-end stack — standardise on one, or stay project-dependent?
Drives which Builder-plugin templates we build first (Vue vs React).
-
Cloud target — AWS default, with on-premise for government work?
Drives IaC module choice and Architecture Assistant reference patterns.
-
Deployment portal — build with Backstage, or buy Port / Cortex?
Q2 capacity hinges on this — OSS is a build effort, paid is faster but recurring spend.
-
Project sizing — who classifies solo / pair / full team?
Determines team-shape assignment per project and DevOps pull on each engagement.
05 · Timeline
One year. Five milestones.
Each quarter delivers one complete capability. Leadership reviews at every boundary before continuing.
Now
Foundation
Pick the pilot project. Agree the standards. Build the shared infrastructure that every assistant will use.
Quarter 1
Understand stage assistants
Client Conversation + Architecture Assistants available to all teams. First projects start with them on day one.
Quarter 2
Build stage assistant
Code Building Assistant rolled out across active projects. AI writes alongside developers — with the guardrails on.
Quarter 3
Ship stage assistant
Quality & Delivery Assistant gates every release. First project ships end-to-end through the new process.
Quarter 4
Run stage live everywhere
Production Monitoring Assistant on every active project. Weekly reports automated. The full process is live.
06 · The user flow · what the client experiences
From a fuzzy idea to a product they trust.
The same project, told from the client's chair. Seven moments that matter — and what they hear from Dhwani at each one.
①
"I have an idea — I'm not sure how to scope it."
The conversation
AM listens. Real intent surfaces. Discovery interviews captured automatically. Charter drafted by AI, refined together. Client signs.
→ Signed Charter · scope and success criteria agreed
②
"Show me what it'll look like."
The mock-up
Working mock-up on a real URL within days. Client refines it on the actual page, not on a slide deck. Each round closes in hours.
→ Mock-up signed off · the build can begin
③
"How's it going? I don't want big-bang surprises."
The continuous preview
Client gets a dev URL that updates daily. They watch the product take shape. Concerns surface early — not at UAT.
→ Continuous visibility · no surprise at the end
④
"Let me try it myself."
The validation
UAT environment ready when the client is. Issues filed → fixed → re-validated. No back-and-forth over screenshots.
→ UAT sign-off · the product behaves as agreed
⑤
"Is it safe to launch?"
The Release Readiness Report
One page. All security checks, load tests, performance baselines. Every check signed off before public users get in.
→ Confidence to launch · evidence, not assurances
⑥
"Take it live."
The launch
Production goes live. Heightened monitoring for the first thirty minutes. AM stays in the room. Rollback rehearsed if needed.
→ Live product · public users in
⑦
"How is it actually running?"
The monthly report
Automated health report lands in the client's inbox monthly. Uptime · performance · issues caught · anything to watch. They never have to chase.
→ Sustained confidence · ongoing trust
This is what the client sees — the outside-in view. The next two sections show the same journey from inside Dhwani: the complete picture of who does what (§07) and how the project flows through environments (§09).
07 · The complete picture
Every stage. Every role. Every gate.
The full AI-SDLC laid out in sequence. Read this once to see how a project moves from a first conversation to a live, monitored application.
Intent & Charter
AM-led. Capture the client's real intent. Map stakeholders. Agree the Charter — scope, success criteria, team, escalation.
Gate · Signed Charter
Solutioning
Draft functional requirements, user roles, process workflows, data model, wireframes. Mock-ups signed off by client — AM facilitates the client touchpoints.
Gate · Client signs the mock-up
Tech Spec & sign-off
Tech Spec assembled. Architecture validated against reference patterns. Sign-off captured as a signed git tag.
Gate · Tech Spec signed · ready for the first AI prompt
Build & QA loop
Four AI personas inside one repo: Dev writes code (strictly to docs), QA writes tests first, BA maintains documentation, Reviewer checks PRs. Auto-deploys per branch.
Gate · CI green · review approved · merge to development
Client UAT
Client validates the built product against the original intent. Often optional on small projects — staging can serve as the preview.
Gate · UAT signed · all critical issues resolved
Pre-go-live checks
Security scans, penetration test, load test, performance baseline, end-to-end test finalisation. All auto-generated. SLOs confirmed.
Gate · Every check green · Release Readiness Report signed
Go-Live
Production deploys. Post-deploy monitoring tightens for the first 30 minutes. Public users only after the gate passes.
Gate · Stable on production for 30 min · rollback rehearsed
Run forever
Weekly health monitoring. CPU should stay under 50%. 3-tier alert escalation — third alert is critical and triggers auto scale. Weekly + monthly reports to project owners.
Ongoing · feeds learnings back to KM for the next intent
All eight stages happen on every project. Their depth changes with project size — a 5-day mGrant fit-gap moves through them faster than a 4-week greenfield. The gates never get skipped.
08 · Inside each plugin
What's actually in each repo.
For engineers and the curious. Each plugin is a packaged set of skills, sub-personas, and commands that Claude Code loads on demand.
Used by · Account Manager
service-am-plugin · product-am-plugin
Two repos, one per department. Same skills shape, tuned for the engagement model of each.
Skills inside: stakeholder mapping · MoM authoring · charter drafting · client comms · scope monitor · sign-off capture
Main command: claude /intent
Used by · Architect
service-architect-plugin · product-architect-plugin
Two repos, one per department. Reference patterns differ between Service and Product work.
Skills inside: architecture review · pattern matching · ADR drafting · IaC pattern selection · pre-go-live validation
Main command: claude /architect
Used by · Builder + Engineering
service-builder-plugin · product-builder-plugin
Two repos, one per department. Same four sub-personas inside each:
- Dev · writes code strictly following docs · no scope expansion
- QA · writes test cases first from the PRD · then validates code
- BA · owns comms · maintains docs as code evolves
- Reviewer · checks tests + docs + PR hygiene before merge
Main command: claude /build · plus master-prompt creation tool
Used by · DevOps + Security
ai-sdlc-devops-plugin
Two surfaces inside the same plugin:
- Quality & Delivery · VAPT · SAST · PenT · E2E finalisation · load · performance reports — all auto-generated · SLOs confirmed
- Production Monitoring · weekly health · CPU < 50% check every 7 days · 3-tier alert escalation · auto scale on 3rd critical · weekly + monthly reports
Main commands: claude /pre-go-live · claude /monitor
Shared infrastructure
ai-sdlc-skills
Every skill referenced above lives here. Semver-tagged with eval suites. Plugins pull from here, so a fix in one place flows to every active project.
Onboarding · SOPs · index
ai-sdlc-hub
Single GitHub Pages site. Per-persona onboarding paths, plugin docs, deployment lifecycle, FAQs. One URL anyone lands on to find the plugin for their role.
09 · From idea to live · the project journey
How a project starts, builds, and ships.
Six environments. One gate at each. The same flow whether the project is a 5-day fit-gap or a 4-week greenfield.
Wrapper · GitHub repo
Triggered by: Product Builder (or AM = Builder on solo projects). One command:
gh repo create dhwani-{stack}-{client} --template ai-sdlc-stage-a-starter
Repo arrives pre-wired: folders · schemas · CI seed · Pages → CloudFront · .claude/ catalogue. First AI prompt ready to execute.
Staging · auto-provisioned
Triggered by: automatic on repo creation.
Staging env spins up the moment the wrapper is set up. First AI prompt runs here. Auto-named: {project}-staging.dhwaniris.in. Builder validates approach before going wider.
Development · the working branch
Triggered by: merge to the development branch.
Auto-deploys to the dev environment. Builder iterates with the Code Building Assistant — Dev writes code, QA writes tests first, BA keeps docs current, Reviewer checks PRs. Regression runs continuously.
UAT · often optional
Triggered by: AM, after dev passes regression. Auto-creates the UAT env.
Client validates against the original intent. On small projects, staging often serves as the client preview and UAT is skipped. On larger projects, UAT is a formal cycle with named approvers.
Pre-go-live gate · DevOps plugin
Triggered by: DevOps, when UAT (or dev) signs off.
The Quality & Delivery Assistant runs every check: VAPT · SAST · PenT · E2E finalisation · load test · performance reports. SLOs confirmed against the Sol Doc. If any check fails, the gate stays shut — no production deploy.
Production · public users
Triggered by: the gate passes. AM + DevOps sign Go-Live.
Public deploy. Post-deploy monitoring tightens for 30 minutes. Production Monitoring Assistant takes over: weekly CPU check < 50%, three-tier alert escalation, auto scale on the third critical alert, weekly + monthly reports to project owners.
The journey is the same on every project. Depth changes — a 5-day fit-gap might collapse Stages ③ + ④ into one merge, while a regulated government project may add a compliance gate between ⑤ and ⑥. The six environments stay constant.
For today's session
Three things to lock.
- The pilot. Which project exercises the full process but isn't client-critical from day one?
- Ownership. Who owns each AI assistant going forward — a vertical lead, a champion, or a team?
- Timeline pressure. Do we ship the foundations by quarter-end, or do we have more runway?
Pick the pilot. The rest follows.