Lars de Ridder
Ship it right.
Everything else is noise.
"I build products from concept to scale. Sometimes that means starting from a napkin sketch. Sometimes it means rescuing a system that's hit its limits. Either way: you get Lars."
Energy systems for TNO. IoT platforms for Sustainder. From napkin sketch to production, or picking up a system that's hit its limits. I also help developers and companies design what their AI knows, through context engineering and tools like Context Lens.
Signal #1: Start with the dream, not the spec
No account manager layer, no junior developers who need supervision. No "let me check with the team." I understand the business problem, design the architecture, write the code, and get it running.
You get direct access and fast decisions from the person who actually built it. That's me.
Evidence
"I don't know anyone else who could have picked this project up as fast"
How it applies
- • From concept to code, one person owns the full picture
- • Technical decisions get made in hours, not committee meetings
- • You know who built what and why - it's the same person
Signal #2: Crisis = Opportunity
System failures reveal patterns you can only see with experience.
Why it matters
System failures reveal more in an hour than months of normal operation. When your system breaks, you need someone who's been there before and knows where to look first.
Experience turns crisis into systematic problem-solving instead of panic.
Evidence: Paylogic Peak Sale Crisis
When Paylogic's peak sale system crashed mid-event, the team was paralyzed. Thousands of tickets, angry customers, account managers losing their minds.
I coordinated the immediate response: paused the queues, called backup systems, worked with customer service, and kept stakeholders informed. The crisis revealed weak points in architecture, process gaps, and communication breakdowns that had been building for months.
"It looks easy when things go right, but we were very happy you were here this time."
- Technical Director, Paylogic
How it applies
- • System failures become learning opportunities, not just fire drills
- • Root causes get fixed, not just symptoms patched
- • Your team learns from crisis instead of being traumatized by it
Signal #3: Experience Over Process
Pattern recognition beats process when you've seen it all before.
Why it matters
After seeing the same failure patterns across dozens of projects, you start recognizing them immediately. Experience creates speed through pattern recognition.
I rely on recognizing what works rather than following process for its own sake.
Evidence
"How do you always solve these things so quickly?"
"DevOps team spent hours debugging. You point out immediately where the issue is."
How it applies
- • Architecture decisions in days, not months of analysis paralysis
- • Problems get fixed before they become crises
- • You skip the expensive learning phase because I've already learned it
Signal #4: Empathy Drives Engineering
The most important skill for a software engineer is empathy.
Why it matters
Technical problems are human problems. Bad software usually means someone misunderstood what someone else needed.
If you can't explain your solution to the business team, you don't understand the problem yet. Most complexity comes from miscommunication.
Evidence: Project Recovery
A 6-month e-commerce project had delivered nothing. Client unhappy, no clear process. The technical problem wasn't the code: it was trust.
I built trust through weekly updates showing real progress, explaining decisions in business terms, and delivering value from day one.
"We would have dropped this project if it wasn't for you stepping in."
- CEO on relationship recovery
How it applies
- • Requirements get internalized, not just implemented
- • Business stakeholders get heard, not just tolerated
- • Code gets written for humans, not just compilers
Signal #5: Culture Shapes Code
When the team suffers, the software suffers.
Why it matters
This isn't about platitudes. It's about sustainable engineering. Burned-out teams ship broken software. Rushed teams create technical debt. Miserable teams write miserable code.
Good software comes from good working relationships.
Evidence
One of my team members was going through a rough patch: a newborn, no sleep, barely keeping it together. I gave him space to find his footing, kept expectations realistic, and made sure he stayed in the loop without feeling pressure to perform. He stayed. The work stayed good.
"I would have quit if it weren't for you."
- Team member during a difficult period
How it applies
- • No death marches or impossible deadlines
- • Clear communication reduces stress and bugs
- • Sustainable pace means sustainable systems
Where are you?
Ready to ship it right?
Building Something New?
You have a concept, vision, or idea that needs to become a real product. You want a technical partner who understands the business side.
Examples:
• "I have this idea for an app..."
• "We need to build a platform for..."
• "Help me figure out how to make..."
Something Broken?
Your system is failing, hitting limits, or a project has gone off track. You need someone who's handled crises before.
Examples:
• "Our system crashes during peak traffic"
• "This project is 6 months behind"
• "We're outgrowing our architecture"
No account managers. No "let me check with the team." No corporate theater.
You get Lars. That's the whole point.
