Built in your repository,
in your cloud account.
Two-week sprints, a demo and a written note at the end of each, and a change-control rule that means nothing gets built — or billed — without you approving it first.
The whole product,
not just the screens.
A SaaS product is roughly a third interface and two thirds everything nobody demos: permissions, billing edge cases, admin tooling, background jobs and the infrastructure underneath.
Application
- Web front end, responsive to mobile
- Application back end and business logic
- Authentication, sessions, roles and permissions
- Search, filtering, pagination and bulk actions
- File handling, uploads and document generation
- Notifications by email, in-app and WhatsApp where relevant
Commerce & accounts
- Subscription plans, trials and upgrades
- Payment gateway integration — Razorpay, Stripe, PayU
- Invoicing, GST handling and receipts
- Usage metering and limit enforcement
- Dunning, failed-payment recovery and cancellation flows
- Multi-tenant or multi-organisation structure
Admin & operations
- Internal admin console for your support team
- Impersonation, account repair and manual overrides
- Audit logging on anything consequential
- Reporting, exports and scheduled jobs
- Feature flags for staged rollout
- Configurable rules rather than hard-coded values
Platform & infrastructure
- Cloud environments: development, staging, production
- CI/CD pipeline with automated checks on every merge
- Database design, migrations and backup policy
- Monitoring, error tracking and log aggregation
- Secrets management and environment separation
- Cost review so the running bill does not surprise you
Two weeks, then
something you can click.
No silent months. Every sprint ends with working software in a staging environment you have access to, and a written note covering what shipped, what did not and why.
Sprint planning
The specification items for this sprint are confirmed, with acceptance criteria restated. You know exactly what will exist in fourteen days.
Build, review, test
Every change goes through code review and automated checks before it merges. Anything raised that sits outside the spec becomes a change request, not a quiet addition.
Internal QA pass
Tested against the acceptance criteria by someone who did not build it, on a clean environment with realistic data.
Demo
Thirty minutes, live, on staging. You use it yourself rather than watching a screen share of it working.
Build note and next sprint
Written summary: shipped, carried over, blocked, change requests raised, and the plan for the next fourteen days.
What “done”
means here.
A feature is not done when it works on a developer's machine. It is done when it meets every line below, and the acceptance criteria in the specification are the test.
- Meets the written acceptance criteria for that item
- Reviewed by a second engineer before merge
- Covered by automated tests where the logic warrants it
- Works at mobile and desktop breakpoints
- Handles the empty, loading, error and no-permission states
- Deployed to staging and verified there
- Documented where another developer would otherwise guess
Who actually
works on it.
A squad, not a rotating pool. The same people from kickoff to handover, with one of them accountable for the whole thing.
| Role | On the build |
|---|---|
| Delivery lead | Scope, sprints, change control, your single contact |
| Technical lead | Architecture, code review, security, infrastructure |
| Engineers | Front end and back end, sized to the scope |
| Designer | Through build, not just at the start |
| QA | Independent test pass every sprint |
Bring us the idea. We’ll bring back a scope you can hold us to.
A scoping call costs nothing and takes forty-five minutes. If the product does not need building yet, or needs building by someone else, we would rather say so in that call than three months into a contract.