Start with a diagnostic.
You give me read-only access for two or three days. I map what you have, price what it costs to run, and hand you a written recommendation with every decision named. You keep the document either way.
From USD 1,500, fixed once I know the shape of the estate. I do not sell hours.
What the document contains.
The as-is map
What exists, how it connects, where the seams are missing. Most companies have never had this written down in one place.
What it costs to run
The monthly bill for every system, per unit where the volume matters. Unit cost is the margin ceiling, and it is usually nobody's job.
The decisions, named
Not a list of problems. A list of choices, each with its cost and what happens if you leave it alone.
Where the logic belongs
Rules written into an application become a development ticket every time they change. Rules held as settings do not. This is the finding that repeats most.
How the days run.
Read-only access
You give me read access and nothing else. Nothing breaks and nobody wonders who changed what. I read the code, the workflows, and whatever documentation exists.
The estate, mapped
I build a knowledge base of your systems and click through the product like a user. Then I send you my questions, and they are all why questions.
The written recommendation
You get the document. Decisions named, costs attached, alternatives included, and the ones that point away from hiring me marked as such.
Three from real reviews
A freight forwarder
They had an approved specification for a customer portal, written by their IT team and about to go to suppliers for tender. Their product owner asked me one question: is this the most flexible approach. The specification applied the right principle to the outside world and never applied it inward. Notification rules, approval thresholds and delegation windows were all written into the portal application, so changing a reminder from five days to three became a development ticket and a release. I named the decision, showed them where they had already answered the same question in their own email plan, and gave their product owner a sentence to ask his developers: if I want to change this in six months, is it a dev task or a setting.
An e-commerce company
Four engineers and no architecture document. Two weeks of read-only access produced the as-is map, the target picture, and the gap between them, priced. The plan came out of that gap rather than out of a wish list.
A gym equipment installer
They were about to buy an inventory forecasting app. They already held every number it needed. I showed them two routes, one of them requiring nothing from me, and told them which I would take. Separately I killed a CRM upgrade in their plan and saved them around EUR 2,500 a year.
I name it in writing.
Recommendations from someone who profits from the work are worth less. So when a finding points toward hiring me, I say so, and I name the alternative if you go elsewhere.
The freight forwarder's report carried a finding reducing what they would order from me, put there on purpose so the rest of the analysis holds. One client has thanked me in writing for advice that cost me the sale.
A build, a partnership, or nothing.
A build
Fixed price, fixed outcome
You pick the work off the recommendation and I build it. Tests, a cost ceiling, and a handover pack come with it. Client data stays on client infrastructure.
A partnership
Monthly, not hourly
I take the technical seat. Architecture, delivery standards, hiring, unit cost, and the platform underneath, on a monthly retainer.
Nothing
You keep the document
Some recommendations point away from hiring me. That is a real outcome and it happens. The document is yours regardless of what you do next.
Give me read-only access and three days.
Tell me what your systems are supposed to do and what they do today. I will tell you where the gap is.