Why I Built a Parking Proxy—and What Cities Can Learn from Open Systems

Why I Built a Parking Proxy—and What Cities Can Learn from Open Systems

Published October 16, 2025

Every year, the same ritual: my kids’ birthday parties. Friends and family from all over the country park in my street, and the hassle begins. "Do you have a discount code for me?" I did, but visitors couldn’t use it. I had to log in, enter four license plates, and pay over €30 upfront—with a resident discount, but still. It wasn’t just inconvenient for me; it was especially frustrating for parents with newborns, elderly guests, and anyone who just wanted to park independently.

Introduction: A Parking Problem as a Catalyst for Innovation

Every year, the same ritual: my kids’ birthday parties. Friends and family from all over the country park in my street, and the hassle begins. "Do you have a discount code for me?" I did, but visitors couldn’t use it. I had to log in, enter four license plates, and pay over €30 upfront—with a resident discount, but still. It wasn’t just inconvenient for me; it was especially frustrating for parents with newborns, elderly guests, and anyone who just wanted to park independently.

The real issue? Closed systems. When parking machines disappeared, only the permit holder (me) could pay. No cash, no choice, no way for visitors to start their own parking session. The app was only usable by me. Visitors couldn’t:

  • Pay with a discount on their own.
  • Start a parking session without my help.
  • Park without creating an account (who signs up for two hours of parking?).

So I became the gatekeeper: collecting license plates via WhatsApp, manually entering them, fronting the cost, and hoping for reimbursement. Or accepting that people risked fines. This had to change.

The Workaround: Puppeteer as a Last Resort

Since Utrecht offered no API, I built the Utrecht Parking Proxy—a system letting visitors manage their own parking sessions using my discount, but without my intervention. Without an API, I had to use Puppeteer, a browser automation tool that mimicked my login.

// A bot logging in as me
const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('https://parkeerapp.utrecht.nl/Account/Login');
await page.type('#EmailAddress', process.env.MY_EMAIL); // My real credentials
await page.type('#Password', process.env.MY_PASSWORD); // My real password
await page.click('#loginButton');

The problems:

  • Fragile: A minor app update could break the entire system.
  • Unsecure: My credentials had to be stored somewhere.
  • Undesirable: It felt like hacking, not legitimate integration.

This didn’t have to happen. With a secure API, I could have built what I needed—without exposing my data.

What Could Have Been Possible with an API

Imagine if Utrecht provided a developer-friendly API. I could have built: ✅ Automatic parking links tied to my calendar (e.g., for birthdays). ✅ Integration with healthcare systems, giving home nurses automatic access. ✅ Multilingual support for international guests. ✅ Better security with OAuth instead of hardcoded passwords.

Instead, I built a functional but vulnerable system.

The Lesson: Open Systems Prevent These Problems

Utrecht’s new solution (discount codes for visitors) is a big step forward. But it’s still a closed system. What if I wanted to:

  • Link my smart home to send parking links automatically?
  • Create an app for my Airbnb guests?
  • Build a neighborhood system for shared parking?

I can’t. Because there’s no API.

Meanwhile, other cities show how it’s done:

  • Amsterdam offers open parking data for apps.
  • Rotterdam shares traffic info via APIs.
  • Berlin lets developers integrate safely with government services.

Utrecht could have done the same.

Why This Matters for Enterprise Architects and IT Leaders

This isn’t just about parking. It’s about choice, scalability, and the power of open systems. Hospitals, businesses, and citizens could build their own solutions if data and functionality were accessible.

Examples:

  • Hospitals could auto-link parking access to appointments.
  • Businesses could integrate parking into customer service.
  • Parents could create simple apps for their kids.

That’s the power of open systems: they let everyone innovate.

The Future: Utrecht, Do Better

I’m glad Utrecht fixed the core issue. But I hope for the next step:

  • A secure API for developers.
  • Clear documentation and support.
  • Room for innovation, not dependency on workarounds.

Ultimately, this isn’t about my proxy. It’s about freedom of choice. I don’t want to rely on what the city offers. I want to choose how I solve my parking problem.

So, Utrecht: thanks for the improvement. Now give us the tools to make it even better.

Call to Action

Tired of closed systems? Struggling with integration challenges in your organization? Let’s talk about how open APIs and data integration can transform your processes.

📩 Reach out via Gijs.com or LinkedIn.

Built out of frustration, but with hope for better digital services.

Back to proof of concepts