Home / Approach
How the work actually runs.
Written scope before anything starts, visible progress at every checkpoint, and a handover your own people can carry. Below is what that means in practice.
01 Four stages
Nothing significant happens before the scope is signed.
3
Service lines
Custom software, consulting, and product development, drawn on in whatever combination the job needs.
1
Point of contact
The same person from the first conversation through to handover. No reassignment once the work is agreed.
0
Work before scope
Nothing substantive begins on a handshake, an email, or an assumption about what was probably meant.
01
Conversation
No charge
What you are after, what is already in place, and how you will judge whether it worked.
02
Written scope
Signed first
Deliverables, dates, fees, ownership, and an explicit list of what sits outside the job.
03
Build in visible pieces
Reviewed as it lands
Something running at each checkpoint rather than a percentage in a status email.
04
Handover
Documented
Notes, source material, and enough walkthrough that your own people can carry it.
02 Shape of a job
Rarely one clean new system.
Usually a new piece that has to live alongside several older ones without anybody entering the same information twice.
The usual shape of a job. What you already run keeps running. One integration layer stops the same information being entered twice. The application is the part built around how you actually operate.
03 Problem patterns
Four situations that come up again and again.
Described in general terms rather than as client stories. If one of these reads like your situation, the conversation will be short and useful.
The workbook that became the system
The situation
A spreadsheet grew into the thing the business runs on. Several people edit it, there is no record of who changed what, and the rules that matter live in one person's memory rather than anywhere written down.
What we do
Move the rules out of the workbook into something with history, controls, and more than one safe pair of hands. Usually smaller than expected, because the logic already exists and only needs somewhere better to live.
Two systems and a person in the middle
The situation
Two tools each do their job properly, and somebody spends part of every day moving information from one to the other. The errors are quiet and the cost is spread thin enough that nobody has added it up.
What we do
Build the connection so the re-entry stops, then agree what happens when the two disagree. The second part matters more than the first and is the part most integrations skip.
Systems no one remaining can safely amend
The situation
Something built years ago still works, but whoever built it has gone and nobody wants to touch it. Every small change becomes a negotiation, and the cost of keeping it alive rises quietly each year.
What we do
Work out what it actually does before deciding what replaces it, then move off it in stages rather than over one weekend. Doing this well is unglamorous and is mostly a sequencing problem.
A product with no agreed edge
The situation
Real demand for something new, and no clear line between what version one is and what version four might be. Every conversation adds a feature and the release date moves further away.
What we do
Force the edge. Agree what the first release will not do, write it down, and hold it. Then put something in front of real people early enough that they can tell you which assumptions were wrong.
04 Capability matrix
What applies to which kind of work.
A filled square means this is usually central to the job. An open square means it applies when the situation calls for it.
| Capability | Customer facing | Internal operations | Typically involves |
|---|---|---|---|
| Requirements and workflow mapping | Central | Central | Interviews, review of current systems, data mapping |
| Interface and interaction design | Central | As needed | Prototypes tested before the build hardens |
| Application development | Central | Central | Building with checking alongside, not at the end |
| Integration with existing systems | As needed | Central | Interfaces, scheduled transfers, conflict rules |
| Data migration | As needed | Central | Staged moves with the old system still running |
| Reporting and analysis views | As needed | Central | Agreeing definitions before building charts |
| Process and sequencing advice | As needed | Central | Order of change, adoption, early warning signals |
| Release and post-launch correction | Central | As needed | First round of changes once real use begins |
05 Commercial terms
Two ways clients engage us.
A
Defined project
Fixed scope
A stated outcome with a scope, a schedule, and a fee agreed at the start. Suits a replacement, a first release, or any work with a clear finish line.
- fee agreed before work begins
- milestones you review as they land
- scope changes priced in writing
- handover and support terms written in
B
Continuing arrangement
Agreed cadence
Ongoing work at an agreed cadence, for companies that need software changed and decisions reviewed as things move rather than in one burst.
- agreed cadence and monthly commitment
- priorities set with you each cycle
- no lock-in beyond the notice period
- same people throughout
If one of those patterns reads like your situation, say so.
Naming the pattern usually gets us somewhere useful inside one conversation.