OUR PROCESS
How an engagement runs
The stages below are the ones we use on almost every build. They are documented so a client can hold us to them, and so a project can be picked up mid-way by someone who was not in the first conversation.
Stage five is a decision, not a handoff
THE STAGES
Each stage, in order
Stages 1 to 3 are reversible. After launch they are not, which is where most of the care goes.
Each stage produces something reviewable and ends with a decision to move on, revise or stop. Nothing advances because a date arrived.
- Discover Understand your goals, requirements and challenges.
- Plan Create a strategy, architecture and project roadmap.
- Design Create UI/UX designs and prototypes for a better experience.
- Develop Build robust, scalable and secure solutions.
- Test Ensure quality, performance and security.
- Launch & Support Deploy your solution and provide ongoing support.
What Happens at Every Step
What Happens at Every Step
Discover Understanding Your Vision
We start by learning about your business, goals, target audience and technical requirements. This helps us understand your needs and define the best approach for your project.
- Detailed consultation with your team
- Identify goals and key requirements
- Analyse challenges and opportunities
- Define scope and project objectives
Plan Strategy, Architecture and Roadmap
With the requirement agreed, we shape the approach: what the system will do, in what order, and what it will take to deliver it responsibly.
- Agree the delivery approach and constraints
- Define the architecture and data model
- Sequence the work into clear stages
- Confirm the commercial plan
Design User-Focused Interfaces and Prototypes
Design starts from how people will actually use the product. We turn the agreed scope into interface designs and clickable prototypes so decisions are made before code is written.
- Map the user journeys the system must support
- Produce wireframes and prototypes
- Review usability with the people who will use it
- Agree the interface before build
Develop Building the Solution
The build follows the approved design and architecture. Work is reviewed on a real staging environment rather than in theory, and documentation is written as the system is built.
- Build against the approved design and architecture
- Code review and staging review cycles
- Write documentation as the system is built
- Track progress against the agreed plan
Test Quality, Performance and Security
Before launch, the product is tested against the agreed requirements and the constraints that matter in use: quality, performance, security and accessibility.
- Functional testing against the agreed requirements
- Performance and load checks
- Security review of the delivered build
- Fix findings and retest before release
Launch & Support Going Live and Staying Useful
Launch includes deployment, guidance and a handover your own team can run. Support afterwards is agreed in advance, with maintenance and enhancement work planned rather than improvised.
- Deploy to the agreed environments
- Provide training and handover documentation
- Agree the support and maintenance plan
- Review and improve after launch
-
Client-Focused Approach
We keep your business goals at the centre of the project. -
Transparent Communication
We keep you informed throughout the journey. -
On-Time Delivery
We plan carefully and maintain clear project milestones. -
High-Quality & Scalable Solutions
We build with quality, maintainability and future growth in mind.
Written before the first sprint
CLIENT JOURNEY
Our Client Journey
From the first conversation to ongoing support, this is what happens and who is involved at each point.
- Initial Inquiry You reach out to us with your idea.
- Consultation We discuss your requirements.
- Proposal We share a detailed plan and estimate.
- Development We build your solution with regular updates.
- Launch We deploy and make it live.
- Ongoing Support We provide continuous support and improvements.
NEXT STEP
Bring us a problem, not a brief
Stage one exists so that neither of us spends money on the wrong problem. Bring what you know so far, including the parts that are not decided, and we will tell you which stage the work actually starts at.
Questions people ask us about this
A conversation about the situation, then a written summary of what we understood and what we still need to know. That summary is the first deliverable, and it is deliberately short, because a proposal written before the questions are answered is a guess with a price attached.
It depends on the size of the scope rather than on our availability, and we will give a range with the assumptions attached rather than a single confident number. What we commit to is progress you can see and a date we have thought about.
They are expected, and they are priced and scheduled rather than absorbed. Anything that changes the agreed scope goes into a written change note with its effect on time and cost, so nobody is surprised at the end.
The people you speak to during the project. There is no account layer between you and the developers, and if the person you agreed the work with is unavailable, you are told rather than given a substitute quietly.
You are told, weekly or at whatever interval suits, in writing. The process page describes the checkpoints, and the rule underneath them is that no status update should ever be the first time you hear that something is late.
Yes, on the real environments and with the real data volumes where we can. Testing is covered in more detail in the automated testing article, and it is part of the price rather than an extra.
Documentation that describes the system as built, credentials in your name, a repository you own, and a walkthrough with the people who will operate it. It is described in detail in the handover article.
You tell us and it gets looked at. If it is within the agreed scope we handle it as part of the delivery; if it is new work, we say so and price it separately rather than absorbing it quietly. The contact page is the fastest route.