01
The situation
Build something new
You know what needs to exist. Now it has to get built.
Maybe the spreadsheet finally broke. Or a customer asked for something you cannot deliver without software behind it, or two systems that should talk to each other still do not and someone is rekeying data between them every week.
You already know what the problem is. What you are short of is a team that can turn it into something that runs, and keeps running after the launch email goes out.
02
Recognition
What this usually looks like.
A manual process that has outgrown its spreadsheet
It worked at ten a week. At two hundred a week it is a liability, and the only person who understands the formulas is on leave.
A platform your customers log into
You need accounts, permissions, an audit trail, and the certainty that customer A can never see customer B’s data. That last one is an architecture decision rather than a setting, and it is much cheaper to get right at the start.
An integration between systems that do not talk
Two products, both fine on their own, and a person in the middle acting as the API.
A product idea that needs to be real before it can be funded
You need something credible enough to show, built in a way that does not have to be thrown away if it works.
03
Approach
What we do about it.
We start by working out whether the thing you want built is the thing you need built. Most of what makes a build expensive gets decided before anyone writes code: the shape of the data model, where the service boundaries fall, and what the system does when something upstream fails.
So we design first. The domain model, the tenancy strategy if you need one, the failure modes, and the integration points get decided and written down. Then we build in sprints you can see into, with a working system at the end of each one.
For the technical reader: we run .NET 8 and 9 with SQL Server or Postgres for systems that carry operational weight, and React or SvelteKit with Supabase where the system is lighter and speed to market matters more than depth. The stack gets matched to how long the system has to live and who has to maintain it afterwards.
We also leave things out. We do not reach for microservices because a system might one day be large. A well-bounded monolith with enforced internal boundaries is easier to operate and easier to hand over, and it can be pulled apart later if the load ever justifies it.
04
Disciplines
The disciplines this draws on.
05
What you get
What you get.
A written scope
Acceptance criteria you can test against, rather than adjectives you cannot.
A solution design
The data model, the boundaries, and the decisions taken, with the reasoning written down where the next person will find it.
Working software each sprint
Something you can open and use at the end of every sprint. That is also how you judge whether the work is going well.
A UAT round your people run
A script tied to the acceptance criteria, and written sign-off before anything reaches production.
Deployment through a pipeline
Releases happen by running the pipeline, and they happen the same way every time.
A codebase inheritance document
What the system does, how to run it locally, how to deploy it, and the known gotchas.
Then a maintenance arrangement, if you want one. Plenty of clients take the documentation and run it themselves.
06
Commercially
How it works commercially.
This is usually Scoped Delivery: a defined outcome for a defined price.
We will not price a build off a first conversation. If you already know the shape of what you need, we scope it properly and quote it. If you do not, the engineering assessment exists for that: a fixed fee, a fixed duration, and a written answer to whether this is the right thing to build and what it really costs.
You own what you pay for.
The code, the data, the credentials, and the infrastructure accounts are yours. They are treated as work product from the first commit, so there is no handover event to negotiate.
07
Objections
The questions people ask us here.
How do we know what this will cost before we commit?
You do not, and neither does anyone who quotes you a number in the first meeting. The assessment turns that into a fixed, bounded cost with a written answer at the end, including the option to walk away with it.
What if we cannot explain what we need?
Then that is the first piece of work, and it is a common starting point. The health check gives you thirty structured questions rather than a blank brief.
What happens if we want to take it in-house later?
Handover is designed in from the start rather than negotiated at the end. The documentation exists throughout, and the accounts are already in your name.
Are we locked in to you for hosting?
No. Infrastructure runs in accounts in your name, with your access.
We already have a developer. Does that make this awkward?
Not usually. A lot of our work sits alongside someone in-house who is good but outnumbered. If that is closer to your situation, get an engineering team is the better page.
Claer & Volker
453 Winifred Yell St, Garsfontein
Pretoria, South Africa
info@claervolker.com
© 2026 Claer & Volker
·
·