The six phases at a glance
Six phases on every engagement; duration scales with project size, the structure never changes.
Six phases, written SLAs, one playbook: from four-week MVP to nine-month legacy redevelopment.
Six phases on every engagement; duration scales with project size, the structure never changes.
A 30 to 45 minute consultation with a senior engineer. Within 48 hours: written scope, milestones, and a fixed price or rate-card estimate. No commitment.
A structured week inside your existing system: codebase review, static analysis, database profiling, undocumented logic captured in an audit report. Surprises get caught here, not in week six when they cost ten times more.
Written architecture document, agreed sprint plan, environments stood up, AI tooling configured (Claude Code, Cursor, GitHub Copilot). Team introduced to your stakeholders.
Two-week sprints, working software demoed at the end of every one. Planning Monday morning; live demo and retro every other Friday.
Full team on standby for 30 to 60 days after launch: daily status, critical issues fixed within 4 hours, old system kept as an instant fallback. Included in the project fee.
Optional monthly retainer: bug fixes within SLA, dependency and security patching, monitoring, and up to 8 hours of minor enhancements per month. Pause, scale, or cancel with 30 days notice.
The structure of a typical 8-week MVP; larger projects add more sprint pairs.
| Week | Phase | Deliverables |
|---|---|---|
| Week 1 | Audit + Architecture | Audit report (if applicable), system architecture document, sprint plan, environments provisioned, stakeholder kickoff call. |
| Week 2 | Sprint 1; Foundations | Repository, CI/CD pipeline, base auth (SSO/JWT), database schema v1, design system tokens, initial test harness. |
| Week 3 | Sprint 1; Core CRUD | Primary entity CRUD APIs, admin views, seed data, automated test coverage above 80%, sprint 1 demo and retro. |
| Week 4 | Sprint 2; Business logic | Domain-specific workflows, role-based permissions, audit logging, integration scaffolding. |
| Week 5 | Sprint 2; Integrations | Third-party integrations (payments, email, CRM, telephony), webhook handling, retry logic, sprint 2 demo and retro. |
| Week 6 | Sprint 3; UX polish | End-to-end user flows, mobile responsiveness, accessibility pass (WCAG 2.1 AA), error states, empty states. |
| Week 7 | Sprint 3; Hardening | Performance tuning, load testing, SAST/DAST scan, dependency audit, sprint 3 demo, UAT begins on staging. |
| Week 8 | UAT + Go-live | UAT defect fixes, production cutover plan, runbook, rollback drill, deployment, monitoring switched on, stabilisation phase begins. |
The same things happen on the same days, every sprint.
Tickets sized, owners assigned, sprint goal written in one sentence. Notes to you by end of day.
Three lines per engineer in your Slack channel every morning: yesterday, today, blockers.
30 minute live demo of working software on staging. Recording and summary shared after.
What worked, what did not, what changes next sprint. Clients welcome, most attend.
20 minute working call with your project lead: decisions, priorities, escalations. Fixed weekly slot.
One-page change request states cost, time, and scope impact before work starts. You decide.
Agreed in writing during the architecture phase. R = Responsible, A = Accountable, C = Consulted, I = Informed.
| Activity | Client | RG INSYS |
|---|---|---|
| Discovery & requirements | R | A |
| Technical audit (legacy) | C, I | R, A |
| System architecture | C | R, A |
| Sprint planning | C | R, A |
| Implementation (code, tests, docs) | I | R, A |
| Code review & quality gates | I | R, A |
| Acceptance criteria sign-off | R, A | C |
| User acceptance testing (UAT) | R, A | C |
| Production deployment | C | R, A |
| Production operations & monitoring | R or shared | R or shared |
| Incident response (P1/P2) | I | R, A |
| Change requests & budget approvals | R, A | C |
Written into every Master Services Agreement; on-call coverage available as an add-on for production systems we operate.
| Channel / Severity | Response time | Resolution target |
|---|---|---|
| Slack (during your business hours) | Within 30 minutes | Same day for in-flight work |
| Email (general) | Within 4 business hours | Within 1 business day |
| P1; production down or data exposure | 30 minutes, 24x7 (with on-call retainer) | 4 hours target |
| P2; core feature impaired | 2 business hours | Next business day |
| P3; minor bug, cosmetic, or feature request | 1 business day | Within active sprint |
| Daily async standup | Posted by 10:00 your time | -- |
| Sprint demo | Every 2 weeks, scheduled in advance | Recording within 4 hours |
| Weekly client check-in | Fixed weekly slot | Notes within same day |
P1 incidents follow a written runbook, with a post-mortem within 5 business days and status updates every 30 minutes until service is restored.
The full SLA language is in our sample MSA.
Talk to a senior engineer about any phase, process, or SLA question.