01
Two shapes
How we work.
Everything we do is bought in one of two shapes. The disciplines do not change between them, only the commitment does.
Scoped Delivery
Shape
A defined outcome for a defined price
Suits you when
You know what needs to exist
Process
Consult, design, build, UAT, host, maintain
You get
A system, documented and handed over
Commercials
Fixed price, with milestones
Embedded Function
Shape
Open-ended engineering capacity
Suits you when
The work is continuous, or not yet definable
Process
Ongoing, directed by you or by us
You get
People in your team, or the whole function
Commercials
Monthly retainer, reviewed against actual hours
Most long relationships start as one and become the other. A scoped build usually ends in a maintenance arrangement. An embedded arrangement usually contains scoped pieces, priced separately so they do not silently consume the capacity keeping the lights on.
02
Delivery
How we deliver.
Our methodology is rooted in Agile. Short cycles, working software ahead of documents about software, and a willingness to change direction when the work tells you something nobody knew at the start. Sprint planning sets the fortnight and a daily standup corrects the day.
We have also altered a fair amount of it. Textbook Agile assumes a team size and a client relationship that most of our engagements do not have, and following the ceremonies faithfully in a small team produces meetings rather than movement. We keep the parts that earn their place and replace the parts that do not, and we are explicit with you at kick-off about which is which.
The problem underneath all of this
Software delivery loses context at every handoff. Somebody experiences a problem, writes an email, attaches a screenshot. Somebody else turns it into a ticket. An engineer fixes something. It gets released. Somewhere in that chain the connection between what the person experienced and what was actually done comes apart, and six months later nobody can say why a thing exists, who asked for it, or what was agreed.
A board full of tickets can hide an engagement that is quietly dying. A ticket can be closed while the problem it described is fully intact. We are not trying to move work items around a board efficiently. We are trying to keep the chain intact from the moment somebody hits a problem to the moment they confirm it is genuinely resolved.
The principles we run on
Capture it where it happens
A request is worth most at the moment and in the place it occurs, inside the software itself, rather than reconstructed later from an email thread.
Never ask you for what the system already knows
Your job is to say what went wrong. Working out the circumstances, the screen, the record, the user, the build, and the logs for that exact moment, is ours.
Acknowledge immediately, decide deliberately
Being heard should be instant. The human decision is a separate thing and takes as long as it takes. Nothing gets declined except for scope or commercial reasons, and when it is, the reason is written down and stays written down.
The same picture on both sides
Status, hours estimated and spent, what was absorbed and not charged, what is waiting on us and what is waiting on you, with the same treatment and the same ages. Transparency that only runs one way is a scoreboard.
Nothing is done until you say it is
The loop closes where it opened. You go back to the place the problem happened, see your original report against what is there now, and give the verdict. You verify once and never get asked to test the same thing twice.
Preserve the chain, not just the state
Duplicates link instead of disappearing, so four reports of one problem become a demand signal. Every decision is added to a history and none of them overwrite the last. Estimates are versioned and approvals are kept as you saw them.
Approve a ceiling, pay the actual
If work is going to exceed what you approved, it comes back to you before the money is spent rather than at invoice time. Commercial honesty has to be a mechanism, otherwise it is only an intention.
Nexus
We are building a system of our own to carry all of that, working title Nexus. The principles above are how we work now, by discipline and habit. Nexus is the machinery that will make them consistent whoever is leading the engagement. It is still in development and not yet in your hands.
When it exists, every engagement will run on it and every product we build or maintain will be instrumented for it, so the experience is the same wherever you meet us. The part that is hard to copy is not the software. It is the discipline of working this way when nothing forces you to.
03
Engagement
How an engagement actually runs.
Five stages, with what you see and what you decide at each one.
Engagement
We work out what you are trying to achieve before anyone talks about technology. You meet the people who will do the work, including whoever will make the architectural decisions. You get a high-level requirements document, a proposal, and an indicative timeline.
You decide whether to proceed.
Overview and scope
Before sign-off, everyone with a stake agrees the objectives, the scope boundaries, the priorities, who decides what, and how we will communicate. Scope gets bounded here, which is the cheapest place to do it.
You decide what is in and what is deliberately out.
Kick-off
Once it is signed we lock down the working detail with you: final scope, the team and their roles, the risks and what we are doing about each, the definition of done, and the reporting cadence. A risk log opens here and stays open.
You get a kick-off document and a plan.
Delivery
Sprints, with something working at the end of each. Weekly status carrying a plain red, amber, or green per workstream and a one-line reason for anything not green. Scope changes are assessed for impact, priced, and approved in writing before work starts.
You decide on every change request, and you see the schedule and budget consequence first.
Closeout or renewal
On scoped work: deliverables accepted, documentation and runbooks handed to whoever is supporting it, final invoice, and a retrospective whose findings we will share if you want them. On a continuous engagement this becomes a periodic review instead, against actual hours and actual load.
You get the system, the documentation, and the access.
04
Ownership
What you own.
You own it. When you pay us to build something, the result is your work product: the source code, the data, the credentials, the infrastructure accounts, and the documentation. All of it sits in your name, under your control, from the first commit, not from the day we finish.
We keep the general components we bring with us and reuse across clients, the internal libraries and scaffolding that mean you are not paying us to solve a solved problem again. You get a perpetual licence to use those in the system we built for you, and we will tell you which parts they are before we start.
05
Handover
If it ends.
Every provider relationship ends eventually. Most of them end badly because nobody planned for it while things were going well, and by the time anyone is planning, the goodwill has gone. So we build the exit before we need it.
The inheritance document exists from the start.
Every system we run has one: what it does, its architecture and the decisions behind it, how to run it locally, how to test and deploy it from scratch, what the key modules do, and where the known problems are. We prove it by having a new engineer follow it and make a change end to end. It is written so that someone who has never seen the system can pick it up, and that someone does not have to work here.
Your accounts stay yours.
Hosting, repositories, domains, certificates, and third-party services, in your name with your access, throughout. Nothing runs in a place only we can reach.
Handover is a defined piece of work rather than a favour.
Documentation, credentials, runbooks, and a walkthrough with whoever is taking over. It happens at closeout on scoped work and on notice under a continuous arrangement.
Notice period is one calendar month, both ways.
Apply this test to us and to anyone else you are considering. Ask what would happen if you asked them, today, to hand everything to a third party. If the answer involves a project, a negotiation, or an awkward pause, you have your answer.
06
Communication
How we communicate.
Communication is part of the work. A feature built but never explained has not been delivered, and a delay you know about but do not mention becomes a future argument with interest on it.
Things will go wrong on any engagement worth doing. Bugs ship, timelines move, assumptions turn out to be false. That is not the test. The test is what happens next, and most clients will forgive a great deal if they believe we are honest, competent, and in control of the next step. What nobody forgives is silence, because silence makes people invent stories, and the stories people invent in the dark are always worse than the truth somebody was too uncomfortable to tell them.
You talk to the people doing the work.
We are small enough that this is possible, and it is one of the few real advantages of being small, so we are not going to put an account manager in the middle of it. A named person owns your engagement and you know who it is. On larger work that is a delivery lead, with the CTO involved in the architectural decisions, not appearing once a quarter.
An update reduces uncertainty rather than creating work.
“Still busy with it” is not an update. This is: the integration is mostly done and auth works, but we are blocked on the response mapping because the required fields have not been confirmed, we followed up this morning, and confirmation today means it finishes tomorrow. Longer to write, and it saves everybody time.
Written where it matters.
Decisions, approvals, scope changes, and anything with a cost attached go in writing, so neither of us is relying on a recollection of a call. Day-to-day runs on chat, because a decision needing three emails needs a conversation instead.
Weekly status during delivery.
Red, amber, or green per workstream, a one-line reason for anything not green, what is coming next, and what we need from you.
Blockers get raised when they appear
rather than at the next scheduled meeting. We would rather tell you early and occasionally be wrong than tell you late and be right.
Assumptions get written down.
When we have to proceed without an answer we record what we assumed, why, and what it costs if the assumption turns out wrong, then ask you to confirm it.
07
Disagreement
We will disagree with you sometimes.
The lazy version of client service says the client is always right. It is not true, and pretending it is does you no favours.
You are almost always right about your pain. You know what frustrates you and what outcome you want. You are often wrong about the solution, which is usually why you called somebody in the first place. Saying yes to everything is agreeable rather than useful, and agreeable is easy where useful is hard.
So we will sometimes say that a thing will work but will create a support problem in eighteen months, or that you have asked for a feature and what you appear to have is a process problem. We do that with respect, never to show off and never to make anyone feel stupid for not knowing something it is our job to know. What we will not do is nod our way into bad work to keep a meeting comfortable.
Claer & Volker
453 Winifred Yell St, Garsfontein
Pretoria, South Africa
info@claervolker.com
© 2026 Claer & Volker
·
·