The software your business couldn’t buy.
Web apps, desktop programs, and internal tools — scoped in writing, built in the open, and handed over whole.
Practice · Software
Everything the Software practice includes.
Scope & design
What it does and what it won’t, written down and designed before anything is built.
Web applications
Portals, dashboards, and the systems your team signs in to every day.
Programs & APIs
Desktop programs, internal tools your team opens, and the APIs that connect them.
Accounts & payments
Sign-in, roles, data, and payments — plus AI features where they do real work.
Care after release
Deployed to your accounts, then monitored, updated, and improved over time.
One practice.
Start the conversation
One standard.
One team.
The three, in full.
- 01 · Scope
Whether anyone wrote down what it does.
Custom builds usually go wrong before any code is written, in the gap between what was asked for and what was quoted. So scope comes first: the people who will use it, the jobs it has to do, and what it will not do, written down and signed. Sometimes the honest answer is that an existing product already does the job, and we say so before quoting.
- The people who will use it, and what they need from it
- Every flow mapped before a screen is designed
- What it won’t do, written as clearly as what it will
- An off-the-shelf option named where one would do
- A fixed quote against a signed scope
- Paid discovery first where the idea needs proving
- 02 · Build
Whether it survives daily use.
One stack, held properly: TypeScript, React, and Next.js, rather than whatever was fashionable this quarter. Sign-in, roles, data, and payments are designed before the interface, because that is where software actually breaks. Nothing is gold-plated: release one does the job it was scoped for, and release two is scoped on its own.
- Sign-in, roles, and permissions modelled first
- Data designed before the screens that show it
- Payments on accounts you own
- A staging link current at the end of every sprint
- Tested against the scope, not against a demo
- Web or desktop, whichever the job needs
- 03 · Handover
Whether it is still yours when we step back.
The last way a build fails is quietly: the code works, and nobody but its author can touch it. The repository sits in your organisation from the first commit, credentials stay in your accounts, and every release ships with a runbook plain enough for someone else to take over. Care keeps it monitored and current after that, if you want it to.
- The repository in your organisation from the first commit
- Keys in your accounts, never ours
- A runbook: how to run it, change it, and hand it on
- Monitored and kept current under a Care retainer
From written scope to handover.
- 01 · Weeks one and two
Scope in writing.
What it does, who uses it, and what it will not do, written down and signed before a line of code. If something off the shelf already does the job, you hear it here.
- 02 · Each sprint
Shown as it’s built.
Every sprint lands on a staging link you can open and click through, with a changelog saying what moved. You get something to use, not a status update about it.
- 03 · Release
Released properly.
Tested against the scope it was built to, deployed to your accounts, and switched on when it is ready rather than when the date says so. A date is a target, not a reason.
- 04 · Handover
Handed over whole.
The code, the repository, the documentation, and the credentials, all in your name. Care then keeps it monitored and current for as long as it earns its keep.
Nothing is built that was not written down, and nothing is handed over that has not been proven. You can open the work at every stage of it.
How we work this practice.
Scope it in writing. Build it in the open. Release when it’s proven. Then hand it over whole.
Most businesses don’t need custom software. The ones that do have usually found out the expensive way, with three subscriptions and a workaround standing in for the system they actually needed. We start by checking which one you are.
Then it is built properly: scoped in writing, built in the open, and handed over whole, with the code, the accounts, and the runbook in your name. This practice opened only once it met that standard. Any build beyond it is declined before it is quoted.
- Scope written down and signed before a line of code
- TypeScript, React, and Next.js — one stack, held properly
- Flows designed before screens, screens before code
- Built in the open, on staging every sprint
- The repository in your organisation from day one
- AI where it earns its place, never as the pitch
- Keys in your accounts, never ours
- A runbook written so someone else could take over
The no, said before the invoice.
We don’t build what you could simply buy.
If an existing product already does the job well, we say so before quoting. Paying to rebuild a subscription is an expensive way to own a worse one.
We don’t take on what we can’t finish properly.
Platforms that need a full team to build and run are not this practice. If a build is beyond us, you hear it before the invoice, not halfway through the build.
We don’t write code only we can read.
Conventional, documented, and handed over with a runbook. Software nobody else can maintain is a dependency with a login screen.
We don’t price what nobody has written down.
A fixed price on an unwritten scope is a guess with a deposit. Where the idea needs proving first, a paid discovery comes before the number.
Straight answers.
Yes, outright, on final payment — the code, the designs, and the documentation. The repository and every account it runs on are in your name from the start, so nothing is ever held hostage.
Most first releases run six to twelve weeks from a signed scope. Larger builds are split into releases, so something useful is in your team’s hands early rather than everything arriving late.
Builds are scoped in writing and quoted before they start. Where the idea needs proving first, a paid discovery or prototype comes before the quote. After release, Care runs monthly, and a standing build allocation can too.
Sometimes. We read the code before we quote, and tell you plainly whether it can carry the standard or whether rebuilding it on our stack would cost you less.
Not yet. Web apps that work properly on a phone, yes. Native mobile opens when it can be held to the same standard as everything else — never before.
Platforms that need a full team to build and run, and anything crypto, blockchain, or Web3. If a build is beyond what we can hold to the standard, we say so before quoting.