Six phases. Predictable cadence. Clear ownership. Written SLAs. This is the same playbook we run on every project, whether it is a four-week MVP or a nine-month legacy redevelopment.
Every engagement moves through the same six phases. The duration of each phase scales with project size, but the structure does not change. You always know which phase you are in and what gets produced before the next one starts.
A 30 to 45 minute consultation with a senior engineer. We listen, ask sharp questions about constraints (regulatory, technical, commercial), and confirm whether we are the right fit before anyone signs anything. Within 48 hours you receive a written brief: scope, assumptions, exclusions, milestones, fixed price or rate-card estimate, and a recommended engagement model. No commitment, no sales pitch.
For legacy redevelopments we spend a structured week inside your existing system. We read the codebase, run static analysis, profile the database, document undocumented business logic, and produce an audit report. The report flags the things that will surprise a less experienced team mid-project: hidden cron jobs, fragile integrations, undocumented data shapes, dead code paths, and migration risks. Surprises get caught here, not in week six when they cost ten times more.
System architecture is finalised and shared as a written document with diagrams. Sprint plan agreed in writing. AI tooling stack configured (Claude Code, Cursor, GitHub Copilot, with project-specific guardrails). Development, staging, and CI environments stood up. The team is introduced to your stakeholders, Slack channels are created, and access is provisioned.
Two-week sprints. Working software demonstrated at the end of every sprint, not just status updates. Every sprint produces something you can click, test, and deploy to staging. Backlog grooming and sprint planning happen on the Monday morning of each new sprint. Every other Friday is a live demo and retro.
The full team stays on standby for 30 to 60 days after launch. Daily status reports during this window. Critical issues fixed within 4 hours. The old system, if there was one, is kept running in parallel as a fallback so we can switch traffic back instantly if needed. Stabilisation is included in the project fee, never billed separately.
An optional monthly retainer takes over after stabilisation. It covers bug fixes within SLA, dependency upgrades, security patching, monitoring and on-call, infrastructure reviews, and up to 8 hours of minor enhancements per month. You can pause, scale up, or cancel with 30 days notice.
Below is the actual structure of a typical 8-week MVP or focused module build. Larger projects scale by adding more sprint pairs (weeks 5–6, 7–8 repeat). The pre-sprint and stabilisation weeks do not change.
| 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. |
Sprints are predictable. The same things happen on the same days. You know when to expect a demo, when to send feedback, and when something can change scope without disrupting the team.
Backlog grooming and planning happens on the Monday morning of each new sprint. Tickets are sized, owners assigned, and the sprint goal is written in one sentence everyone agrees on. You receive the planning notes by end of day.
Posted in your shared Slack channel every morning your time. Three lines per engineer: yesterday, today, blockers. Async by default so we do not eat into your day with calls. Live calls are scheduled on demand.
A 30 minute live video demo at the end of each sprint. Working software, not slides. Every feature is clicked through on staging. Recording shared after, with a written summary of what shipped.
Held immediately after the demo. What worked, what did not, what changes next sprint. Action items are written down and reviewed at the next retro. Clients are welcome to attend, most do.
A 20 minute live call once a week with your project lead. Not a status meeting, a working call. Questions, decisions, priority changes, escalations. Time slot fixed at the start of the engagement.
Mid-sprint changes are welcome. They go through a one-page change request: cost, time, and scope impact stated before any work starts. You decide. No surprise invoices, no scope creep.
Ambiguity around ownership is the most common reason software projects slip. We agree this matrix in writing during the architecture phase so there is never a "I thought you were doing that" conversation. 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 |
The SLAs below are written into every Master Services Agreement. They apply during your business hours, with on-call coverage available as an add-on for production systems we operate.
| Channel / Severity | Response time | Resolution target |
|---|---|---|
| Slack & WhatsApp (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 |
For P1 incidents we follow a written runbook: acknowledge, triage, contain, communicate, restore, and post-mortem within 5 business days. Clients receive a status update at minimum every 30 minutes during an active P1 until service is restored.
If you need to reach us outside business hours, the WhatsApp number is the fastest path. The full SLA language is in our sample MSA.
Talk to a senior engineer. We will walk through any phase in detail and answer process and SLA questions on the call.