Parkings aéroport · B2B SaaS
Five booking channels, one queue.
An airport parking operator sells through Parkos, through AlloPark, through its own site, by email and sometimes by API. That is five sources of truth that disagree on the morning of a busy departure day. ParkAgenda reduces them to one, then runs operations on top.
See the live systemThe problem
An operator running between one and fifty sites rarely sells through a single channel. Spaces go through resellers such as Parkos and AlloPark, through its own site, by email, and sometimes through a client API. Each channel has its own format, its own lag and its own way of cancelling.
While those flows stay separate, nobody knows how many cars actually arrive tomorrow morning. The counter recounts by hand, driver scheduling is guesswork, and overbooking is discovered in the car park rather than on a screen.
The problem is not volume. It is that the booking, the arrival, the shuttle, the vehicle handover and the payment live in five different tools, usually with a spreadsheet among them.
What we did
We built a single intake that normalises every channel into the same booking object regardless of where it came from. Resellers, the direct site, email and the API land in one queue under the same cancellation and amendment rules.
Operations sit on top of that: shuttle assignment and real-time tracking, scheduling for drivers, dispatchers and counter agents, vehicle condition capture with photos and signature, on-site payment and cash reconciliation.
The foundation is .NET 8 on Azure Functions in isolated worker mode, EF Core on SQL Server, Storage Queues to decouple intake from processing, and Application Insights for monitoring. The Domain, Application and Infrastructure split is held strictly, because a booking object arriving from five different sources becomes unmanageable the moment business rules scatter into controllers.
The application runs in the browser with no installation, on desktop, on a counter tablet and on a wall display in the operations room.
Where it stands
ParkAgenda is in production. Its public site displays the volume of reservations handled that day, so real activity is verifiable without asking us anything.
Operators get live occupancy, commission reporting per channel, and CSV and PDF exports for accounting.
We publish no quantified client gain. No operating figure was given to us for publication, and we would rather show a page with no percentage on it than a percentage nobody can check.
- .NET 8
- Azure Functions (isolated worker)
- EF Core
- SQL Server
- Azure Storage Queues
- Application Insights
The same .NET and Azure foundation as Comparkly. Two different products, one engineering discipline, which means the team that delivered one already knows how the other is structured.
Common questions
- Is ParkAgenda a JADEV product or a client project?
- It is a product we own and operate, not an engagement we delivered and left. We cite it as engineering evidence, not as a client endorsement. The distinction matters and we hold it everywhere on this site.
- Can you build the same multi-channel intake for us?
- Yes, and it is the most common pattern we are asked for: several sources of orders, stock or bookings that need to become one reliable queue. The domain changes, the normalisation and idempotency problem does not.
- Who owns the code on an equivalent project?
- You do. On a client engagement the repository and cloud accounts are yours from day one. ParkAgenda is the exception because it is our own product.
Several sources, one truth?
Describe your channels and what falls out of sync today, with no confidential code or personal data. We scope before proposing anything.
Describe my problem- Technical debt: what it costs and when to repay itHalf of what gets called technical debt is not debt. How to tell deliberate borrowing from ordinary mess, how to make the cost legible to a board, and why some of it should be left exactly where it is.
- Custom booking platform cost, block by blockFive technical blocks, a published day-rate grid from 150 to 450 EUR, and worked examples from booking platforms we operate in production.
- Payment idempotency for iDEAL and BancontactOne replayed webhook is enough to charge the same traveler twice. We explain the idempotency key design that makes it impossible, drawn from booking platforms we run in production with iDEAL and Bancontact.
- Industrial IoT data ingestion on Azure: the patternThe pattern that makes machine data ingestion into Azure survive real plant conditions: a queue between the shop floor and the cloud, priced in engineering days on our public rates.
- AutoMotoMarket.be · Used vehicle marketplaceAutoScout and mobile.de stock ingestion, CSV and XML import, verified sellers, three languages, subscription tier for dealers.
- Pavimmo · CRM migration with zero business interruptionYears of client history cleaned, mapped and reconciled, with the source system in production from the first day to the last.