The problem comes before the technology.
We choose the stack after we understand what the business needs and what the people using it need to do.
How We WorkFIELD GUIDE / 01
From the first messy conversation to a working release
Howwe work.
No mystery process. No packages pretending every business has the same problem.
We find the useful first version, price that project clearly, build it where you can see it, and stay responsible through launch.
Follow the processStart
The business problem
Middle
Visible working software
Finish
A controlled launch
THE PRINCIPLE
A package starts with what an agency wants to sell. A good project starts with what your business needs to change.
You do not buy a package. We shape the right first version.
THE PROCESS / 01—06
From problem to working product.
The shape changes with the project. The discipline does not: understand, focus, agree, build, prove, launch.
- 01
Context
Show us what is broken, slow, or missing.
You do not need a polished brief. Bring the messy version: the manual work, the missed opportunity, the idea that will not leave you alone, or the current system everyone has learned to tolerate.
A shared understanding of the real problem - 02
Shape
Define the first version worth building.
We separate the essential journey from the tempting extras. The goal is not to make the project smaller for the sake of it. It is to make the first release focused enough to finish, test, and learn from.
A focused scope with clear priorities - 03
Commit
Agree on the work before the work starts.
You receive a written proposal covering the scope, project price, timeline, ownership, ongoing support, and any third-party running costs. If something is uncertain, it is named instead of buried.
A proposal you can make a decision from - 04
Build
Watch the real thing take shape.
We work in visible stages and show progress in the product itself. You react to screens, journeys, and working behaviour rather than trying to imagine the final result from a document.
Regular working previews and direct decisions - 05
Prove
Test the journey that matters most.
Before launch, we walk through the real customer and operations journeys, check the awkward cases, test across the devices that matter, and fix the details that make software feel trustworthy.
A launch-ready product, not a presentation - 06
Launch & run
Go live with somebody still responsible.
We handle the launch, document what matters, and stay close while the first real users arrive. Ongoing hosting, maintenance, and improvement can stay with us or move in-house on terms agreed upfront.
A controlled launch and a clear ownership plan
PROJECT-BASED PRICING
Priced individually. Explained clearly.
A landing page, a booking platform, and an operations system are not the same product. Their prices should not pretend to be.
Once the scope is clear, you receive one proposal covering the build cost, timeline, support options, and third-party running costs. No package theatre and no surprise invoice halfway through.
01
Scope
How many journeys, screens, roles, and edge cases the first release needs.
02
Complexity
The business rules, permissions, data, and decisions the product must handle.
03
Connections
Payments, messaging, AI, CRMs, external APIs, and existing systems.
04
Running costs
Hosting and third-party tools such as AI, email, SMS, maps, and storage.
BEFORE YOU SAY YES
The proposal names the deal.
01
What the first release includes
02
What it deliberately leaves for later
03
The project price and payment schedule
04
The working timeline and decision points
05
Ownership, handover, and access
06
Optional support and external costs
WORKING RULES
What does not change.
Different projects need different shapes. These rules keep the relationship understandable on all of them.
You see the work while it is still changeable.
Working previews replace long periods of silence and a dramatic reveal at the end.
Your product stays yours.
Your brand, content, accounts, data, and commissioned product are not held hostage by the relationship.
YOUR TURN
Describe the problem