Your process vs traditional SDLC
Small-team rapid delivery — not a scaled enterprise software factory.
Capture the problem, not a spec document
AI / v0 / Figma — something clickable
Walk through it with the client
Explicit yes/no with remarks
Implement exactly what was approved
Ship and record the version
Changes become new prototype versions
Understand the workflow
Talk to the user. Watch how they work today. Capture the problem, not a 40-page spec.
In the app: create a Feature with a Problem Statement.
Generate a prototype
Use AI, v0, Figma, or a quick Razor mock. Something the client can click.
In the app: create Prototype v1 with a URL link.
Review together
Walk through the prototype in a meeting or async. Collect verbal feedback — no formal review board.
In the app: add Comments on the feature or prototype.
Get approval
Client says yes or no. If rejected, note why and iterate — don't overwrite, create v2.
In the app: record Approval (Approved / Rejected) on that version.
Build exactly that
Developer or AI implements what was approved. The prototype is the spec — no interpretation gap.
Update Feature status to Built when done.
Deploy to production
Ship it. Record which prototype version went live so you can answer "was this included?" six months later.
In the app: record Deployment with feature + version links.
Collect feedback → repeat
"Can we also add…" becomes a Change Request. New prototype version. Approve again. Build again.
The loop never destroys history — every version stays on record.
Each phase produces formal documents and sign-offs before the next begins. Click a step to see typical deliverables.
Interviews, BRD/FRD, use cases
Cost, risk, and technical viability
Architecture, modules, stack
Low-fidelity layouts and flows
High-fidelity static screens
Clickable validation before code
LLD, schema, APIs, data model
Coding, reviews, unit tests
SIT, regression, performance
Business test scripts and sign-off
Release plan, migration, go-live
Support, patches, enhancements
Requirements gathering
Business analysts interview stakeholders, document current-state pain points, and capture functional and non-functional requirements in structured templates.
Often weeks of workshops before anyone sees a screen.
Feasibility study
Evaluate whether the project is worth doing: budget, timeline, technology fit, regulatory constraints, and operational impact.
Gate review: project may stop here if ROI is unclear.
High-level design (HLD)
Architects define system boundaries, major components, integration points, and the technology stack — still mostly diagrams and narrative, not screens.
Separate from UI work; often owned by a solution architect.
Wireframes
Low-fidelity sketches of layout, navigation, and field placement. Focus is structure and workflow — grey boxes, not brand polish.
Tools: Balsamiq, Axure, Figma wireframe mode, or even paper.
Mockups
High-fidelity static screens with real typography, colours, and sample data. Looks like the product but does not behave like it.
Designers hand off PNG/Figma links; developers still interpret behaviour from notes.
Interactive prototype
Clickable simulation linking mockups together so stakeholders can walk through flows before code is written. Still throwaway — not production quality.
This is the closest step to what our cycle treats as the living spec — but it usually sits after weeks of prior documents.
SDS / detailed design
Software Design Specification (SDS) or Low-Level Design (LLD): developers document exactly how each module, table, and API will work. The written spec may diverge from the prototype unless someone keeps them in sync.
Heavy documentation phase — often 50+ pages for a mid-size feature.
Implementation
Developers code against the SDS. Code reviews, coding standards, branch policies, and unit test coverage gates apply before merge.
If prototype and SDS disagree, teams debate which is authoritative.
Integration & system testing
QA validates modules working together, regression suites, performance benchmarks, and security scans in staging environments.
Separate team, separate timeline from development.
UAT (user acceptance testing)
Business users execute scripted scenarios against staging. Formal sign-off pack collected before production release is approved.
Another gate — release blocked until paperwork is complete.
Deployment
Release management: deployment runbook, data migration, rollback plan, communication to users, and post-go-live smoke checks.
Often a change-advisory board (CAB) approves the window.
Maintenance
Production support, SLA tickets, hotfixes, and enhancement requests that may restart the full SDLC cycle for the next version.
The loop returns to requirements gathering for major changes.
In enterprise SDLC these are separate deliverables, often owned by different people, reviewed in different meetings. Drift between them is common.
What we use instead
- ✓Prototype URL — the living spec clients can click
- ✓Approval record — who said yes, when, and any remarks
- ✓Version history — v1, v2, v3 never overwritten
- ✓Change requests — scope changes logged, not sneaked in
- ✓Deployment ledger — which approved version shipped
Side-by-side
- ✗Requirements doc → Prototype link
- ✗Sign-off meeting pack → Approval + remarks
- ✗Change request form → CR in tracker
- ✗Release notes doc → Deployment record
- ✗"Was this in scope?" debate → Audit trail