Software development studio
Tedious work is the kind a computer should be doing. We build the web and mobile software that takes it off your hands — and we say what it will cost to find out, before you commit to building anything.
Scope
Build and test
Keep it running
What we do
You have an idea, a spreadsheet or a manual process, and nothing built. We work out whether it belongs in a browser or on a device, write the scope down, then build it.
It is built and it keeps breaking, or there is a release you are afraid of. We find the defects before your users do — and tell you when the problem is not testing at all.
The software works and nobody can work out how to use it. We separate the problems that are structural from the ones that are surface, and rank them by how many people hit them.
It is live and nobody is looking after it, often because whoever built it has gone. We take it over: access, updates, fixes and the small changes that keep accumulating.
How an engagement starts
The decisions that shape a software project are made before much of it is built, and they are cheapest to change while they are still on paper. This sequence exists to make them in the open, and to let you stop after step two if the answer is that the work is not worth doing.
Not a specification — the task as it happens today. Who does it, how often, what they start with, what they have to produce, and what currently goes wrong.
A written scope, the list of screens or routes, the questions still open, and a cost range rather than a number. If scoping shows the job is smaller or larger than you thought, you find out here.
A range on paper is enough to compare us with anyone else, or to decide not to build. Taking the scope elsewhere is a legitimate outcome of it.
Working software you can try, rather than a demo at the end. Tests on the paths that run every release, and a plain statement of what is not covered.
Where the repository, the hosting and the store accounts are held in your name, you can change supplier without asking anyone's permission — so it is worth settling in the scope rather than at the end. Support afterwards is a separate arrangement, not an assumption.
What you hold before committing
Every CTA on this site leads to the same first deliverable. It is worth saying what that deliverable actually is, because “we'll send you a proposal” and “you'll have a scope” are different offers.
Fit
Enough process that manual work is expensive, small enough that one team can still change how things are done. That combination is where this kind of work pays for itself soonest.
Repetitive, rule-based work with a clear input and output is the cheapest thing to automate and the easiest to scope honestly.
Built by someone who has moved on, still in daily use, nobody sure how it works. Taking one of these over is a defined piece of work with a defined first step.
Work that turns on medical, legal or financial regulation needs a specialist in that field and in that jurisdiction. Say so in the first message and it can be ruled in or out before anyone writes a proposal.
This is scoped project work. If what you need is people inside your organisation permanently, that is a different kind of purchase.
Adding a supplier to a build that is already failing against a fixed public date changes the shape of the problem without changing the date. Worth establishing in the first exchange rather than the second month.
Straight answers
Nobody can tell you before scoping, and a supplier who gives you a number on a first call is guessing or quoting a different job. What actually moves the figure: how many kinds of user there are, how many other systems it has to talk to, whether existing data has to be migrated, whether it must work offline, and whether it goes through an app-store review. Scoping produces a range you can compare against another supplier. The number comes after.
The floor is set by how much has to be decided and how many systems have to be integrated. Three things stretch a timeline, and none of them is coding speed: decisions waiting on someone at your end, access to a system nobody can grant, and a definition of “done” that was never agreed. Scoping is where those get named.
Less than you think. Describe the task as it happens today — who does it, how often, what they start with and what they have to produce. If something already exists, say who built it and whether you have access to the code. You do not need a specification, a budget figure or a technology preference; working those out is the job.
Three fields and a paragraph is enough to start. If the honest answer is that a spreadsheet already does the job, that is the answer you will get.