Services
Four ways to work with me. Each has a defined shape, a defined output and a stated timeline, so you can judge the risk before you commit to it.
The four formats side by side
| Format | Timeline | What you leave with | Seen in |
|---|---|---|---|
| Architecture review | 1–2 weeks | A written report and a staged plan you can act on without me | The CRM that stayed one system |
| System rescue | 1–3 months | A stabilised system your own team can run | Video analytics on ARM |
| Build from scratch | From 3 months | A running system and the reasoning behind every significant fork | Eleven years of billing |
| LLM integration into existing systems | 3–8 weeks | A pipeline in production with quality expressed as a number | New direction, no case study yet |
Best place to start
Architecture review
One to two weeks, fixed price agreed before it starts. You get the architecture as it actually is, the risks in order, the bottlenecks with the measurement behind them, and a plan for the next quarter that separates what to fix from what to leave alone.
Most larger engagements start here, because it is the cheapest way for both of us to find out whether the bigger project is real.
Architecture review
1–2 weeks · Fixed price, quoted before we start
You have a system that works but nobody is comfortable with, or a plan that nobody wants to sign off on. I read the code, the schema and the deployment, talk to the people who run it, and write down what I find.
Who it is for
CTOs and heads of engineering who need an outside read before committing budget to a rebuild, a migration or a vendor.
What you get
- A written report: architecture as it actually is, not as the diagram says.
- Ranked risks: what fails first, what fails worst, what is fine despite looking alarming.
- Bottlenecks with the measurement that proves them, not opinions.
- A staged plan with what to do in the next quarter and what to leave alone.
- A call to walk your team through it.
How to start
Send me a paragraph about the system and I will tell you within a day whether a review is worth your money.
Ask about this →A review whose answer was to decompose almost nothing →
System rescue
1–3 months · First assessment in the opening week
The project has stalled, the migration keeps slipping, or production has become unpredictable. I come in, find the load-bearing problem, stabilise it, then hand back a system your team can run without me.
Who it is for
Companies mid-way through a billing migration, a platform rewrite, or a latency problem that has survived several attempts to fix it.
What you get
- A stabilised system with the failure mode understood and closed.
- Instrumentation, so the next problem is visible before it is expensive.
- Documentation and handover to your engineers. I am not trying to become permanent.
How to start
Describe what is broken and what has already been tried. The second part matters more.
Ask about this →Where the bottleneck was never the part everyone suspected →
Build from scratch
From 3 months · Scoped after a review
Full cycle: architecture, data model, implementation, deployment, the operational side. I have built rating and charging engines, agent desks on live PBXs, and execution stacks that had to keep their timing under load.
Who it is for
Companies where the system being built is the business, and where getting the invariants wrong the first time is not recoverable.
What you get
- A running system, with the reasoning behind each significant fork written down.
- A deployment and observability setup your team owns.
- Knowledge transfer throughout, not as a final ceremony.
How to start
Most of these start as an architecture review. It is the cheapest way for both of us to find out whether the project is real.
Ask about this →Built because nothing on the market fit, then run for eleven years →
LLM integration into existing systems
3–8 weeks · Quoted per pipeline
Call transcripts, tickets, contracts, logs: putting a model over data you already have, without rewriting the systems that produce it. The interesting engineering is in the pipeline, the evaluation and the failure handling, not in the prompt.
Who it is for
Contact centres and operations teams sitting on years of unstructured data, with legacy systems that are not going to be replaced.
What you get
- An ingestion and processing pipeline that runs on your data where it lives.
- An evaluation set, so quality is a number rather than an impression.
- Explicit behaviour for the cases where the model is wrong. Most pilots skip this, and most rollouts die on it.
- Cost per unit of work, measured rather than estimated.
How to start
Tell me what data you have and what decision you want it to support.
Before you ask
What access do you need?
Read access to the repository, the schema and whatever you use for monitoring, plus an hour each with the people who operate the system. Production write access only if the work requires it, and only after we have agreed what I will touch.
Will you sign an NDA?
Yes, before anything is shared. Client names appear on this site only where the client has cleared them; the rest are described by shape rather than by name.
Do you work with our team or around it?
With it. Your engineers know things about the system that no amount of reading finds, and they are the ones left holding it. Work that only I can maintain is a failure even when it runs.
What happens when the engagement ends?
You get the reasoning, not just the result: what was decided, what was rejected, and what to watch. Handover happens along the way rather than as a final ceremony, so nothing depends on a single meeting at the end.
How are prices set?
A review is a fixed price agreed before it starts. Longer work is scoped after there is enough information to scope it honestly, which is usually after a review. If I think your problem does not fit the time stated above, I say so before we start rather than after.
Not sure which of these you need?
If it isn't my kind of problem, I'll say so and point you somewhere better. Direct email works too: hi@realgeek.biz.