A parking permit issuer on AWS for a few dollars a month
Sixty spaces, two hundred and forty staff, and a car park that is full by twenty past eight and half empty by three. Every proposal to fix it produces a stronger reaction than any other facilities decision, and the reason is that parking is one of the few workplace resources where the allocation is visible to everybody every morning.

Key takeaways
- Over-issue deliberately, at a ratio derived from measured occupancy.
- Publish the allocation rule before applications open. Which rule matters less than that.
- Reclaim permits that go unused; they are the main source of new capacity.
- Accessible bays are allocated on need and sit outside all of this.
- Designed on AWS for about $2 a month.
The whole system on one page
Before any code, here is the shape of what we are designing.
- Compute
- Analytics
- Front-end & mobile
- People
Why this is hard
Not technically. A permit is a row in a table and a car park has a number of spaces in it. The difficulty is entirely that parking allocation is a visible distribution of a scarce good among colleagues, and any rule produces people who did not get one and can see who did.
Which means the design goal is not optimality; it is defensibility. A rule that is published before applications open, applied consistently, and shown to have been applied consistently, produces far less trouble than a better rule applied opaquely.
What runs (the inside)
- The ratio. How many permits to issue per space, derived from measured occupancy rather than guessed. Part 2.
- Allocation. The published rule, applied and recorded. Part 3.
- Reclaim. Finding permits that are not being used and returning them to the pool. Part 4.
One year, end to end
- Compute
- Analytics
- Front-end & mobile
In plain words
Sixty spaces. Counting cars at ten in the morning for a month shows the car park averaging seventy-one per cent full when permits were issued one per space, which means roughly three in ten permit holders were not there on any given day.
So eighty-one permits are issued against sixty spaces, a ratio of one point three five. That is deliberately conservative — the arithmetic would support more — because being turned away when you have a permit is a much worse experience than not having one.
A hundred and thirty-seven people apply. The rule was published two weeks before applications opened, it is applied, eighty-one people get permits and fifty-six go on a waiting list with their position visible. By March, nine permits have been reclaimed from people who used them fewer than four times, and nine people move off the list.
Design rules that shaped every decision
- Derive the ratio from measured occupancy, and re-derive it annually.
- Publish the allocation rule before applications open. Every time.
- Show waiting list position; an invisible list is assumed to be fixed.
- Reclaim on measured usage, with warning, and a way to explain.
- Accessible bays are outside the ratio, the ballot and the reclaim.
- Never enforce automatically. Every enforcement action goes through a person.
Why this shape
The value of a system here is almost entirely in consistency and visibility. A spreadsheet managed by one person produces the same allocations and produces them in a way nobody can check, which is what generates the belief that permits are given out on the basis of who asks loudest.
Everything in this design is oriented at making the process checkable: a stated rule, a recorded application of it, a visible waiting list, and usage data that makes reclaim a fact rather than a judgement.
The next four posts walk through each piece: how many permits for how many spaces, how allocation gets decided, what happens to a permit nobody uses, and why enforcement is the hard part. One diagram per post, a cost breakdown, and an engineering reference at the end.
All posts