Skip to content
§ 01 / 04 Process

Five stages.
No surprises.

Software projects rarely fail on the code. They fail because nobody wrote down what was being built, decisions were made twice, and the client did not see the thing until it was too late to change. Every stage below exists to close one of those gaps.

01 02 03 04 DELIVERABLE REVIEW GATE
Fig. 01 — Increment structure — every stage ends in a deliverable and a review gate
§ 02 / 04 — Stages

The
stages

Typical total
8–24 weeks

  1. Scoping

    1–2 weeks

    We establish what is actually being solved before anyone writes code.

    A short paid engagement where we interview the people who will use the system, audit what exists, and map the constraints — regulatory, technical, budgetary, political. The output is a written scope, an architecture proposal, a risk register, and a fixed price. If the honest answer is that you should buy something off the shelf instead, we tell you and you keep the document.

  2. Architecture

    1–2 weeks

    Decisions get made once, in writing, before they get expensive.

    Data model, service boundaries, hosting, authentication, and integration contracts are specified and reviewed with you. We produce architecture decision records so that in two years someone can read why a choice was made rather than guessing. This is where we identify the parts of the system that will be hard to change later and make sure those parts are right.

  3. Build

    4–16 weeks

    Two-week increments, each ending in something you can use.

    Work ships to a staging environment continuously. Every second Friday you get a working build, a written changelog, and a call. There is no phase where the project disappears for three months. Code review, automated testing, and CI run from the first commit — not retrofitted before launch.

  4. Launch

    1–3 weeks

    Production, with the operational work done properly.

    Monitoring, alerting, backup and restore procedures, rollback plans, and load verification. For published titles this is where store submission, staged rollout, and release-day coverage happen. We do not consider a launch complete until we have restored from a backup at least once to prove it works.

  5. Operate

    Ongoing

    Support with defined response times, or a clean handover.

    Choose a retainer — defined response times, a monthly maintenance window, and a roadmap review — or take full ownership with a documented handover, credential transfer, and a paid onboarding period for your own engineers. Both are legitimate outcomes. We will not build a dependency you did not ask for.

§ 03 / 04 Cadence

What you get, and when

Interval Deliverable
Every second Friday A working build on staging, a written changelog, and a call.
Every sprint An updated risk register — what changed, what is now more likely to bite.
On every decision An architecture decision record: the choice, the alternatives, and why.
Monthly A burn-down against the fixed quote. If scope is drifting, you hear it that month.
Before launch A runbook, a rollback plan, and a restore-from-backup rehearsal.
At handover Credentials, documentation, and a paid onboarding period for your engineers.
§ 04 / 04 Questions

Questions we are always asked

01 What does a typical engagement cost?

Scoping engagements run $4,000–$12,000 CAD depending on complexity and produce a fixed quote for the build. Most custom builds land between $40,000 and $250,000 CAD. Retainers start at $4,500 CAD per month. We quote after scoping rather than before, because a number given without understanding the problem is a guess.

02 How long before we see something working?

A usable build in a staging environment within the first four to six weeks of the build phase, and a working increment every two weeks after that. You will not go a month without seeing the software.

03 Do we own the code?

Yes, without exception. Intellectual property transfers to you on payment, repositories live under your organisation, and cloud infrastructure sits in accounts you own and bill. This is written into every contract we sign.

04 What are the terms of a publishing agreement?

Revenue share, term length, territory, and platform scope are negotiated per title and depend on what we take on — a launch-only engagement is priced differently from full publishing with ongoing marketing. Rights revert to you at the end of the term. We will walk you through the full agreement before anything is signed.

05 Can you work with our existing engineering team?

Regularly. We embed alongside in-house teams, take ownership of a discrete subsystem, or provide architecture review and mentoring. We adapt to your standards, your review process, and your tooling rather than importing ours.

06 Do you work with clients outside Canada?

Yes. We are based in Acton, Ontario and work with clients across North America and Europe. Contracts are governed by Ontario law unless otherwise agreed, and we hold core collaboration hours in North American time zones.

07 What happens if we want to stop working together?

You receive a documented handover: repository access, infrastructure credentials, architecture records, runbooks, and a paid onboarding period for whoever takes over. There are no exit fees and nothing is withheld.

Ask us something else