How We Work

Phase 1: Research and Scoping

This is the most important phase of any project, and the one we refuse to rush.

Before we discuss technology or write a line of code, we need to properly understand your business — how it works today, where the friction is, and what a good outcome actually looks like. That means talking to the people who do the day-to-day work, not just the people who commissioned the project. The clearest view of what needs to change usually comes from the people closest to the problem.

We ask a lot of questions during this phase, including some that might seem obvious. That's deliberate — assumptions are where projects go wrong, and what looks straightforward from the outside often has unexpected complexity once you dig into it. Equally, what looks complex sometimes has a surprisingly simple solution.

Depending on the size and complexity of the project, this phase typically takes between one and six weeks. At the end of it, we have a thorough understanding of what needs to be built and why — which is the foundation everything else depends on.

Phase 2: Design and Specification

With a clear picture of your requirements, we move into designing the solution — mapping out the technical architecture, choosing the right platforms and technologies, and planning how everything fits together.

We're not just solving today's problem. Every decision at this stage considers how the system will behave as your business grows — whether it will scale, how it will integrate with future systems, and whether it can adapt as your processes evolve.

This phase ends with a detailed proposal: what we'll build, what it will cost, and how long it will take. No vague estimates, no scope that expands after you've signed anything — a clear and specific plan that both sides understand before work begins.

Phase 3: Build and Test

Once the proposal is agreed upon, development begins. You'll have a lead developer as your primary point of contact throughout — someone who understands the full picture of what's being built and why, not just their piece of it.

We keep clients closely involved during development through regular review sessions, typically weekly or fortnightly. These aren't just progress updates — they're opportunities to catch anything that needs adjusting before it becomes embedded in the system. Issues that surface early cost a fraction of what they cost to fix later.

Phase 4: Release and Acceptance

Before go-live, there's a structured acceptance period — typically two weeks — where you and your team use the system with test data, work through real scenarios, and satisfy yourselves that everything behaves as it should. We're available throughout to address anything that comes up.

Only once you're satisfied does the system go live, including the migration of your real data into the new system.

A note on scope

The proposal we produce at the end of Phase 2 defines what gets built. We work to that scope, and if your requirements change during development — which sometimes happens — we'll discuss the implications honestly rather than absorbing changes silently and presenting a larger bill at the end.

Software is never really finished — and that's a good thing

Almost every client we work with comes back to us after go-live, sometimes within months, sometimes a year or two later. Requirements change, the business grows, new opportunities emerge, and what was the right solution at the start evolves into something that needs extending. That's not a failure of the original build — it's just how businesses work.

The advantage of custom software is that it can change when you need it to, not when a vendor decides to release an update. You're not waiting for a feature to appear on a product roadmap, or paying for a premium tier to unlock something your business needs. If you want something added, changed, or improved, we can do it — and because we built the system in the first place, we can do it efficiently and without disrupting what's already working.

Most of our clients think of their software less as a one-off project and more as an evolving asset. That's exactly what it should be, and it can become addictive. Once you have software that does exactly what you need, the natural next thought is 'what else could we improve?' We consider that a good sign