Process
How We Work
Five stages. Scope is agreed in writing at stage three, before anything gets built.
Understand the goal
We start with the decision or the workflow, not the dataset.
- You provide
- The problem in your own words, and the decision the output should support.
- We produce
- A written statement of the goal, and our first read on whether we are the right fit.
- Approval point
- You confirm we have understood the problem.
- What usually goes wrong here
- The goal is a tool ("we want a dashboard") rather than a decision. We will push back until it is a decision.
Inspect a sample
A small, safe sample tells us more than any amount of description.
- You provide
- One representative file or page. Not the full dataset, and nothing sensitive.
- We produce
- An assessment of structure, quality, volume and the constraints we found.
- Approval point
- You agree the sample is representative of the whole.
- What usually goes wrong here
- The sample is the tidy one. Send the messy file — it is the one that sets the effort.
Confirm scope
Deliverables, exclusions, assumptions, revisions and timeline, in writing.
- You provide
- Sign-off on the scope, and the deadline that actually matters.
- We produce
- A written scope and a quote, with the exclusions as explicit as the inclusions.
- Approval point
- You accept the scope in writing before any build starts.
- What usually goes wrong here
- A requirement surfaces after sign-off. It becomes a change request, priced separately — never absorbed silently.
Build and validate
We build, then we try to break it before you see it.
- You provide
- Access to the agreed data, and answers to the exceptions we raise.
- We produce
- The deliverable, plus the reconciliation showing headline figures match your source.
- Approval point
- You review against the scope, not against new ideas.
- What usually goes wrong here
- Source data changes shape mid-build. We stop and re-scope rather than quietly absorb it.
Hand off or maintain
You own the file, and somebody on your side can run it.
- You provide
- One person to be walked through the refresh.
- We produce
- Files, documentation, refresh guide, and a walkthrough session.
- Approval point
- Your named person runs the refresh once, themselves, before we close.
- What usually goes wrong here
- Nobody is nominated to own it. A system with no owner stops being refreshed within two periods.
FAQs
Questions worth asking before you hire anyone.
Including the ones with answers that cost us something to publish.
What files do you need from me?
To quote: one representative file or page — the messy one, not the tidy one. To build: the sources behind it, in whatever format they already exist. Excel, CSV, Google Sheets, a system export, a PDF or a scan all work. We will tell you what is needed before any full-file transfer, and we would rather see a small sample first than a full dataset we have not yet agreed to handle.
Why is there no file upload on your quote form?
Because we have not built file storage we are willing to make promises about. Until we have, a share link you control — Google Drive, OneDrive, WeTransfer — is safer for you than an upload box on a marketing site: you can see who opened it and you can revoke it. Ask us on the form and we will send an address to share with.
How many revisions are included?
Every package states its own allowance, and it is on the package card rather than buried in terms. A revision means a correction against the scope we agreed. A new requirement is a change request, priced separately — we will always tell you which one we think it is before doing the work, not after.
Stage one is a conversation, not a commitment.
Describe the problem. If a sample makes sense we will ask for one, and if we are not the right people for the job we will say so at that point rather than later.