Product development
For the point where the spreadsheet has become load-bearing and the SaaS subscription is being worked around rather than used.
There’s a stage most growing businesses hit where the tools stop fitting. The spreadsheet that ran everything has become something nobody dares touch. The software you pay for monthly does most of the job and the rest happens in email. Everyone has a workaround and nobody has written them down.
That’s the point where building something is worth considering — not before. When we do build, we start from the outcome rather than the feature list: the number that has to move, whether that’s hours saved, errors avoided or orders processed. Features that don’t serve it get cut before they’re built.
Fit
When this is the right job — and when it isn’t
We’d rather lose a project at this stage than sell you one you don’t need. The right-hand column is the honest half.
- A spreadsheet has quietly become critical infrastructure and nobody wants to be the one who breaks it
- You’re paying for software you’ve outgrown and working around it daily
- The way you work is genuinely different from your competitors, and generic tools flatten that advantage
- You’ve got the process right and now the constraint is the tooling
- An off-the-shelf product would do it. Rebuilding something that already exists is a long way round to a worse result
- The process isn’t settled. Build it once you know what it is
- Nobody internally has time to be involved. These projects need someone on your side who knows how the work really happens
Scope
What’s included
Scoped against an outcome
We start with the number that has to move. If a feature doesn’t serve it, we’ll say so before it’s built.
A scope you can hold us to
Written down before work starts — what it does, what it doesn’t, and when it lands.
Boring where boring is correct
We keep the stack unremarkable wherever novelty would only add risk. The interesting part should be your business logic, not our infrastructure choices.
We stay after launch
Monitoring, iteration and support once it’s live. A product that shipped and then quietly broke is worse than none.
Related work
Where this shows up in the portfolio
Questions
Straight answers
How do you scope this?
We start from the outcome the software has to deliver — hours saved, errors avoided, orders processed — and scope backwards from it. A two-week tool and a six-month system aren’t the same job, so the scope is written for yours and you see it before any work begins.
Who owns the code?
You do. Nothing is outsourced and there’s no arrangement where you need us in order to keep using what we built.