Acapulco, Hospitality Restock Marketplace, Go/No-Go Decision

One-line outcome: I turned a promising “smart restock” marketplace into an actionable decision—pause the build until route density, supplier commitments, and unit economics could work in the real world.

TL;DR

Problem: Hospitality venues restock essentials under time pressure, but logistics, compliance, and thin margins make “just build a marketplace” risky.
What I did: Combined field research, a service blueprint, prototypes, and a unit‑economics model to convert uncertainty into clear go/no‑go criteria.
Key constraint: Asset‑heavy operations (delivery, inventory, compliance) meant every product promise had an operational and financial cost.
Outcome: I replaced guessing with go/no‑go thresholds and paused before scaling an unproven model.
Timeframe + role: 2018–2019 · Solo founder & Product/UX Lead.

Context

In 2018, just after my MBA at EOI (Escuela de Organización Industrial, Madrid), I went solo to test a hypothesis: could we make hospitality restocking predictable without pretending logistics and compliance don’t exist?

At 6 a.m., a venue owner texts a supplier: “We’ll run out of milk by noon—any chance?” The answer depends on trucks, substitutions, and goodwill. That’s the real product surface: not a catalog, but a daily rhythm under constraints.

The risky part wasn’t interface complexity. It was building an asset‑heavy business (routes, inventory, compliance) without evidence that the economics could survive real‑world variability. I spoke with investors and didn’t raise funding, which made the constraint explicit: learning had to be cheap, fast, and grounded.

My Role & Team

I ran Acapulco as a solo founder and led product and UX.

My scope: discovery on the ground, service modeling, prototype strategy, and the decision framework tying product signals to unit economics.
Decision ownership: I drove the evidence and made the call, with input from venue operators, suppliers/wholesalers, drivers, and investor conversations.
Collaborators: hospitality venues, supply partners, delivery operators, and early investors/advisors.

Constraints

Thin margins + high variability: Distance, drop size, and substitutions meant small operational misses erased profit.
Compliance and traceability: Requirements had to be captured at the point of ordering, not cleaned up later.
Route density: Without enough orders per zone, every extra kilometer killed viability.
Supplier commitments: Supplier politics and service‑level commitments were as important as product design.
No external funding: I couldn’t “build first and hope the metrics catch up.” I had to prove (or kill) assumptions before writing code.

Approach

When you can prototype quickly, the real job is deciding what’s true—and what would be expensive to learn too late.

Lean Startup principles shaped the project: start with the riskiest assumptions, run tight experiments with real users, and only “build” what changes a decision.

I sequenced the work to surface the hardest truths early:

Field research to replace assumptions. I observed stock checks, order calls, and delivery realities with venues, wholesalers, and drivers. Patterns emerged: drop sizes were often too small, routes stretched too long, and compliance paperwork arrived late. That reframed “smart” as reliability (cut‑offs, windows, traceability), not recommendations.
Service blueprint to align debate. I mapped the end‑to‑end service (ordering → picking by lot/expiry → delivery scanning → invoicing) so operational, product, and financial trade‑offs were visible in one place.
“Honest” prototypes to test promises. Delivery windows reflected the real fleet. Recurring staples were suggested but required explicit confirmation. Compliance lived in the cart (batch/lot captured and shown through receipt).
Unit‑economics model as the decision tool. I built a spreadsheet model that stress‑tested margin sensitivity by category, distance, failure rate, and drop size—so every feature idea had a cost and a threshold.

Process at a glance

Phase	What I needed to learn	Output (decision tool)
Field research	What the restock rhythm really looks like (constraints and failure modes)	Observations + constraint list
Service blueprint	Where hand-offs create cost, risk, or delays	End-to-end service blueprint (ordering → invoicing)
Honest prototypes	What we can promise without breaking operations	Prototype flows with real delivery windows + compliance in-cart
Unit economics	Viability thresholds and sensitivity drivers	Unit-economics model + go/no-go criteria

How I made the call: field research, a service blueprint, honest prototypes, and a unit-economics model produced clear prerequisites—so the responsible decision was to pause the build until route density, supplier commitments, and margins could work.


          flowchart TB
A["Field research<br/>venues, suppliers, drivers"] --> B["Service blueprint<br/>end-to-end flow"]
B --> C["Honest prototypes<br/>real windows + compliance"]
C --> D["Unit economics model<br/>stress-tested"]
D --> E{"Viability prerequisites<br/>met?"}
E -->|No| F["Pause full build<br/>define restart conditions"]
E -->|Yes| G["Run a zone pilot<br/>then build"]

Key Decisions & Trade-offs

Decision: Focus the MVP on recurring essentials + scheduled delivery windows (not an “everything store”).
- Options considered: Broad marketplace catalog; narrow recurring essentials; a zone‑based pilot to prove route density before expanding.
- Criteria used: Purchase cadence, operational predictability, and what could realistically reach viable route density.
- Trade-off accepted: Smaller catalog and saying “no” to breadth to protect learnings and economics.
- Resulting implication: The product was designed around rhythm (repeat orders) and constraints (real slots), not browsing.
Decision: Make constraints visible inside the product instead of hiding them.
- Options considered: Optimistic delivery promises with manual exception handling; compliance captured after purchase; “honest” constraints embedded in the flow.
- Criteria used: Trust, compliance risk, and the margin impact of substitutions and failed drops.
- Trade-off accepted: Less “magic” in the demo in exchange for operational integrity.
- Resulting implication: Stakeholders could evaluate the real service, not a best‑case fantasy.
Decision: Pause the full build until viability prerequisites were secured.
- Options considered: Build a coded MVP to satisfy investor expectations; keep iterating in prototype; pause and define preconditions.
- Criteria used: Unit‑economics sensitivity to distance/drop size, capital risk of inventory/fleet commitments, and the credibility cost of missed promises.
- Trade-off accepted: Slower momentum and a harder fundraising narrative in exchange for avoiding a costly, avoidable failure.
- Resulting implication: A clear restart plan (anchors + supplier service levels + zone pilot) instead of sunk‑cost acceleration.

Impact

Observable outcomes (qualitative):
- Clear go/no‑go thresholds for scaling, supported by field work and unit‑economics sensitivity analysis.
- A service blueprint that made trade‑offs discussable with suppliers and delivery operators before writing code.
- A product concept that made constraints visible (delivery windows, substitutions, traceability), which changed what I was willing to promise.
- A repeatable viability checklist I reused later when evaluating ops‑heavy ideas.

What I Learned / What I’d Do Next

For ops‑heavy products, the “product” is the service. If the economics are fragile, UX integrity means exposing constraints early so leaders can choose the right path.

Next time, I’d secure letters of intent (LOIs) from anchor venues and memoranda of understanding (MOUs) with suppliers before writing code, run a zone pilot to prove route density, and instrument product signals that roll up to unit economics (gross margin per order, utilization, and payback).