Decision record
Decision: what we chose Context: what forced a choice Options: what else we considered Because: the premise it serves Revisit if: what would change it
London software studio · apps, web, interfaces
Start from what is true. Build what follows.
AxiomLabs designs, builds and publishes mobile apps, web platforms and interfaces. Before any code is written, we help you put the few things your product must get right into plain sentences. Every screen, service and release afterwards has a reason you can point to.
Why decisions come first
Most software that becomes expensive to change was not built badly. It was built quickly, in response to requests nobody had weighed against each other. A feature for one group quietly made life harder for another; a framework was chosen because it was familiar; a launch date was fixed before anyone checked what app review would ask for.
We slow down the first fortnight so the following months can move faster. The diagram shows the order in which we ask questions. Select any node to read what we write down at that point.
Compose your first premise
This is the opening exercise of every AxiomLabs discovery workshop, shrunk to fit a web page. Fill in the gaps and watch a one-paragraph product statement assemble itself. If the sentence feels awkward to read aloud, that is useful information: it usually means one of the parts is still undecided.
Nothing you type here leaves your browser. With optional storage accepted, it is remembered on this device only.
Premise draft
What you can ask us to do
Five kinds of work, each with the decision we help you make and what you hold at the end.
| Service | The decision we help you make | What you hold afterwards |
|---|---|---|
| Mobile apps | Native Swift and Kotlin, or one cross-platform codebase? Which device features are essential, and what happens offline? | Source code in your repository, a signed build pipeline, a written platform rationale. |
| Web platforms | One service or several? Which data is the source of truth, and who may change it? | An architecture note you can read in one sitting, deploy scripts, hosting in your name. |
| UI/UX design | Which journey carries the most risk, and how do we test it before building it? | Tested prototypes, a small design system with usage notes, accessibility annotations. |
| Publishing | What will Apple, Google or your hosting provider ask for, and when must it be ready? | Completed store listings, accurate privacy declarations, reviewer notes, a launch checklist. |
| Support | Which faults matter most, and which changes are worth making next? | Written triage for every report, maintenance releases, an updated decision log. |
Derive, then decide
A smaller version of the weighting matrix we use when a team is split between two approaches. Set how much each criterion matters to you, then score both options. The bars show which one your own priorities favour. It is a conversation aid rather than an oracle: a close result means the choice deserves a longer discussion.
Rename the options to compare anything: two hosting providers, a rebuild against a repair, or two designs for the same screen.
CriterionWeight
Time to first release
Platform-specific polish
One team can maintain it
Device feature access
How an engagement runs
Framing
One or two workshops with the people who fund, run and use the product. We leave with written premises, a list of open questions and a first idea of scope.
Structure
An architecture note, key interface flows and a release plan. Each is short enough to read over a coffee, and each says what we chose not to do.
Build
Fortnightly increments you can install or open, each with a written summary of what changed and which premise it serves.
Release
Store submission or web launch, prepared from the first week rather than the last. Accounts and keys stay in your organisation's name.
Keep
Handover documents, a walkthrough for your team and, if you want it, an ongoing support arrangement.
Why we write things down
People change roles, suppliers change, and memories of why a choice was made fade within months. A short decision record, written at the time, costs ten minutes and saves days of archaeology later. It also makes disagreement easier: it is much simpler to challenge a sentence on a page than a half-remembered conversation.
Our written outputs are deliberately small. A premise sheet fits on one side. An architecture note fits on two. A release plan is a checklist with dates. If something needs a longer document, that usually signals a decision that has not been made yet.
Everything we write belongs to you and lives in your own tools, whether that is a shared drive, a wiki or the repository itself.
From our notebook
Three templates we use constantly. Borrow them freely.
Bug report that gets fixed
Expected: what should happen Happened: what did happen Where: device, browser, version Since: when it started Who: how many people it affects
Release note people read
What is new, in one line What is fixed, in plain words What you might notice Where to report problems
Questions people ask before a first call
Do we need a finished specification before contacting you?
No. A rough description of the problem and who has it is enough. Turning that into a written premise is the first piece of work we do together.
Can you take over an app another supplier built?
Usually, yes. We start with a short review of the code, build process and store accounts, then tell you plainly whether we would repair, refactor or rebuild, and why.
Will we own the code and accounts?
Yes. Repositories, store accounts, domains and hosting are set up in your organisation's name from the start. We are invited in as collaborators.
How do you handle support after launch?
Reports come in through our support page or email during UK working hours, Monday to Friday 09:00 to 18:00. Each one gets a written triage note before any work starts.
Do you guarantee app store approval?
Nobody can. Approval decisions belong to Apple and Google. What we can do is prepare complete, accurate submissions, which avoid most delays. See publishing assistance.
Have a premise, or just a problem?
Either is a fine place to start. Tell us what you are working on and we will reply during UK office hours.