How We Work
Our approach
We follow a consistent four-phase methodology across all engagements. It is designed to reduce risk, surface problems early and ensure you are never surprised.
Four phases, every engagement
Whether you are building a production ML system or migrating a data platform, the same four phases apply — scaled appropriately to the complexity and duration of the work.
Discover
Understand the real problem
We spend time understanding your business context, technical constraints and success criteria before writing any code. This is where we ask uncomfortable questions — about your data quality, your team's ability to maintain what we build, and whether the proposed solution is the right one.
Typical outputs
- • Problem and success criteria definition
- • Architecture options with trade-off analysis
- • Data and infrastructure audit
- • Risk register and open questions log
Duration
Typically 1–2 weeks, depending on scope. For well-defined work this can be compressed into a structured kickoff.
Design
Architecture decision records before code
We document key decisions in architecture decision records (ADRs) so there is a permanent record of what was decided and why. This prevents the "why did we do it this way?" problem eighteen months later. Design reviews happen with your team, not just internally.
Typical outputs
- • Architecture decision records (ADRs)
- • System design diagrams
- • Evaluation strategy (for AI work)
- • Cost model and capacity plan
- • Sprint plan for the build phase
Duration
Typically 1–3 weeks. Larger architectural decisions may require a spike to validate assumptions.
Build
Iterative delivery with clear gates
We work in two-week sprints with weekly check-ins. Code goes into your repository from day one — you own it and can see it. Every sprint delivers working, tested software against agreed acceptance criteria, not "percentage complete" status updates.
How we work
- • Code in your repo, deployed to your infrastructure
- • Weekly written status update + async comms
- • Sprint review with your team every two weeks
- • PR reviews open to your engineers
- • Eval gates for AI work (no ship without passing)
Escalation
Blockers get escalated within 24 hours. We do not let problems sit — we surface them early so they can be resolved early.
Operate
Production-ready hand-off or retained support
A working prototype is not a production system. We ensure everything we build is observable, documented and supportable before it goes live. At the end of an engagement you can choose a clean hand-off to your team or retained support from us.
Typical outputs
- • Runbooks and operational documentation
- • Monitoring dashboards and alert runbooks
- • Knowledge transfer sessions with your team
- • 30-day stabilisation support window
Ongoing support
Retained support engagements available on a monthly basis for monitoring, retraining, incident response and iterative improvements.
Engagement models
We offer three ways to work together. The right choice depends on your timeline, level of internal resource and how well-defined the problem is.
Fixed Scope
Project delivery
Best when you have a clear outcome and timeline. We scope, price and deliver to a defined specification. Changes are managed via a formal change control process.
- ✓ Fixed budget and timeline
- ✓ Clear acceptance criteria
- ✓ Milestone-based payments
Recommended
Time & materials
Best for complex or evolving work where the full scope is not clear up front. You buy engineering time and direct it sprint by sprint. Most transparent and flexible arrangement.
- ✓ Maximum flexibility
- ✓ Fortnightly billing
- ✓ Pause or scale as needed
Ongoing
Retained support
A monthly retainer for teams that need ongoing engineering support, incident response or iterative improvements after initial delivery.
- ✓ Guaranteed availability
- ✓ Defined SLA for response
- ✓ Monthly review cadence
What you can expect from us
Weekly written updates
Every Friday you receive a written summary of what was done, what is next, and any open questions or blockers.
Code you can read
All code is in your repository, reviewed and commented. No black boxes, no IP held back.
Honest status reporting
We report problems when they surface, not at the end of the project. Green/amber/red status with clear reasoning.
Decisions in writing
Key architectural and technical decisions are documented in ADRs so the rationale is preserved long after the engagement ends.
Outcome accountability
We measure success against outcomes, not outputs. Time billed is not the metric — results are.
Pragmatic recommendations
We will tell you when a simpler approach would serve you better, even if it means less work for us.
Ready to get started?
Tell us what you are working on and we will be straight with you about whether we are the right fit.