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."
I'm Lars de Ridder. Energy systems for TNO. IoT platforms for Sustainder. E-commerce that scales for teams under pressure.
This isn't another "full-stack developer" portfolio. This is a system for understanding how to build products right - whether you're starting from scratch or fixing what's broken.
Signal #1: Start with the dream, not the spec
You get Lars. Not an account manager.
Why it matters
When you work with me, there's no account manager layer or 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.
Evidence
"I don't know anyone else who could have picked this project up as fast"
- Client feedback on immediate project ownership
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
Crisis Response Track Record
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: Speed Over Process
Experience beats process when you've seen the patterns 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?"
- Client surprised by fast problem solving
"DevOps team spent hours debugging. You point out immediately where the issue is."
- Technical lead on pattern recognition vs. process
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 understood, not just implemented
- • Business stakeholders stay informed and confident
- • 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: Team Dynamics
Happy teams ship reliable systems. When I work with teams, I optimize for sustainable velocity, not sprint heroics. Long-term success beats short-term wins.
I've seen brilliant engineers burn out, and I've seen average engineers become great when they work in good environments.
"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.