Home / Services
What we take on.
Three named services. Most jobs use two of them, and getting the sequence right matters more than the boundary between them.
01 Consumer products
Applications made for one company.
Software shaped around how a business actually works, rather than a general product bent until it roughly fits. Worth doing when the way you operate is the advantage, and flattening it to suit a vendor's feature list costs more than it saves.
01
Working out what it has to handle
Before anything gets made we sit with the people who will use it, look at what they use now, and map what the data actually is rather than what the diagram claims. The expensive mistakes get made here, quietly, and are paid for later.
02
Making it, and checking as we go
Checking is not a phase at the end. It runs alongside, so what you see at each checkpoint is something working rather than a claim about progress.
03
Connecting it to what is already there
Interfaces between systems, moving data across, and getting off older platforms without a gap in service. This is where schedules usually slip, so we plan it early rather than discover it.
04
Keeping it working
Businesses change and their software has to follow. What we look after, for how long, and on what terms goes in the agreement rather than being assumed on either side.
02 Product strategy
The decisions around the software.
A system can be built competently and still be beside the point. Usually because nobody settled what it was for, or because the people who would have to change how they work were told rather than asked.
01
Where throughput is constrained
We trace how something actually moves from start to finish, including the spreadsheet nobody mentions and the approval that happens by text message. The distance between that and the official version is normally the whole problem.
02
Make it, buy it, or leave it
We work the options through with you and put numbers on each over several years, including the cost of doing nothing. Then you decide with the arithmetic in front of you rather than on how convincing a vendor was.
03
What order to do it in
Order decides whether a change lasts. We help work out the sequence, who has to be brought along and when, and which early signals tell you it is going wrong while there is still time to act.
03 Product development
From proposition to first release.
For clients bringing something new to market. The difficulty is not construction. It is establishing what the first version will deliberately exclude, and holding that boundary while every stakeholder proposes one further addition.
01
Deciding what it is
Who it is for, what it does, and the list of things it deliberately leaves out. We argue for a small first release, because something small that reaches people beats something complete that does not.
02
Drawing it and trying it
How it looks and how it behaves, tested on real people before the making sets around it. For anything customers touch, this is where most of the result is already decided.
03
Release and refinement
A controlled release, followed by the first cycle of refinements once genuine usage reveals what planning could not. Every product surfaces something. What distinguishes a disciplined engagement is how quickly it is identified and resolved.
04 Capability
What we work on, stated plainly.
Not a technology showcase. This is the ground a job is likely to cover, so you can judge before the first call whether your problem sits inside it.
Interfaces
- Web applications
- Internal tools
- Operations dashboards
- Client and supplier portals
- Views that work on a phone
- Forms and intake
Logic and data
- Application logic
- Data models and schemas
- Scheduled and background jobs
- Reporting queries
- Search and filtering
- Permissions and access
Connections
- Application programming interfaces
- Third party services
- File and batch transfers
- Event and webhook handling
- Data migration
- Sign-in and identity
Delivery
- Version control and change history
- Separate test and live environments
- Automated checks
- Release and rollback
- Error and uptime monitoring
- Written documentation
Tools are chosen to suit the job and whatever you already run, not to suit us. An existing platform, hosting arrangement, or in-house preference is a constraint we design around, and we say so before a scope is written.
05 The written scope
What you receive before work starts.
Every engagement runs against a signed document. This is what is in it. If any line is missing, the scope is not finished and the work has not begun.
Most of what goes wrong on a software project was decided before anyone wrote anything: an objective nobody agreed on, a deliverable that meant two different things to two people, or a change that was absorbed quietly until the schedule broke.
Why item three matters most
The out-of-scope list is the one clients are least used to seeing and the one that prevents the most argument. Naming what a job does not include is how both sides find out, early and cheaply, that they pictured different work.
Why the change procedure is written down
Requirements move. That is normal and not a problem in itself. What causes overruns is absorbing changes informally until the original dates are meaningless. Agreeing the procedure in advance means a change is a decision you make with a price attached rather than something that happens to you.
What this is not
Not a guarantee about outcomes, and no honest document could be. A record of what was agreed, which is what makes disagreement resolvable.
Not sure which of these your situation calls for?
Describe it and we will tell you what we think, including when the honest answer is less work than you expected.