From a business problem to a clear development plan.
A useful software project starts with the people who will use it, the work it needs to support and the constraints it must respect. Here is how we take it from there, in five stages.
Start with the work
Describe who needs the software, what they need to do and where the current experience falls short. An existing process, a new customer service or an internal tool can all be starting points.
- Who will use it?
- What should they be able to do?
- What would a useful first version achieve?
What you can expect: a short conversation, followed by a written summary of the problem, the users and what a useful first version would achieve. What we need from you: a description of your users and their main task, the tools already involved and the people who will approve decisions.
Define a practical first scope
Identify the essential user journey, the information involved and the systems the project needs to work with. Separate the first useful release from later improvements.
Where an existing tool or a configuration change can meet the need, that option should be considered before custom development.
What you can expect: a scoped first release — the essential journey, the systems it touches and what is deliberately left for later — with an estimate range and the assumptions behind it. What we need from you: decisions on what is essential, and access to anyone who knows your existing systems.
Make the experience reviewable
Use screen designs and bounded prototypes to make important decisions concrete. Review navigation, content, interactions and error states before expanding the scope.
What you can expect: screen designs and, where useful, a prototype you can click through. What we need from you: feedback from the people who will actually use the software, ideally before development begins.
Explore example workflowsBuild, check and refine
Organise implementation around reviewable increments. Check the agreed behaviour, mobile layouts, accessibility and relevant integrations, then address the findings before moving forward.
Acceptance criteria should describe what the software must do and how it will be checked.
What you can expect: working software in reviewable increments, checked against the agreed criteria, with findings fixed before the next step. What we need from you: timely review of each increment and one point of contact for decisions.
Plan for operation
Before launch, agree hosting, access, data handling, maintenance responsibilities and support arrangements. These depend on the project and must be defined explicitly.
What you can expect: a clear agreement on hosting, access, data handling and support before launch, not after. What we need from you: decisions on who owns the accounts and who will run the system day to day.
How we keep decisions visible
Ways to structure the work
Where AI fits
AI may be useful when a task involves variable language, documents or other inputs that are difficult to handle with fixed rules. Its usefulness must be evaluated against simpler alternatives and the consequences of an incorrect result.
For tasks that require professional judgement, define where human review remains necessary.
Fictional data · Simulated AI extraction
Explore the document review demoWhat helps us understand your project
- A description of your users and their main task.
- The tools or systems already involved.
- Any timing, budget or organisational constraints you want to share.
- The people who will review decisions and approve the result.
An initial conversation does not require passwords, client records or confidential documents.
Frequently asked questions
Do I need a finished specification before contacting you?
No. A rough idea is a perfectly good starting point. Part of the first conversation is turning it into a scope that can be estimated.
Can we start with something small?
Yes, and we would usually suggest it. A bounded first release lets you learn from real use before committing to a larger build.
What happens when requirements change?
Change is normal. New requests are weighed against the agreed first release and agreed in writing before work on them starts, so cost and timing do not change by surprise.
How will I know where the project stands?
You can try working software at each increment and see decisions written down. The rhythm of reviews is agreed at the start of the project.
What does support after launch look like?
It depends on the project and is agreed separately. Support, updates and improvements are not assumed to continue automatically beyond the agreed initial engagement.