A first version needs boundaries.
Trying to include every future feature makes it harder to learn what matters. We keep a visible backlog and agree what can wait.
Digital products.
Have an idea for a tool people would use? We work out the smallest useful version, test it, and build from there.
Make the first useful version of your idea.
We help turn an idea into a working digital product: a customer portal, internal tool, booking flow, or a new service people use online. The first job is to understand who it is for and what they need to get done.
We decide what belongs in the first version, test the important journeys, and build in small, reviewable pieces. You see the work as it develops, and real feedback helps decide what deserves more time after launch.
From first idea to daily use.
A customer portal that replaces a chain of status emails.
An example of a first release focused on submitting and tracking one kind of request.
Submit a request
A customer signs in, provides the information your team needs, and sees that the request has been received.
Move the work forward
Your team reviews the request, assigns it, and updates its status through a focused internal view.
See what changed
The customer can check progress and respond to questions, with access limited to the information they should see.
How we’ll work
together.
8–12 weeks
A focused first release with a few core journeys.
Weeks 1–2
Find the first useful version.
We talk through the problem, speak with intended users where possible, and decide what the first release needs to do.
Weeks 3–4
Try the key journeys.
We make an interactive prototype, test the main flows, and settle the rules, roles, and data the product needs.
Weeks 5–9
Build in working pieces.
We develop the agreed journeys, connect the necessary tools, and review usable progress with you throughout the build.
Weeks 10–12
Release and learn.
We test permissions and important cases, prepare the handover, and launch to an initial group before deciding the next priorities.
The number of workflows, permissions, integrations, and unknown technical requirements affects the plan. Discovery may show that a prototype should come before a production build. We agree dates after scoping the work.
What you get.
We agree what’s included before starting.
Release plan
A first-release scope and prioritized backlog.
Interactive prototype
User journeys and an interactive prototype.
Interface system
Interface designs and reusable components.
Working product
The agreed working product and integrations.
Tested core journeys
Checks for core flows, permissions, and failure cases.
Code & handover
Source code, deployment guidance, and a handover.
What we need
from you.
- Access to intended users or people who know their work
- A decision-maker who can choose priorities and review progress
- Business rules, example data, and relevant system access
Things to consider.
A few things to agree before we start.
Useful does not automatically mean adopted.
A product needs to fit real habits. Testing with users, clear onboarding, and a plan for introducing it are part of the conversation.
Software needs care after launch.
Hosting, dependencies, support, and new requirements continue after the initial build. We agree who will own those responsibilities.
Common questions.
Something else on your mind?
How do you estimate a product that is still an idea?
We start with the people using it and the first job it needs to do. That gives us a smaller release to scope and estimate. If a technical question could change the budget, we test that before committing to the full build.
How long does a first release take?
A focused first release often takes eight to twelve weeks. That depends on the core journeys, integrations, and testing needed. We agree a release plan after working through the scope.
Will we see the product before launch?
Yes. We share designs and working versions during the build. You can try the main journeys and give feedback while there is still time to change them.
Can you build on our existing product?
We can begin with a review of the code, access, and current problems. Then we agree whether to extend what is there, replace a specific part, or start with a separate prototype.
Can we start with a prototype?
Yes. If the main uncertainty is whether people understand or need the idea, a prototype can be a useful first project. We agree what it should test and avoid presenting it as production-ready software.
What if priorities change during the build?
We review the effect on the agreed scope, time, and budget. A new feature may replace something planned for the first release or become a separate next step.
Can our own team take over later?
We plan the handover around your team’s needs, including source access, setup instructions, and the services the product depends on. Ownership and third-party licensing are set out in the project agreement.