How We Work
Here is exactly how we work.
Not a summary, and not a sales overview. The actual method, the commitments we make, and how a working relationship is structured.
Why we publish this
Research by the OECD into technology adoption among UK small and medium-sized businesses found that trust in technology vendors sits alongside cost and perceived relevance as a primary barrier to adoption. We take that seriously. Publishing the method is the most direct answer we have.
Figures cited are drawn from published sources and are correct at the date of publication. The source is named alongside each figure.
The seven stages
- 1
Listen
We start with the business problem, the people it affects and the constraints you are working under, not with technology.
You receive: a written summary of the problem as we understand it, so you can correct us before anything else happens.
- 2
Define
We establish what should be built, what should not, and what success actually looks like.
You receive: documented requirements, clear scope boundaries, indicative cost and a delivery plan.
- 3
Design
We design the experience before writing software, and test the thinking with real users where the engagement warrants it.
You receive: wireframes, interface designs, and a clickable prototype where appropriate.
- 4
Build
We develop in phases and show you working software regularly, rather than presenting everything at the end.
You receive: regular demonstrations, visible progress, and early access to working functionality.
- 5
Prove
We test for function, security, accessibility and real-world use, including manual testing, not just automated checks.
You receive: test results, accessibility findings, and agreed acceptance against defined criteria.
- 6
Launch
We deploy carefully, with a rollback path and a plan for the first weeks of live use.
You receive: a live system, handover documentation, and training suited to whoever will use it.
- 7
Support and improve
We monitor, maintain, fix and improve. The relationship continues, because this is when software actually has to work.
You receive: ongoing support, agreed response expectations, and a route for future development.
What we commit to, on every engagement
- 01
Requirements are written down before development begins, and shared with you.
- 02
Accessibility and data protection are designed in, not retrofitted before launch.
- 03
You own your data, and you can export it.
- 04
Intellectual property arrangements are agreed in writing before work starts.
- 05
We name our assumptions and our risks rather than discovering them jointly at the end.
- 06
If we believe you should not proceed, we will say so before you spend money.
How engagements are structured
Discovery
When you understand the problem but not yet the solution.
You receive a documented recommendation, scope, indicative cost and delivery approach. The deliverable is the document, not a commitment to build anything with us.
Project delivery
When scope is defined and the outcome is agreed.
A defined build, delivered in phases, with documented requirements and acceptance criteria.
Retained partnership
When you need ongoing capability rather than a single build.
Agreed monthly capacity covering maintenance, improvement and advisory support.
Support and maintenance
When a system is live and has to stay reliable.
Monitoring, fixes, updates and defined response expectations.
How we communicate
You deal with the people doing the work, not an account manager relaying messages. We hold a scheduled check-in at an agreed cadence, and you can see progress between those. If something slips, you hear it from us before you notice it yourself.