FOOD HALL MARKETPLACE • B2B PROPTECH • 2026
From offline leaks to an end-to-end B2B Marketplace
TIMELINE
4 months
ROLE
Lead Product Designer (Me!)
TEAM
Head of Product
Lead Developer
Engineering Team
COO
TL;DR
Legacy white-label sites on subdomains were buried in hall footers. Tenants used them merely as a digital catalog, while 100% of actual bookings, contracts, and payments leaked into phone calls and spreadsheets.
I convinced the business to execute a strategic shift. Moving from passive white-label subdomains to a unified B2B aggregator with a hall-first discovery model. I designed the complete end-to-end transactional flow for tenants and an operational console for hall managers.
SOLUTION
Transforming white-label subdomains into a central B2B marketplace
My main role in the project was not just designing the interface, but above all convincing the business to make a strategic shift: moving away from passive, white-label sites on subdomains towards a single, central B2B aggregator paired with a new discovery model (hall-first).
I designed two complete, interconnected user journeys in the product:
Hall Manager console
A dedicated operational environment allowing managers to set up properties, define global pricing and blackout rules, efficiently process the booking queue, and monitor occupancy rates.
I highlight two key moments from the manager journey:
Operational console with booking queue
A clear management panel allowing admins to quickly verify data, filter bookings, and smoothly update request statuses.
Automatic rule inheritance
Defining prices and blackout dates globally at the property level, automatically applied across all spaces inside with a clear indicator of the rule's origin.
Tenant journey
A comprehensive transactional flow taking the user from food hall discovery and space selection, through a two-step booking request, all the way to e-signing the rental agreement and online payment.
I highlight two key moments from the tenant journey:
Hall-first discovery model
Presenting spaces built around the reputation, foot traffic, and character of the food hall itself, alongside the context of neighboring vendors.
Progressive request form
A streamlined booking request with minimal fields, where account creation happens only at the very end of configuring the request.
OVERVIEW
Scaling B2B rentals for global food halls
The Hungry Place is a B2B SaaS platform in the commercial real estate space, used by one of the largest food hall operators in the world. The product handles short-term commercial space rentals (pop-ups, stalls, shop units, promotional booths, marketing activations) in food halls and covered markets.
Adapting core booking flows for multi-country compliance
The product previously operated under a white-label model on client-branded subdomains across three international markets. My role was to adapt the interface of the new booking flow to different fiscal policies, local taxes, and currencies across these markets, while ensuring seamless scalability for future regions (such as the US).
Cross-functional product triad leadership
I worked as a Lead Product Designer within a cross-functional team, collaborating directly with the Director of Product, Chief Operating Officer, Lead Developer, and the engineering team.
PROBLEM
Fragile PHP monolith blocking product growth and global scaling
The previous version of the platform relied on an outdated PHP monolith that had reached its architectural limits. The codebase was tightly coupled, meaning even minor changes or new feature deployments triggered unpredictable breakages across other parts of the application.
Pivoting engineering focus from bug-fixing to product value
As a result, the engineering team spent more time fixing recurring regressions than delivering actual value to users and the business. Our primary goal was to design a brand-new booking flow from scratch—solving current user pain points, building a flexible foundation for validating and gathering demand for new features, and enabling future product growth.
INITIAL FINDINGS
Uncovering offline workarounds and leaky funnels
During discovery interviews with hall managers, I spoke with a manager at one of the key food halls. Our white-label site was buried at the very bottom of the food hall's footer, making it extremely difficult for tenants to discover it in the first place.
Diagnosing the broken off-platform booking loop
Consequently, the entire journey was severely broken: tenants called the hall asking about space availability, were redirected to the footer link to browse the catalog on a subdomain, and then called the hall back to specify which stall they were interested in.
No actual bookings occurred within the product. The entire core transaction—price negotiation, scheduling, contract generation, and payment—happened completely outside the system via spreadsheets, phone calls, and traditional mail.
GOALS
Aligning tenant workflows and manager controls
When designing the new platform, I set clear business filters and goals for every user role in the system:
Vendors
Operational relief for managers
Tenants can independently search, compare, and select spaces without requiring constant phone consultations.
Conversion retained in product
The product end-to-end supports the tenant at every stage—from request submission, through contract e-signing, to online payment.
Friction reduction at entry
Requiring only essential information at each stage, eliminating unnecessary upfront paperwork.
Admins
Multi-tenant scalability
A platform operating seamlessly across diverse markets and venue sizes, tailored to enterprise requirements.
Managers
Retaining managers in product
The app serves not just as a mirror of the tenant flow, but provides managers with a global view of bookings, occupancy rates, and financial transactions.
DESIGN PROCESS
Resolving user-flow dependencies through alignment workshops
Initially, we set out to design pre-assigned items from the roadmap: login screens, admin dashboard, and tenant profile. However, we quickly hit a wall—we couldn't properly design these screens because they depended on product decisions scheduled to be made much later in the roadmap.
Instead of hitting these blockers one by one as we moved through views, I proposed a dedicated session and facilitated a 3-workshop series. This allowed us to map the end-to-end flow and resolve these blockers upfront. Furthermore, initiating this workshop shifted our delivery sequence, prioritizing the areas most critical to solving our core problems first.
Pivoting from white-label subdomains to a demand-generating B2B portal
The previous model relied on white-label subdomains tied to individual halls. I observed that complete dependence on hall branding hindered our ability to build brand recognition and drive independent marketing campaigns.
Pitching C-level on a central demand-generation portal
I proposed building a single, centralized portal aggregating all food halls. This gave us a platform to establish our own brand and drive SEO rankings. I presented this concept to executive leadership (C-level), who brought aligned market insights: the industry didn't need another passive booking engine, but an active demand-generation engine. This sealed our transition to a central aggregator.
Accelerating design iterations with Cursor, Storybook and code commits
I leveraged AI tools to radically shorten the feedback loop while maintaining full autonomy over product decisions. I experimented early on with Claude for ideation, then tested Figma MCP for automated design-to-code conversion. I quickly abandoned Figma MCP due to impractical token costs and corrupted frame structures in design files.
Bridging design and engineering via Cursor and Storybook
Instead, I moved my workflow directly into the development environment (Cursor) and set up Storybook alongside the engineers. I committed component code directly to the repository, pulling styles and UI elements to build the application.
This enabled me to deliver interactive code prototypes at high speed. The team used these live prototypes not only for rapid decision-making and battle-testing edge cases, but for actual production implementation. As a result, Figma's role evolved—from a design creation tool to, at times, lightweight documentation for what developers had already received in code.
I later shared learnings from this workflow at AI Design Labs and industry webinars.
TRADE-OFFS
Balancing market launch speed with feature scope
When scoping the initial release of the platform, I made several tough design trade-offs to balance user value with speed-to-market:
Replacing the interactive map with neighboring vendors on cards
Designing an interactive floorplan was prohibitively expensive and time-consuming. Instead of a complex map, I proposed simple cards displaying adjacent vendors („Neighbors: Coffee bar, Bakery, Wine bar”). This was a fraction of the implementation cost while immediately answering the tenant's core question: are target customer demographics walking by this space?
Streamlining the request form
I initially aimed for tenants to configure their entire request anonymously and create an account at the very end of configuring the request. Due to system architecture constraints, guest submission wasn't feasible—requests required authentication. In exchange, I negotiated reducing form fields to the absolute minimum, cutting initial onboarding friction down to a few clicks.
OUTCOME
Unifying the end-to-end leasing lifecycle in a single platform
A single central portal
Built a robust B2B aggregator that established brand recognition in the CRE space and drove daily engagement among hall managers.
Closed rental lifecycle
Unified the complete journey in one product—from food hall discovery, through request negotiation, to e-signing rental agreements and online payments.
Scalable architecture
Delivered a flexible system equipped to handle multi-region tax, currency, and compliance requirements seamlessly.
WHAT’S NEXT
Analytics dashboards, Mapbox visual search and in-app feedback
Subsequent phases of the product roadmap include an analytics and reporting dashboard for hall managers, Mapbox integration for geographic visualization, and an in-app user feedback module. We continue gathering feedback from managers and validating the tenant flow for upcoming feature releases.
REFLECTION
Preventing offline leakage and defending key architectural choices
Looking back at the project, I would dive even deeper into tenant behavior at the very top of the funnel – specifically what triggers a user to drop out of the digital flow and pick up the phone. The phone call remains our hidden competitor, and there are further digital touchpoints we could design to keep users inside the system.
Validating the strategic impact of aggregator architecture
On the other hand, I would unhesitatingly defend our decision to shift to a central aggregator and adopt a hall-first search logic. These two strategic moves gave the product its market identity and transformed hall managers into active, engaged platform users.
LET’S TALK
Happy to walk through the decisions this write-up compresses into a paragraph each.
