The CTO who inherited a maze
The codebase grew four years without a through-line. You want a map before you start renovating.
Available for new engagements
Your team ships software. But do the pieces still fit together?
You've got talented engineers, a roadmap, and more frameworks than anyone can keep in their head. And somewhere between the architecture diagram and the Monday standup, the system stopped making sense. Features slow down. Bugs come back. Juniors are stuck. Nobody wants to touch that service.
I help senior teams fix the thinking, not just the code. Training that actually changes how people reason. Consulting that pulls the hidden complexity out of your stack. Engineering when you need a steady hand in the codebase itself.
Sound familiar?
- The codebase works, but only three people know why.
- Every estimate is wrong in the same direction — twice as long, half the scope.
- Your juniors copy patterns they don't understand, and seniors fix bugs they can't explain.
- Something called "legacy" is actually the part that still pays the bills.
- You've hired more people and shipping got slower.
- "We should refactor that" has been on the board for fourteen months.
Reframe
The problem is almost never the code.
It's the mental model the team is holding. Code follows the model. If the model is fuzzy, the code will be fuzzy, and no amount of tooling will save you. The work I do is usually clarification, done through three channels: teaching the patterns explicitly, reviewing architecture against the real load, or writing the hard parts alongside your team.
Who I usually help
The tech lead drowning in reviews
Every PR is a teaching moment, and you can't be the single point of review forever. You want the team to see what you see.
The startup betting on AI
You shipped an LLM feature in a week. Now it's Tuesday, production is weird, and you need someone who has built actual agent systems, not just demos.
The platform team going functional
F#, effects, discriminated unions — the pattern you picked up from a talk. It works in toys. You want it to work at scale.
The training manager who is tired of fluff
Your engineers have watched a hundred courses. They still can't name the three ways a computation expression composes. You want training that sticks.
The founder with a hard problem
Type systems, DSLs, inference, compilers. The thing you're building actually requires someone who has written one. You need a pair of hands, not a deck.
How we work
Training
Workshops that change how your team reasons.
Two- to four-day sessions. F#, functional patterns in C#, LLM engineering, type-driven design, computation expressions. On-site or remote. I bring the material. Your team brings a real problem — we solve it together.
Typical shape: 1–3 days, cohort of 6–12, real code from your repo.
Consulting
Architecture review that names the thing.
I come in, read the code, talk to the team, and write you a document you'll actually use. No 80-slide deck. Concrete recommendations, ordered by leverage. Follow-up is included — I stay reachable while you act on it.
Typical shape: 2–6 weeks, part-time, written deliverable + live debrief.
Engineering
Hands in the codebase when it matters.
Parsers, type checkers, DSLs, agent systems, the tricky core of a product. I write code alongside your engineers, leave behind things that can be maintained, and document the reasoning as I go. No handover cliff.
Typical shape: 3–6 months, fractional, embedded with one team.
See how I think — on the channel
The long-form argument lives on YouTube.
If you want to know how I actually approach a problem, watch me solve one. @ThePureState is where I publish the reasoning that doesn't fit into a blog post — type inference, monads in anger, the design of a programming language, the philosophy behind a Result type. Pick any one.
-
01
How To Make a Programming Language
Type inference and a constraint solver, end to end. The TypeFighter video. If you only watch one, make it this one — it shows the whole loop from parser to solver to error messages.
-
02
Monads in the Wilderness
BobKonf 2024 keynote. Monads as a working tool, not an abstraction puzzle — where they show up in real codebases, and why.
-
03
Computation Expressions in F#
BobKonf 2024 tutorial. How to build your own, why bind and return are the whole story, and how to use them so your team actually understands what's happening.
-
04
This is My Result Type
Discriminated unions, three lines of F#, and why this tiny thing changes how your team handles errors forever.
-
05
Pipe Operator
Deep dive on one language feature. Why it changes the way you read code, and when it gets abused.
-
06
VSCode REST Client
A practical HTTP workflow you can use tomorrow. No Postman, no ceremony — just files that describe your API and live in the repo.
-
07
A Hackable Frame (Pt. 1)
PXL Clock hands-on intro. Hardware you can program in C#, with a browser simulator and hot reload. Side project, real craft.
Objection FAQ
- We already have senior engineers. Why bring in a consultant?
- You don't need more engineers — you need an outside mind that has no allegiance to past decisions. I'm that for a few weeks, then I'm gone.
- We're not a .NET / F# shop.
- Most of the work is language-agnostic. The clarity of thought transfers. I've worked in TypeScript, Python, Rust, and Scala codebases — same toolkit, different syntax.
- We've done training before. It didn't stick.
- Training sticks when people solve their own problems during the workshop, not toy exercises. I ask for real code ahead of time. We use it.
- Our AI feature is already in production.
- Good — now you have a baseline to make real decisions against. I come in with eyes on cost, eval, failure modes, and the team's understanding of what the model is actually doing.
- We need a full-time hire, not a consultant.
- Then hire one. But ask me to help you write the job description and interview them. I do that more often than you'd think.
What else I build
Hardware · Side business
PXL Clock
A 24×24 RGB pixel display in a hand-made wooden frame with real glass. Programmable in C# with .NET 10 and a browser-based simulator. Built with a friend, shipped through Cumin & Potato GmbH.
Open source · Research
TypeFighter
A teaching-grade type inference engine and constraint solver. The long-form video on How To Make a Programming Language walks through exactly how it works.
Channel · Weekly(ish)
@ThePureState
The YouTube channel. Long-form technical arguments — type systems, effects, compilers, functional patterns applied to real code. Linked throughout this page.
About
Ronald Schlenker
Independent consultant, engineer, and occasional teacher based in Germany. I've spent roughly two decades building systems where the thinking matters more than the tooling — compilers, DSLs, type systems, agent architectures, and the odd piece of hardware. I publish most of my long-form reasoning on YouTube at @ThePureState, and most of my code on GitHub.
I work through Cumin & Potato GmbH and take on a handful of engagements a year. If we talk, it'll be me on the other end of the email. No agency, no account manager.
Tell me what's not fitting together.
One email. I read them all. Most conversations start with a fifteen-minute call to see if I'm the right person for your problem — and if I'm not, I usually know who is.
hello@schlenkr.dev