Approach
Assessment first, then a fixed scope.
Work inside a live business, whether repairing a system or building a new one, fails in predictable ways: the visible problem is not the problem, the scope grows quietly, and the person who did the work leaves with the knowledge. The way we work is built to prevent each of those.
How we work
Six things that hold in every engagement.
- 01
Assessment before quote
We read the system, or the process a new tool has to serve, and write down what we found before quoting anything. That is what lets the price be fixed without being padded. The assessment is paid, bounded, and yours to keep.
- 02
Fixed scope, agreed in writing
Every engagement has a written scope with the deliverables named, and half paid up front. We do not work hourly. A change to the scope is agreed as a change, with its own cost, so you always know what you are paying for.
- 03
Deliverables you own
Assessments, mapping rules, import tooling, applications and handover notes are written so that your own team or another firm could act on them without us. Source code is yours. Dependence on a consultant is a failure of the consultant.
- 04
One engineer, start to finish
The person who reads your first message reads the code, maps the data, builds the work and writes the handover. There is no discovery team followed by a delivery team, and nothing is lost between them.
- 05
Confidentiality assumed
We work under agreement and do not publish what those agreements cover. Nothing about your system, your data or your business appears on this site or anywhere else. Work can run entirely on sanitised copies where that is easier for you.
- 06
Remote, with plain reporting
Investigation runs on read-only or copied access. Delivery access is agreed in the engagement, narrowed to what the work needs, and ends when the work does. Progress is reported in writing, in plain language, at agreed points. You will not need a technical reader to know where things stand.
The three stages
You can stop after any of them.
Each stage ends with something in your hands, and none of them commits you to the next.
- 01
A short conversation
You describe the system you have, the process you want to improve, or the tool you need built. We tell you whether this is our kind of problem. If it is not, we say so and point you towards the kind of firm you actually need.
- 02
A written assessment
Scope agreed in writing before we start. For an existing system we read the code, the jobs, the data and the integrations; for a new tool we map the process it has to serve. Either way you receive a document covering what exists today, what should change, what that would take, what to leave alone, and, if there is work worth doing, a fixed-scope quote for it.
- 03
The work
Quoted from what the assessment found. Deliverables, milestones and acceptance are named in the agreement. Buying the assessment does not commit you to this stage, and the document is written so someone else could do it.
What we need from you
Four things, and none of them is a project.
Listed here so the fixed scope stays fixed. If one of these is hard to supply, say so at the start and we will work around it.
- Read access to the code, or a copy of it. For a new tool, a walk-through of the process it will serve.
- A copy of the data, or read-only access. Sanitised is fine.
- One person who can answer questions about how the business actually uses the system, and who can reach whoever knows the parts they do not.
- Whatever documentation exists, including none.
Before you ask
The questions we are asked before anyone signs anything.
What does it cost?
Every engagement is a fixed scope, quoted in writing. The assessment is quoted in the first reply, once we know the size of the system; the work is quoted from what the assessment finds. We do not work hourly, and nothing is billed that was not agreed first.
How soon can you start?
We take a small number of engagements at a time, so the honest answer depends on the month. The first reply tells you when the assessment could start, and the assessment itself takes one to two weeks.
Who does the work?
One principal engineer, personally, from the first message to the handover. You are introduced to them directly in the first reply, and there is no team the work is passed to.
Why is the assessment paid?
Because it is the work, not a sales call. Reading a system properly takes a week or two of concentrated effort, and what you receive is a documented understanding of it and a plan you can use with any delivery partner. Paying for it also means the document is written for you, rather than written to sell you the next thing.
What if you look and find nothing serious?
Then that is the answer, in writing, with what was checked and how. A system nobody understands is a risk whether or not it is currently failing, and “this is sound, and here is why” is worth having on paper before somebody proposes replacing it.
Do we have to buy the fix from you?
No. The assessment is written so that your own team, or another firm, could act on it without us. If you want us to do the work, it is scoped and quoted separately, from what the assessment found.
What happens after handover?
The system is documented and yours, so your own team or any other engineer can maintain it. If you want us to keep looking after it, that is agreed as its own fixed scope. Nothing about the build depends on one person staying available, and that is deliberate.
Can you work with our ERP, or our vendor?
Our delivered ERP work is on ERPNext, and migration, integration and data work translate to other platforms because the method is the same. Where a vendor is involved, we work alongside them on the parts they will not or cannot do. If a system is genuinely outside what we can read, you find that out in the first reply, not after you have paid.
What about confidentiality?
Assumed rather than requested. We work under agreement, we do not publish what those agreements cover, and your system will not appear on this site or anywhere else. Work can run on sanitised data where that is easier.
How do you handle changes to scope?
As changes. If something is found mid-engagement that was not in the agreement, it is written up with its own cost and you decide whether to add it. Nothing is done without your agreement, and the price never changes without a decision from you.
Start here
The first step is a short conversation.
Describe the system you have, the process you want to improve, or the tool you need built. The reply comes in writing, with questions, and if it fits, a proposed scope.