UX/UI Design • Solutions Design • Strategy • Systems Design
Booking Engine & Marketplace Foundation
Building a Booking Engine, unifying a segmented product offering, and implementing Component Methodology to build a 0–1 application in a week.
Strategic Thesis
The problem wasn't a missing product. It was a missing spine.
Noteefy had multiple products — a waitlist tool, a confirmed booking tool, an AI chatbot — but no unifying infrastructure connecting them. They were bundled together in sales but experienced as disconnected by users. Revenue growth required either selling harder or building smarter. The decision was made to build a booking engine. But the real opportunity was bigger than that.
The one-week timeline was clarifying. It forced the only question that matters: what is the smallest thing that is genuinely true?
Starting Conditions
One Airbnb.
One week.
Zero-to-One Build.
Team
1 designer, 5 engineers, 1 product person
Deadline
Functional sales demo in 7 days from zero
Existing Infrastructure
None purpose-built for this product
Product Context
3 disconnected products, bundled in sales, fragmented in architecture
Stakeholder Expectation
A demo that could close deals with a real product behind it
Component Methodology Lens
Opportunity identification under constraint
System Diagnosis
The fragmentation had two layers.
The obvious layer was the client experience; our product offerings felt unnecessarily segmented. The less obvious layer was architectural: no shared identity layer, no shared data model, no shared UI language.
Unifying later would mean rebuilding from scratch. The booking engine was the opportunity to introduce the spine the products were missing — not by fixing old products, but by building the new one in a way the old ones could eventually attach to.
Before — Core Golf bundled, not unified
Core Golf
• Tee Sheet Integration Required
• Segmented User Experience
• Not Cohesive Product Offering
Waitlist
Manages tee time waitlist requests
Confirmed Bookings
Manages confirmed tee time records
AI Chatbot
Answers queries, no booking control
No shared layer
Separate auth, separate data models, no cross-product visibility for admins or guests
After — Unified platform
Booking Engine
• Centralized identity
• Shared data layer
• Unified UI system
Waitlist
Integrated into booking flow.
Confirmed Bookings
Enable direct tee time confirm, modification, cancellation.
AI Chatbot
Controls booking engine directly.
Method Applied
The Card as a Universal Container
The first design decision was to make a single card component the interface primitive for every piece of data in the system. Whatever the content — tee time slots, booking details, form fields — it lived in a card with content-area variants.
This let engineering build against a reliable container regardless of what data was ready, allowing design and engineering to move in parallel at sprint pace. New data types later wouldn't need new interface patterns — just new content variants within the existing container.
Card variables
A component-variable map that translated interface states into reusable implementation rules.
Card header variables
A longer spec view showing how content, action, truncation, expandable, and pricing states map back to component behavior.
View full component spec
The Differentiator
Group Golf—Architecture Before Design.
Once the core booking operations were established as the baseline, the team made a deliberate choice: ship one feature that no existing tee sheet does well, rather than more table-stakes functionality. Group Golf was that feature.
The problem it solves is one every golfer knows: you book a foursome, then spend three days managing a text chain trying to figure out who's confirmed, who's paid, whether you have enough people to keep the tee time. A coordination problem the industry had never addressed at the product level. That gap was the opportunity.
There were no formal requirements for Group Golf. What existed instead was a set of scenarios that needed resolution before anyone could design or build anything: questions about ownership, assignment, invitation, account states, and what happens when someone cancels. The flow diagrams weren't a deliverable. They were a prerequisite.
Unifying later would mean rebuilding from scratch. The booking engine was the opportunity to introduce the spine the products were missing. Not by fixing old products, but by building the new one in a way the old ones could eventually attach to.
Group Golf Flows
View document
Component Methodology
The Lead Golfer cancellation has two paths — cancel the entire tee time, or cancel just their own spot and reassign the lead role. The second is better UX. It's also not crucial for v1. Documenting it at reduced opacity is Component Methodology in practice: planned, scoped out, not forgotten.
Component Methodology in Practice
The grayed flow still hasn't been built — there hasn't been a need. But when there is, the path is already mapped. No discovery sprint, no architectural surprises, no being caught on the back foot. The planning cost was minimal. The optionality preserved is significant. This is what staying on timeline looks like from the inside: not cutting corners — cutting scope, with intention, while keeping the future visible.
Key Decisions
Four Decisions that Shaped the Architecture
The first design decision was to make a single card component the interface primitive for every piece of data in the system. Whatever the content — tee time slots, booking details, form fields — it lived in a card with content-area variants.
This let engineering build against a reliable container regardless of what data was ready, allowing design and engineering to move in parallel at sprint pace. New data types later wouldn't need new interface patterns — just new content variants within the existing container.
Systems • Velocity
Card as Universal Container
Tradeoff
Reduced visual variety in exchange for interface consistency and engineering pace.
Rationale
Under a one-week timeline, the decision that costs least and enables most wins.
Impact
Functional demo in 3 days. Pattern became the UI foundation for all subsequent product work.
Architecture • Optionality
Centralized Login
Tradeoff
Slightly more complex initial build in exchange for marketplace optionality.
Rationale
The marketplace wasn't a commitment, it was a possibility. Component Methodology identifies possibility as sufficient grounds for reusable architecture when the cost delta is low.
Impact
Now the infrastructure for a cross-product aggregated environment, currently in active development.
Strategy • Scope
One Differentiator Over More Features
Tradeoff
Narrower feature set at launch for one genuinely distinctive capability.
Rationale
Table-stakes features clear a threshold. Differentiation closes deals.
Impact
Group golf became the key demo talking point, contributing to multi-course operator partnerships.
Process • Documentation
Pattern Capture in Motion
Tradeoff
Less formal process in exchange for a pattern library that reflected real decisions.
Rationale
Documentation that precedes decisions is speculative. Documentation that captures them is accurate.
Impact
Lozenges, data-value pairs, and page hierarchy patterns carried forward into all subsequent work.
Output
The work, as evidence of the strategy.
The Card Component, Proven at Scale
The card component can be used in many ways, allowing us to rapidly build many variations to accomplish our needs.
Additional Impacts
We were able to successfully configure our AI Pro Shop Assistant to work natively with the booking engine.
Our differentiating feature of group golf required a large amount of planning and simplification.
We also added an additional card variation, the Course Card. We built multiple versions of this to ensure course branding was treated appropriately.
Outcome
What Changed.
The first design decision was to make a single card component the interface primitive for every piece of data in the system. Whatever the content — tee time slots, booking details, form fields — it lived in a card with content-area variants.
This let engineering build against a reliable container regardless of what data was ready, allowing design and engineering to move in parallel at sprint pace. New data types later wouldn't need new interface patterns — just new content variants within the existing container.
3
Days to a functional demo from a standing start
3→1
Disconnected products unified under a single platform
2mo.
Demo to released product, MCO partnerships secured
Optionality Insight
Optionality is a feature you build for before you need it.
The marketplace may never get built. The centralized login was worth building anyway — because the cost of preserving the option was low, and the cost of losing it was potentially catastrophic. When you're moving fast, the question isn't what do we need right now. It's what are we ruling out forever if we cut this corner. Those are different questions, and only one of them protects you.