The process
Six steps. No surprises.
This is exactly how a build runs, start to finish, for a BC business or public body commissioning software instead of renting it. One fixed price. Working software at every check-in. The code in your name at the end.
- 6
- Steps, end to end
- 1 day
- First written reply
- $0
- Cost to find out
- 100%
- Code and IP to you
The arc
From first email to handover.
Six discrete steps. Each one ends with something concrete you can look at and approve before the next one starts.
How long the whole thing takes depends on scope. A focused automation is a matter of weeks. A system that runs an operation is staged into milestones, and the schedule is written into the proposal before you sign it rather than discovered along the way.
Free teardown
You describe how the business actually runs, and we come back with pointed questions about the tools you pay for, where work falls through the cracks, and what people are doing in spreadsheets because the software will not. Within one business day you get a written summary of what we found, what we would build, and which of your current tools we think you should keep renting. It costs nothing, there is nothing to sign, and there is no call to schedule first.
Scope and one fixed quote
We define exactly what gets built, what it does on day one, what it deliberately does not do yet, and what it costs. You get a single fixed number, not a range and not an hourly rate. If paying it up front is the obstacle, this is where we structure it over two years at roughly what you already spend on the subscriptions it replaces.
Agreement and kickoff
Sign, and work starts inside a week. You talk directly to the person building your software. There is no account manager in the middle relaying requirements, and no discovery phase that bills for six weeks before anything runs.
Build, in milestones you sign off
Work is broken into milestones with a regular check-in on each one. At every check-in you see working software, not slides and not a status report. Billing follows the milestones, so nothing is invoiced for work that has not shipped. Changes get caught while they are cheap instead of after launch.
Your people test it on real work
Before anything goes live, the people who will actually use it run their real workflows through it. What they find gets fixed. Revisions inside the agreed scope are not nickel-and-dimed, because a build that technically matches the spec but does not fit the job is not finished.
Migration and handover
We move the data and check it against the old system. Migration of your existing data is scoped and priced as part of the build, not discovered later, and the time we need from your team is agreed up front. At handover you receive the full codebase, the hosting credentials, and documentation written so any competent engineer can pick it up cold. The source, the data, and the accounts are in your name.
Working software. Not slide decks, not status updates, not a promise about what is coming next sprint.
After handover
What happens when something breaks.
The answer most shops will not give you before you sign. There is no mandatory monthly fee to keep the lights on, because a support subscription is a smaller version of the thing you are leaving.
Walk away clean
Take the code and owe nothing. You hold the source, the accounts, and documentation good enough to hand to any other developer. Nothing stops working because you stopped paying us.
Or keep us on, quoted per request
No hourly rate. Each piece of work after handover is quoted in writing before it starts, with response terms agreed before handover, not invented the day something goes wrong.
Triaged by severity
Critical means the business cannot operate: picked up immediately. A simple change goes into the next available week.
The full support and financing model, including why we publish the model instead of a rate, is on the pricing page.
If you are a public body
The same six steps, entered through procurement.
The build process does not change for government work. What changes is the front door. Because we are already pre-qualified, a ministry or agency has permission to invite us to a limited competition rather than starting from a full open one. A pre-qualification is permission to be invited, not a contract award.
Step one is often earlier than this page implies. If the question is whether an existing system should be extended or replaced, that gets answered by a fixed-price condition assessment first, and the six steps below only start if the answer turns out to be a build.
OAG-RFQ-26-068
Runs to 2030-07-07
Pre-qualified supplier to the Office of the Auditor General of British Columbia
Digital Services. Qualified in three categories: Public Cloud Services, Application and System Design, and AI Readiness and Adoption.
ON-003317-03
Pre-qualified, Province of British Columbia Multi-Use List, Service Area 3
Software Development and Testing. The provincial standing list ministries draw from when they scope a build.
BC Digital Marketplace
Registered supplier
Listed on the province’s marketplace for digital opportunities, so BC public bodies can find and invite us directly.
Delivery in progress
We hold an active contract with a Canadian provincial government ministry, client name withheld under contract confidentiality.
To be exact about what the first three are: a pre-qualification is permission to be invited, not a contract award and not a guarantee of work. It means the province has already reviewed us against its criteria and cleared us to bid. What it gives a ministry is permission to invite us to a limited competition, not a shortcut past one.
Why it works this way
Four things we will not bend on.
Fixed price, never hourly
Hourly billing pays a shop to take longer. One quoted number, agreed before kickoff and billed by milestone, pays it to ship the right thing. Work outside the agreed scope is quoted separately, in writing, before it starts. Nothing inside the agreed scope is ever re-billed.
You own the outcome
Source code, data, hosting accounts, documentation. All of it in your name at handover. We do not build dependency into the delivery and call it a support plan.
You talk to whoever is building it
No account layer, no ticket queue between you and the code. When you ask why something works the way it does, the answer comes from the person who made that decision.
No overhead in the invoice
The people on your build are the people you pay for. Anyone added is named to you and approved by you before they start, with their cost already inside the fixed price.
Step one starts here
Free teardown. In writing. Zero obligation.
We go through your current systems, ask the pointed questions, and send back a written breakdown of what we would build and what it would cost. If the honest answer is that you should keep what you have, that is what the write-up will say.