A parking management app is a permit list that knows which bay is free.
Most of the work in a parking management app is not the map and not the payments. It is the small set of records that say who holds a permit, which bay it points at, when it expires, and who is next in line when it does. A site with 90 bays and 140 staff is a queueing problem with a car park attached. The same records sit under property management apps, which is why the two so often get built by the same person.
This page covers what those records have to hold, what it costs to read a licence plate from a photo, how many bays the accessibility standard takes off the table before you allocate anything, and why allocation is the part that causes arguments.
Work out the accessible bay countThe short version
The bays are fixed, the demand is not.
A car park does not grow. The number of people who want to use it changes every week: new starters, contractors, a visitor at ten, a van that needs the loading bay at nine. Every parking problem that ends up in software is the same one, handing out a fixed number of spaces fairly and then being able to show what you handed out.
So the first question is not which system to buy. It is which of these you actually have: a permit problem, a visitor problem, an enforcement problem, or a payment problem. They need different builds, and most sites only really have one of them.
What the app is actually storing
Start with the records, because every screen later is a view of them. A bay has a number, a status and a type: standard, accessible, electric, motorcycle or loading. A permit has a holder, a start date, an end date and a scope: one named bay, any bay in a zone, or a right to look for a space. A vehicle has a plate, a make and a colour, and it belongs to the holder, not to the permit, because people change cars.
Keeping vehicles separate from permits is the one decision that saves the most trouble later. Somebody with two cars, and a hire car for a fortnight while theirs is in the garage, is normal. A parking permit app that stores one plate per permit makes that person phone the office every time reality changes, and a system that generates phone calls has not replaced anything.
Then there is the history, which is what homemade systems drop first. Who held bay 42 in March, when the permit came back, who approved the contractor exception in June. The shape is the same as an asset tracking app: a thing, a holder, a period, and a record that outlives both. Keep that log append only, because a permit row edited in place cannot answer the question people ask six months later, which is always some version of who said this was allowed.
Reading a licence plate from a photo costs money per photo
The feature people ask for first is a camera that reads plates. It is real, and it is not free. Turning a photo into a plate number needs an OCR service, and the plate aware ones are priced per lookup. Plate Recognizer publishes its Snapshot pricing openly: 2,500 lookups a month free, then 50,000 a month for $50, 250,000 for $150 and 500,000 for $250, with the same figures for the cloud API and the on premise SDK, and half as much again if you also want make, model and colour. Its continuous camera product, Stream, is priced per camera instead, at $35 a month.
A general OCR service is cheaper per image but knows nothing about plates: Google Cloud Vision lists text detection free for the first 1,000 units a month, then $1.50 per 1,000 after that. Both sets of figures were checked in September 2026 and both can change. The volume is lower than people fear: one photo per arrival at a 90 bay site is about 4,000 lookups a month, inside the smallest paid tier. A camera watching a lane all day is the expensive shape, because it is billed per camera rather than per read.
The other way to know a car is there is proximity rather than a photo, and mobile gets thin here. Bluetooth beacons work and are imprecise, good for a zone and useless for a bay. Ultra wideband would answer the bay level question properly, and React Native has no first party ultra wideband module. Apple's Nearby Interaction framework and the Android UWB API are native, with no wrapper in React Native core, so using them means native code on both platforms. Treat bay level positioning as a native project, not a checkbox.
However you read a plate, treat the result as evidence and not as a verdict. Character confusion, mud, a tow bar and a low sun all produce wrong reads. Put a person and the original photo in front of any charge, clamp or warning letter, because the cost of a bad read lands on someone who then has to prove a negative.
Accessible bays are a count you do not set
Before you allocate a single space you need to know how many are not yours to allocate. In the 2010 ADA Standards, Table 208.2 sets the minimum number of accessible spaces by the size of the parking facility: 1 where the facility has 1 to 25 spaces, 2 for 26 to 50, 4 for 76 to 100, 6 for 151 to 200, 9 for 401 to 500, 2 percent of the total from 501 to 1000, and above that 20 plus 1 for each 100, or fraction of 100, over 1000. Section 208.2.4 then says that for every six, or fraction of six, of those required spaces, at least one has to be a van space.
Two details catch people out. The count is per parking facility rather than per site, so two lots at one address are worked out separately and the totals are not pooled. And the general table is not universal: parking serving hospital outpatient facilities is 10 percent, rehabilitation and outpatient physical therapy facilities are 20 percent, and residential parking has its own rules in 208.2.3.
Software does not make a car park compliant. The counts are arithmetic. The rest is physical: space and access aisle widths, surface slope, signage, and a route from the bay to the entrance. What an app can do is hold the count, refuse to issue an ordinary permit against an accessible bay, and flag a car parked in one without the right to be. It cannot discharge the duty, and the calculator below is a sketch, not advice. Check the standard and your local code with someone qualified.
US Access Board, 2010 ADA Standards, section 208 Parking Spaces
Try it
How many bays are not yours to allocate
Table 208.2 of the 2010 ADA Standards sets a minimum per parking facility. Two lots at one address are counted separately.
5
accessible spaces, minimum
1
of those, van spaces
115
left for ordinary permits
Hospital outpatient, rehabilitation and residential parking follow different rules, and dimensions, aisles, slope and signage still have to be right. Check the standard and your local code.
Allocation is the part that causes arguments
Once the bays are counted, the question is who gets one, and that is a policy problem in technical clothing. Seniority, distance from home, car sharing, shift pattern, a blue badge, whoever asked first in 2019. Where the car park belongs to a residents' association the rule set is the community's rule set, the same territory as an hoa community app, and the software's job is to apply the rule the same way every time rather than to invent it. A rule that cannot be written down in plain words is a habit, and it will be argued about inside the app instead of in the corridor.
The mechanism that earns its keep is the release. On any given day a good share of permit holders are not coming in. A staff parking app that lets someone give up their bay the night before, and passes it to the top of the waitlist automatically, adds usable capacity without adding a single space. It also produces the only number anyone upstairs cares about: how full the car park really was, as opposed to how many permits were issued.
Visitors are a separate flow, not a smaller permit. A visitor is booked by a host, comes once, needs a plate captured at booking time and an expiry the same evening. Folding them into the permit table is how a parking lot management app ends up with thousands of dead rows and a search that returns nothing useful. Give them their own record with a short life.
Enforcement comes last and is mostly a walk. Someone with a phone records the bay, the plate and a photo, and the app answers one question: is this plate allowed here, right now. For a lot of sites that single answer is the whole product, and everything else on this page is optional.
What each approach gives you
| Approach | Knows who holds each bay | Handles the waitlist | Reads plates | Fits your own rules |
|---|---|---|---|---|
| Spreadsheet and an email thread | Yes | by hand | No | Yes |
| Printed permits on the dashboard | only on a walk round | No | No | Yes |
| Public pay and display platform | No | No | depends on the product | No |
| Barrier hardware with plate cameras | Yes | No | Yes | the vendor's rules |
| An app you build | Yes | Yes | if you pay per lookup | Yes |
Building one around your own car park
Parking platforms are built for operators: multiple sites, paid public parking, enforcement contracts, hardware on the gate. An office with one lot, 90 bays and a waitlist is paying for a category it is not in, and still cannot express the two rules it actually runs on, that the loading bays are free after four and that the night shift does not count against the day quota.
Newly is an AI app builder. You describe the app you want, including the allocation rules your site really uses, and it writes a real React Native and Expo project you own, runs it on a cloud simulator while it builds, and ships it to TestFlight and to Google Play internal testing. It costs $25 a month and there is no free plan. It does not come with a plate recognition service, barrier hardware or built in payments, so treat each of those as a separate decision with its own bill.
One thing worth settling early is how much mapping you need. A coloured plan of your own lot with numbered bays is drawing, not mapping, and it is far simpler than putting a lot on a map with live positions on it. Most sites need the first and end up paying for the second by accident.
Questions people ask about parking management apps
It holds the record of which bays exist, who holds a permit for which bay and until when, which vehicles belong to that person, who is on the waitlist, and what happened over time. Cameras, barriers and payments all sit on top of that record. If the record is wrong, nothing above it helps.
Describe the rules your car park actually runs on
Write down who gets a bay, who is next when one is released, and what a visitor needs, then build the permit list around those rules instead of somebody else's.
Start building