v15 — The Pragmatic Path

Wrestling with a software project that no longer ships?

You've tried the expensive consultant. You've tried the two-week training. You've tried the ceremony framework with the certificate. Yet, here you are.

There's a pragmatic path out. It doesn't involve a framework you buy.

Let's talk through your situation

Sound familiar?

Six things clients tell us on the first call.

"AI is obviously important. We just don't know how to use it for us."
"Our people are good. They just can't keep up in daily business."
"Fifty cheap developers won't solve this."
"The expensive consultant worked. For two weeks."
"We added tests, coverage, analyzers. The project is still broken."
"We're agile. Why doesn't it feel like it?"

The reframe

We only do things that deliver value — now or over time. No feature piled on feature. No framework stamped on a team it doesn't fit. In-house stays. Boost is brought in.

How we work together

Five engagement shapes. Equal weight. Scroll to tour.

Each shape is an outcome, not a deliverable. Pick the one that matches where you're stuck — or ask and we'll suggest.

01 / 05 — Diagnostic

AI Adoption Review

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.

What you get

A shortlist of concrete AI moves, ranked by payoff-over-risk.
Effort and risk estimates your board will actually believe.
A written argument — no slide theatre, no vendor pitch.

How long 2–4 weeks · time-boxed

02 / 05 — Transfer

In-House Upskilling Sprints

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.

What you get

Pairing on a live feature, not a toy problem.
Reviews and spikes tied to your current sprint.
A team that carries the know-how after we're gone.

How long 4–8 weeks · on your codebase

03 / 05 — Judgement

Architecture Second Opinion

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.

What you get

A written architectural argument, not a Miro board.
"Keep / change / cut" calls with reasoning attached.
A conversation with someone not selling a replatform.

How long 1–2 weeks · written argument

04 / 05 — Reset

Pragmatic Delivery Review

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.

What you get

The two or three practices that actually produce value.
An explicit list of ceremonies safe to drop.
A return to Manifesto-level intent — empowered teams.

How long 2–3 weeks · observation + report

05 / 05 — Hands-on

Hands-on Engineering (selective)

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.

What you get

A working build of the hard, nested piece.
Pair-sessions so your team owns what ships.
Documentation a future engineer can actually read.

How long variable · scoped explicitly

The six frames

Where the pain actually lives.

01 · The AI-Transfer Gap

"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 actually 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.

02 · The Team-at-the-Edge Problem

"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 10 hours a week to read about vector databases, agent frameworks, or Computation Expressions. So the gap widens.

What you need is not 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.

03 · The Body-Shop Trap

"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.

04 · The Two-Week Shine

"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.

05 · The Metrics-on-a-Dying-Project Problem

"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: does this change produce value now, or over time? If neither — cut it.

06 · The Scrum-Industry Inversion

"We're agile. Why doesn't it feel like it?"

The Agile Manifesto was 17 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.

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.

Proof — artefacts, not testimonials

Things I've already built and shipped — because I'd rather show than claim.

Public and dated. No invented quotes, no fake logos.

F# Expert Recognized F# Expert, F# Software Foundation — Applied F# 2019.
OSS — FsHttp Invited by Don Syme (creator of F#) to the official fsprojects/FsHttp. 499★, 128 dependent packages.
Research — TypeFighter A research language with structural types and inference-first design — SchlenkR/TypeFighter.
Hardware PXL Clock — a 24×24 programmable LED display shipping via Cumin & Potato GmbH. Real hardware, real firmware, real customers — pxlclock.com.
Teaching BobKonf 2024 — Computation Expressions in F#, full tutorial track.
Community Recurring features in F# Weekly (Sergey Tihon, Microsoft MVP). Co-host at Amplifying F# — community format with G-Research OSS.

Objections

Fair questions, asked honestly.

Sounds expensive.

Less than hiring a senior full-time. Scoped explicitly; no retainer trap.

Can you do this remotely?

DACH and remote EU, both supported. Onsite workshop possible for team-facing engagements.

We already have an agency.

An agency builds more capacity. I make your existing team capable. Different job.

We don't use F#.

Good — most of my client work is C#/.NET, TypeScript, and the mix everyone actually has. F# is how I think; it's not a prerequisite.

We only need help for two weeks.

Then you don't need me. I'm interested in engagements that leave something standing after I'm gone.

About — why me for this problem

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.

Start a conversation

Let's talk through your situation.

No calendar-gate, no pitch deck. Describe where you're stuck — AI, team upskilling, a project that's stopped shipping — and I'll reply with an honest read.

hello@schlenkr.dev