Ronald Schlenker · Pragmatic engineering consulting · Frankfurt and remote EU.
You don't need fifty cheap developers. You need your own team sharper than last quarter — and the know-how to stay that way. There's a pragmatic path out, and it starts with picking where you actually need help.
Pick your path. Three ways we can work together.
"I want our team to understand what's actually new."
In-house upskilling for the AI and functional-programming shift — on your codebase, with your people, not a workshop deck.
See training path Consulting"I want a seasoned voice on a decision we're about to make."
Architecture second opinions, pragmatic delivery reviews, and multi-week sparring — neutral, time-boxed, written up.
See consulting path Engineering"I want someone to build the nested thing the market won't solve."
Hands-on builds where the problem is knotty — AI + functional architecture + DSLs + developer tooling. Paired, then handed back.
See engineering pathShort, high-bandwidth upskilling on your code, with your team. Pair-programming, reviews, dedicated spikes around a real problem — so your product carries your team's fingerprints, not a consultant's.
A short, high-bandwidth engagement that leaves your own developers able to ship the next thing without outside help. Delivered on your codebase, with your people — not a workshop deck.
A diagnostic 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.
For teams standing at a decision: a codebase going sideways, an architecture whose cracks are audible, a delivery process that runs ceremony without shipping. You get a written argument and a conversation, not a deck.
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.
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.
AI pipelines, functional architecture, domain-specific languages, developer tooling — the intersections the general market doesn't solve. I take on the build, pair with your team, and hand it back fully documented.
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.
The customer sees themselves first, then the reframe. If one of these is your week, you're in the right place.
"AI is obviously important. We just don't know how to use it for us."
What's 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.
"Our people are good. They just can't keep up in daily business."
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."
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."
A useful engagement ends with something your team owns: an architectural decision they can defend, a tooling chain they can rerun, code they wrote with help and now maintain alone.
"We added tests, coverage, analyzers. The project is still broken."
Ropes from above, 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?"
Consulting for agility. Not for the Agile Industrial Complex. Schema-F Scrum is not agile — that is the mistake being repeated for forty years in German engineering teams.
No invented quotes. No fake logos. Evidence is public and dated.
Outside client work, I build. PXL Clock is a 24×24 programmable LED display I co-founded with Sefa — engineered end-to-end by two people, shipping in limited batches from Frankfurt. pxlclock.com
TypeFighter is my experimental programming language — a modern, inference-first type system where records match by shape, not by declared name. Research-grade, explained end-to-end. github.com/SchlenkR/TypeFighter
@ThePureState on YouTube is my channel for the longer arguments — language design, functional programming, AI workflows, the craft that underlies the consulting. A good place to start: How To Make a Programming Language. youtube.com/@ThePureState
And plenty of other work on GitHub — FsHttp (499★, the F# HTTP library), Trulla (type-safe templates), TheBlunt (parser combinators), LocSta (stateful stream processing).
Less than hiring a senior full-time. Scoped explicitly; no retainer trap.
DACH and remote EU, both supported. Onsite workshop possible for team-facing engagements.
An agency builds more capacity. I make your existing team capable. Different job.
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.
Then you don't need me. I'm interested in engagements that leave something standing after I'm gone.
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.