about
A bit about how I work.
I'm a developer from Switzerland. For five years I built the software businesses actually run on: customer-facing sites, internal dashboards, line-of-business tools and the integrations that tie them together, mostly inside an agency. I learned a lot, and I worked with good people. But I wanted to get closer to both ends of the work: closer to the person I'm building for, and closer to the hard parts of the build itself. So now I work directly as a freelancer, with no agency in between.
The hard parts are where I spend my own time, and the demos are where you can see them: less a portfolio of past client work, more the engineering I go deepest on, from machine learning at the autograd level to distributed real-time state to GPU graphics and simulation.
Every one of them runs live and shows its own internals. I'd rather show you how a thing works than ask you to take my word for it.
// working together
That directness is the whole point. You talk to the person who actually builds the thing, not an account manager relaying it back and forth. The scope stays honest because I'm the one shipping it, and when something breaks at 11pm, the person who fixes it is the person who wrote it. I take on fewer clients so each one gets that.
// how I work
Here's why that depth matters to you. I work a level below most web developers: autograd, GPU kernels, distributed state. So whatever you're building is rarely the hardest thing I've had my hands on. You don't need a transformer. But someone who can hand-derive one will read your codebase quickly, find the load-bearing parts, and not need hand-holding through the unfamiliar bits.
Three ways to work together:
- Build. A defined project, shipped end to end. I own it from the first commit to the thing running in production.
- Ongoing. A few hours a week on retainer. I stay the person who knows your system, so changes and fixes come from someone who already has the full context, not a stranger reading it cold.
- Rescue. Something half-built, inherited, or on fire. I read it, tell you honestly what's salvageable, and either patch it or say so.
On price: not the cheapest tab you'll open, but a good deal less than an agency that would have sub-contracted the work to someone like me anyway. You pay for the build, not the layers around it.
the name
Why jDKOderso?
My initials are J.D.K., which, if you've ever watched a project compile, you'll also recognise as the Java Development Kit. I did not plan this. The universe simply handed a developer the initials JDK and dared me not to make it a brand. Oderso is the rest of me, the part that isn't a runtime. Put together: jDKOderso. Legally distinct from Oracle, emotionally adjacent to a good build log.
/* the obligatory mission statement (it's just me) */
First, to be clear: jDKOderso isn't a company. No team, no office, no "we": it's one person and a browser tab I forgot to close. The brand name just makes the byline look tidier.
Still, every personal site is contractually required to have some inspirational copy, so here's mine: I think every semicolon is a promise, I'd rather read the documentation than disrupt anything, and I don't chase unicorns. I profile them.
Mission: keep only what compiles. Vision: still be curious on Friday afternoon.
/* signed, me, wearing all the hats at once */
reach me at [email protected]