// Methodology
How we work
Our approach to building software. Not a methodology deck — a description of how we actually run projects, communicate with clients, and hold ourselves accountable to delivery.
// Delivery process
Our delivery process
Discovery & Specification
Week 1–2
We spend the first sprint understanding the problem before touching code. This includes stakeholder interviews, technical architecture review (for existing systems), user research review, and a written specification document that defines scope, technical approach, and acceptance criteria.
Design & Architecture
Week 2–4
Design and engineering proceed in parallel. Designers produce low-fidelity wireframes before high-fidelity mockups — getting structural feedback early before investing in visual polish. Engineers finalise the technical architecture, database schema, and API design in parallel.
Iterative Development
Ongoing sprints
Two-week sprint cycles with a consistent rhythm: planning on Monday, daily standups, midpoint check-in, review and demo on Friday. Each sprint delivers working software that is reviewed by the client before the next sprint begins — no month-long silences.
Quality Assurance
Embedded throughout
QA is not a phase — it is embedded in our process. Automated tests cover unit, integration, and critical end-to-end paths. Every PR is code-reviewed before merge. Performance and accessibility checks are part of our definition of done.
Launch & Handover
Week -2 to launch
Pre-launch is a structured process: final stakeholder review, production environment setup, staging-to-production deployment validation, monitoring configured, and go/no-go against the acceptance criteria. Handover includes codebase documentation, runbooks, and a training session.
Managed Maintenance
Ongoing, optional
After launch, clients can move to a managed maintenance engagement — SLA-backed support, monthly bug fix cycles, dependency updates, and proactive monitoring. Most long-term clients continue with quarterly enhancement sprints alongside the managed service.
// Working principles
What we believe about client work
Honest estimates
We give estimates based on actual complexity, not what we think clients want to hear. Estimates include explicit uncertainty ranges and assumptions.
Async by default
Most communication happens asynchronously through Slack and Linear — preserving deep work time for engineers and designers. Meetings are for decisions, not status updates.
No scope creep without acknowledgement
When scope changes, we raise it explicitly — not silently absorb it and deliver less. Scope changes are discussed, sized, and either accepted or deferred with the client.
Own the outcome, not just the output
We care whether our work achieves its objective — not just whether we delivered the spec. If something is not working, we raise it. We partner with clients for results.
Write things down
Decisions, architecture choices, and meeting outcomes are documented. A team with good documentation is a team that can onboard, maintain, and improve their systems without tribal knowledge.
Continuous feedback
Weekly written status updates, fortnightly sprint reviews, and a structured project retrospective at the 90-day mark. Feedback surfaces problems when they are still small.