Comensalaqui: My First Startup Was a Restaurant Platform

My first real web startup was a restaurant discovery and reservation platform called Comensalaqui, built for the US-Mexico border region.

The name is a play on Spanish: "come aqui" means "eat here," and "comensal" means "diner." It was the kind of name that works perfectly in one language and is completely opaque in another. That linguistic duality turned out to be a metaphor for the entire product: great for the local market, impossible to explain to anyone outside it.

Comensalaqui taught me more about building products than any course, book, or hackathon. Not because it succeeded (it didn't become a lasting business). Because it forced me to deal with every dimension of product building simultaneously: technology, design, marketing, sales, operations, and the cold reality that building something people can use is different from building something people will use.

The Problem I Saw

Living on the US-Mexico border, specifically the Tijuana-San Diego corridor, means living in a culinary paradise that's invisible to technology.

Tijuana has one of the most vibrant food scenes in North America. Craft breweries, innovative taco shops, upscale restaurants mixing Mexican and Asian cuisines, street food that rivals anything in Mexico City. San Diego has its own food culture: seafood, farm-to-table, the growing craft scene.

But finding these places was fragmented. Yelp worked for San Diego but barely existed for Tijuana. Google Maps had locations but no curation or community. TripAdvisor covered tourist spots but missed the places locals actually loved. Instagram showed beautiful food photos but offered no information about hours, prices, or how to get there.

The border added a unique complication. People who live in the border region eat on both sides. A San Diegan might have lunch in Tijuana and dinner back in the US. A Tijuanense might celebrate a birthday at a San Diego steakhouse. No existing platform served this cross-border dining behavior.

Comensalaqui was meant to be the food platform for the border: bilingual, cross-border, curated by locals.

What I Built

The platform had three core features:

Restaurant discovery. Curated listings with photos, menus, hours, location, and cross-border context (parking near the border, walkability from the crossing, which currency they accept). Each listing was tagged for cuisine type, price range, and what it was best for: date night, family dinner, quick lunch, late night.

Reservations. For restaurants that accepted them (many in Mexico don't use reservation systems), users could book a table through the app. This was the intended business model, a commission on each reservation.

Community reviews. User-generated ratings and reviews, with the critical difference that reviewers could specify whether they were locals or visitors. A local's review carries different weight than a tourist's, and the platform reflected that.

The technology was straightforward: Node.js, Express, MongoDB, a responsive web application. The stack didn't matter. The content and the market did.

What I Learned About Local Markets

Local markets are trust markets. In San Diego, people trust Yelp because they've used it before. In Tijuana, people trust word of mouth because they've been burned by unreliable platforms before. Comensalaqui had to earn trust on both sides of the border, using different trust signals for each audience.

For the US side, trust came from design quality and feature parity with platforms they already knew. "This looks like Yelp but for the border" was a compliment, not a criticism. For the Mexico side, trust came from local knowledge. If the platform knew that Tacos El Franc is only open after 6 PM and doesn't have a sign (just a cart near the hospital) then the platform was credible.

Restaurants are terrible customers. This isn't unique to the border. Every restaurant tech startup discovers this eventually. Restaurant owners are busy, skeptical of technology, burned by previous platforms, and operating on margins thin enough that any new expense requires immediate ROI.

Selling to restaurants meant showing up in person, during off-hours (never during service), with a demo on my phone, and explaining the value proposition in under three minutes. If the owner was interested, they'd want setup done immediately. "Come back later" meant "never." If they weren't interested, no follow-up would change their mind.

Cross-border adds complexity to everything. Payments in two currencies. Content in two languages. Legal compliance in two countries. Marketing across two cultures. Server infrastructure that serves users with very different internet quality (fiber in San Diego, spotty mobile in parts of Tijuana).

Every feature that was simple in a single-market product became complicated in a cross-border product. Every decision had two versions. Every bug had two contexts.

The Business Model Problem

Comensalaqui's intended business model was reservation commissions, a small fee per seated reservation. This model works for OpenTable in the US because American restaurants are accustomed to paying for reservations and the volume is high enough to make small commissions meaningful.

On the border, this model had three fatal problems:

Most Mexican restaurants don't take reservations. The dining culture in Tijuana is walk-in. Even popular restaurants seat you when you arrive. A reservation system for restaurants that don't use reservations is a solution without a problem.

The volume wasn't there. Even with hundreds of restaurants listed, the border dining market is small. Thousands of diners, not millions. At a few dollars per reservation, the math didn't work unless the conversion rate was extraordinary.

Restaurants expected free. After years of free listings on Facebook, Google, and Instagram, restaurant owners on both sides of the border expected digital presence to be free. Asking them to pay for reservations, when their customers could just walk in or call, was a hard sell.

I tried alternative models: restaurant advertising, premium listings, partnership deals with food festivals. None generated meaningful revenue. The market was too small and too accustomed to free.

Why It Mattered Anyway

Comensalaqui didn't become a business. But it became something more valuable: an education.

I learned to ship. Not a tutorial project or a side project, but a product with real listings, real users, and real feedback. I learned the difference between code that runs on my laptop and code that runs in production. They're different things.

I learned to sell. Walking into restaurants, pitching the platform, handling objections. This was my first experience with direct sales. The skills transferred to every product I've built since. If you can sell to a skeptical restaurant owner during the pre-lunch rush, you can sell to anyone.

I learned that markets matter more than products. Comensalaqui was a good product in a difficult market. A mediocre product in a better market would have done better. This lesson (choose your market before you choose your features) has guided every product decision since.

I learned about bilingual product design. Not just translation, but genuinely serving two language communities with different expectations, behaviors, and trust models. This skill directly applies to building products for international aviation markets, which I was already doing with Aviation Infinity.

I learned about content as a moat. The most valuable part of Comensalaqui wasn't the code; it was the curated restaurant data. Accurate hours, real photos, cross-border context, local insights. This content took months to build and couldn't be replicated by copying the code. Every product I've built since has a content component that serves as a competitive moat.

The Transition

Comensalaqui wound down slowly rather than shutting down dramatically. Traffic plateaued. Restaurant partnerships lapsed. I stopped adding new listings. Eventually, the site went offline.

But the transition wasn't from failure to nothing. It was a reallocation of energy. I'd already been building aviation products since 2008 — Aviation Infinity was on the App Store, AvioSharing and New Pilot Shop were live. The contrast between Comensalaqui's struggle and my aviation products' traction made the lesson obvious.

The difference was the market. Aviation had institutional buyers (flight schools), recurring needs (exam preparation isn't a one-time purchase), and a willingness to pay (pilot training is already expensive, so a useful tool at a reasonable price is easily justified). Comensalaqui had a market that expected free.

Comensalaqui taught me web development and local market dynamics. My aviation products had already proven I could build for a real market. Combining those lessons — web skills from Comensalaqui, domain expertise from aviation — is what unlocked the next phase of growth.