ParkPro — Building a Two-Sided Marketplace From Zero

A greenfield marketplace connecting drivers to bookable parking. What it taught us about sequencing an architecture when there is no existing system to inherit.

Executive summary

ParkPro arrived with an idea and no system: a marketplace connecting drivers with venues, stadiums, and businesses that have safe parking to sell. Greenfield work is deceptively attractive — there is no legacy to fight — but that freedom is the difficulty. When nothing exists, every architectural layer is a decision you own. We sequenced the build from the bottom of the SKF-001 pyramid upward and reached production in six months.

The organization

ParkPro was early-stage: a clear business thesis, no internal engineering team, and no existing technology. We acted as their architecture and delivery team rather than a vendor executing a fixed spec.

The problem

A two-sided marketplace has two customers with different incentives. Drivers need to find, book, and pay for a space in real time. Owners need to list inventory, set pricing, and get paid reliably. Both sides depend on a single fact being correct at all times: is this space actually available right now? That question — not the app, not the payment flow — was the real product.

Constraints

• No existing team or stack — everything was a first decision, with no precedent to inherit.
• A cold-start problem: neither side is useful without the other, so both had to launch together.
• Speed to market, on an early-stage budget.
• Two client surfaces from day one — a driver-facing mobile app and an owner-facing portal.

Architecture

We resisted the common greenfield instinct to start at the visible layer — the app — and instead built upward:

Business model — marketplace liquidity, pricing, payouts
   ↑
Operational data — canonical model of spaces, availability, bookings
   ↑
Automation — booking lifecycle, payment capture, notifications
   ↑
Applications — driver app · owner portal
   ↑
Experience — mobile and web booking flows

The availability and booking model sat at the center. Getting it right meant a single source of truth that both the mobile app and the owner portal could trust, which is why we invested there before building either surface.

Implementation

We worked in person with the founding team during key decision windows. Compressing the feedback loop mattered more on a greenfield build than on any other kind — there was no existing behavior to reverse-engineer, so every ambiguity had to be resolved by conversation, not by reading code.

Results

ParkPro went from concept to a production-ready platform in six months. The engagement delivered both client surfaces and the brand identity — logo, UX, and UI — in scope.

Tradeoffs

MongoDB's flexibility accelerated early iteration but pushed schema discipline into application code rather than the database. That is an acceptable trade for a product still finding its shape; it becomes debt worth repaying once the domain model stabilizes. We recorded it as a known future decision rather than pretending it was free.

Lessons learned

• On a marketplace, the operational data model is the product. Availability is far harder than it looks.
• Greenfield speed comes from sequencing layers, not skipping them.
• A shared operational base let one model serve both web and mobile — build it once, below the surfaces.
• Cold-start is solved by concentrating both sides of supply and demand in the same place at launch.

Related knowledge

• SKF-001 — The Summit Architecture Pyramid (framework applied here)
• SKM-001 — The Summit Architecture Pyramid (module)
• SKC-002 — Samsonite, a contrasting brownfield engagement
• SKC-004 — DataExpandr, positioning and experience-layer work