All systems
Launch Checklist FastAPIPayments SecurityProduct Design

ParkQuick

Parking SaaS: driver app + operator back office

SYS.01ConceptSYS.02Core BuildSYS.03JWTAuth RebuiltSYS.04Security AuditSYS.05Launch
The problem

Parking infrastructure in most places still runs on interfaces and processes that haven't moved on in a decade: pay-and-display machines, clunky apps, confusing signage.

The opportunity

There's real room for a genuinely modern experience here, closer to how people expect software to work in 2026 than how parking meters have always worked.

The solution

ParkQuick pairs a driver-facing app (find a space, pay, manage a session) with a back-office operator app for site management, permit lookups and JWT-authenticated staff access, built around a custom colour-coded design system: mint for action, green for paid or confirmed, red for expired.

Technical challenges
  • Replacing an early, weaker way of proving who's an authorised operator with a proper, industry-standard method, rather than leaving it as a quick fix from the prototype stage.
  • Finding one login secret stored somewhere it shouldn't have been during a security review, and treating that as a reason to check everywhere else in the system too, not just fix the one spot.
  • Treating payment security as something that has to be right before launch, not patched afterward: checking that payment confirmations are genuinely real and haven't been faked, that only approved sources can talk to the system, and that sensitive keys are kept separate from each other so one leak can't compromise everything.
Lessons learned

Finding one secret in the wrong place is a bug. Treating it as a reason to audit every other secret in the system is the difference between patching a symptom and actually closing the gap.

Current status

Working through a short, concrete pre-launch checklist (infrastructure configuration, wiring in real payment credentials, and a full security pass) rather than open-ended feature work.

Supplier Portal Myo Discovery