An assessment page, not a pitch
Leaders want AI to work by next Tuesday. Most teams need to get three foundations right first — and none of them are on the conference slides. You've shipped a ChatGPT wrapper nobody uses. Management wants AI in the product by Q3 and hasn't said what problem it solves. The vendor demos keep promising the same three things.
What's actually missing is the bridge — from "AI is capable" to AI that delivers measurable value in your product, on your codebase, maintained by your team. The bridge is engineering, not a platform.
Let's talk through your situationBefore an AI feature becomes an AI product, three things have to be honest. Every engagement starts by testing which of these is shaky. Usually at least one is.
Not every LLM demo maps onto your product. The real question is narrow: which workflow, for which user, carries a cost that AI cuts by enough to matter — and which carries a risk AI absolutely must not own?
We answer that with a shortlist of AI moves that fit your product, your stack, your team — each with an effort estimate and a risk you can defend in the next board meeting.
Metrics on a dying project don't revive it. Coverage is a green light on a dead engine. Before you point a model at your code, the code has to have seams — legible boundaries, testable interfaces, a deployment story that isn't folklore.
The pragmatic question is always the same: does this change produce value now, or over time? If neither — cut it. Same for AI features. Same for architecture.
Your developers build the product that pays the bills. They don't have ten hours a week to read about vector databases, agent frameworks, and evals. So the gap widens: the tools move, the team holds the fort.
You don't need a replacement team. You need know-how transfer into the team you already have — so your product carries your team's fingerprints, not a consultant's.
Three patterns we see across product teams under AI pressure. None of these are failures of engineering talent. They're failures of foundation.
The feature works. The demo is fine. It solves a problem nobody in the product's real user base was actually blocked on. Foundation 01 was skipped.
RAG over your docs. A chatbot. A copilot. The slides change, the deck doesn't. Buying a platform doesn't answer which AI move fits your product.
Mandate without a problem is how ChatGPT wrappers get born. An Adoption Review produces the missing page-one document — before a sprint gets scheduled against vapour.
Every engagement starts with a pain the customer recognises. These are the six we meet most often. Frame 1 is why this page exists. The other five are how it stays honest.
"AI is obviously important. We just don't know how to use it for us."
You've shipped a ChatGPT wrapper nobody uses. Management wants AI in the product by Q3 and hasn't said what problem it solves. The vendor demos keep promising the same three things.
What's missing is the bridge — from "AI is capable" to "AI delivers measurable value in your product, on your codebase, maintained by your team." The bridge is engineering, not a platform.
"Our people are good. They just can't keep up in daily business."
Your developers build the product that pays the bills. They don't have ten hours a week to read about vector databases, agent frameworks, or computation expressions. So the gap widens: the tools move, the team holds the fort.
You don't need a replacement team. You need know-how transfer into the team you already have — so your product carries your team's fingerprints, not a consultant's.
"Fifty cheap developers won't solve this."
You've seen the offshore model. You've seen the staffing agency. You end up managing more contracts than code. Quality is a lottery. The knowledge leaves with the contract.
In-house stays. Boost is brought in. Software craftsmanship is not an arbitrage play. Pair-program with senior help for a quarter, keep the result forever.
"The expensive consultant worked. For two weeks."
You paid. Everyone was inspired. There was a deck. Then the normal gravity resumed and you were back where you started — minus a budget line.
A useful engagement ends with something your team owns — an architectural decision they can defend, a tooling chain they can rerun, a piece of code they wrote with help and now maintain alone. Not a certificate. Not slide 42.
"We added tests, coverage, analyzers. The project is still broken."
Automated tests on a cold project don't revive it. Coverage dashboards are a green light on a dead engine. Unit tests around broken architecture preserve the breakage.
When a project has fallen in the well, ropes from above are the answer — not more metrics. The pragmatic question is always the same: does this change produce value now, or over time? If neither — cut it.
"We're agile. Why doesn't it feel like it?"
The Agile Manifesto was seventeen developers saying one thing: trust motivated people and let understanding emerge from the work. The industry that grew on top of it sells the opposite — rigid ceremonies, certified process police, velocity dashboards stamped onto teams that don't fit them.
Schema-F Scrum is not agile. That is the mistake being repeated for forty years in German engineering teams. Consulting for agility. Not for the Agile Industrial Complex.
Five engagement shapes. Each is an outcome, not a deliverable. Most AI-curious teams start with the Adoption Review — it produces the page-one document everything else depends on.
A diagnostic engagement for product teams that know AI belongs in the roadmap but aren't sure where. Output: a shortlist of AI moves that fit your product, your stack, your team — with effort and risk estimates you can defend in the next board meeting.
A short, high-bandwidth engagement that leaves your own developers able to ship the next thing without outside help. Pair-programming, reviews, dedicated spikes around a real problem — not a workshop deck. Delivered on your codebase, with your people.
A neutral, time-boxed read of where your system is heading. You get a written argument — what's working, what's decaying, what moves next — plus a conversation with a senior voice who is neither selling you a replatform nor defending the status quo.
For teams stuck in ceremony theater. We identify the two or three practices that actually produce value and recommend what to drop — starting from the Agile Manifesto, not the framework textbook.
When the problem is so nested — AI + functional architecture + DSL + developer tooling — that a tool-hire makes sense, I take on the build, pair with your team, and hand it back fully documented.
Things already built and shipped — because showing beats claiming. Every item below is public and dated. No invented quotes. No fake logos.
"The consulting I sell is the opposite of buzzword compliance. Here's the receipts."
// A pragmatic seam: the AI touches a small, pure function
// with typed inputs, typed outputs, and a test.
public static class SupportTriage {
public record Ticket(string Subject, string Body);
public record Routing(string Queue, double Confidence);
public static async Task<Routing> Classify(
Ticket ticket,
ILlmClient llm,
CancellationToken ct) =>
// one model call, one schema, one fallback.
await llm.StructuredCall<Routing>(Prompt."triage.v3", ticket, ct)
?? new("queue/general", 0.0);
}Placed last. Ronald shows up in your story as a guide, not the hero of this page.
Ronald Schlenker — fifteen years in .NET, creator of FsHttp, TypeFighter, and several other OSS libraries the F# community uses. Recognized F# Expert (F# Foundation, 2019). Co-founder of the PXL Clock — a programmable hardware product that is itself a working example of pragmatic engineering: small team, in-house discipline, shipped without a framework textbook.
The reason this page is written the way it is: every time I see a dying software project, it died the same way — buzzword compliance replacing engineering judgement. The consulting I sell is the opposite of that.
Based in Frankfurt. Work with DACH and remote-EU teams. Trading as PureState IT Consulting.
Next step
Tell me what you're trying to ship, what's stuck, and what you've already tried. A short email is enough — I'll reply with whether this is a good fit, and if not, who might be.
hello@schlenkr.dev