Corner Table

Corner Table started with a simple idea.

Bars and restaurants know their regulars. The bartender remembers what someone drinks. The staff recognize the people who keep coming back. Over time, those relationships become part of the place.

The founders wanted to turn that recognition into a product.

That raised a harder question:

What does it mean for software to know that someone belongs somewhere?

We couldn't make "regular" a badge people added to their own profiles. If the relationship was going to mean anything, the venue had to be part of establishing it.

The same problem appeared from the other side. Someone could say they worked at a restaurant, but Corner Table couldn't simply take their word for it. The people operating that venue needed to confirm the relationship.

Those decisions became the foundation of the first product.

A guest could ask to become a recognized regular. A member of staff could confirm them. Someone joining the industry side could request a role at a venue, but managerial approval established whether that relationship was real.

Regulars, industry people and venues could now exist in the same network without Corner Table reducing those relationships to profile labels.

That was Phase 1.

Then the question changed.

There was a real break between our two engagements.

The first version worked around a specific idea: recognize the relationships that already existed between people and venues.

But recognition alone didn't answer a larger product question.

Why would someone open Corner Table when they weren't standing inside a venue?

Before Phase 2 began, we spent months with the founders working through that question.

We could have kept expanding the original concept. More recognition mechanics. More venue discovery. More ways to represent status inside the hospitality world.

Instead, the ambition became broader.

People in hospitality already shared jobs, events, recipes, recommendations, opportunities and whatever was happening around them. They taught each other, hired each other, worked shifts together and moved between venues.

Corner Table could give that activity a place to happen.

The feed became the center of the product.

Industry users could post what was happening around them, share events and masterclasses, publish recipes, find work, discuss the industry and discover other people and venues.

Jobs became part of the same network.

So did Job in a Pinch: when a venue suddenly needed somebody for a shift, it could put that immediate need in front of people already participating in the industry rather than treating an emergency like a conventional long-running job listing.

Corner Table had changed.

What began as a product about recognition was becoming a social network for what people working in hospitality simply call the industry.

But the first product hadn't become irrelevant.

It had become more important.

The relationships established in Phase 1 gave the larger network context. Corner Table already understood people and venues, who worked where, and which relationships had actually been confirmed.

What started as the product became part of the foundation underneath it.

The product wasn't the only thing changing between phases.

The team was changing too.

Phase 2 would be built by a different P23 team, inheriting a Flutter application that was about to become considerably larger.

We could have treated that as an onboarding problem.

Instead, we treated it as an engineering problem.

Before layering the new product onto the old one, we reorganized the existing application around clearer feature boundaries and responsibilities. We did it incrementally, keeping the product working rather than disappearing into a rewrite.

The goal wasn't architectural neatness for its own sake.

It was continuity.

A codebase that only makes sense to the people who wrote it is a liability the moment the team changes. And in client work, teams change.

The next team needed to inherit a product, not just a pile of code.

That work gave Phase 2 somewhere stable to grow from.

As Corner Table expanded, it also expanded across surfaces.

The Flutter app remained the deepest experience.

Guests could discover venues, manage their profiles, request regular status, message people and build relationships around the places they visited.

For approved industry users, the product opened much further: the feed, jobs, events, recipes, masterclasses, venue and people discovery, social interaction and the wider industry network.

We also built a Next.js web app.

The obvious approach would have been to reproduce the native product in the browser.

We didn't.

The web had a different job.

It gave people another way into Corner Table: sign up, read the feed and jobs, and participate through lighter interactions such as likes, comments, replies and reports.

Creation, applications, messaging and the deeper relationship flows stayed in the native app.

The existing Remix control panel stayed too.

By Phase 2, the newer user-facing web product was being built in Next.js. Rebuilding the control panel in the same stack would have made the architecture look tidier on paper.

It wouldn't have made Corner Table better.

The control panel had a small, specific audience and already handled the operational work around approvals and managerial oversight.

So we left it alone.

The surfaces didn't need to match. They needed to make sense together.

Once Corner Table became a network, more of the product had to work when nobody had the app open.

A new job might need to reach somebody who wasn't looking at the jobs screen.

A relationship change might need to notify another person.

A photo or video uploaded from one device still needed to arrive everywhere else in a predictable form.

Those responsibilities didn't belong in individual clients.

We moved them into event-driven backend workflows.

Firestore changes could trigger matching, relationship updates and notifications. Storage uploads could trigger image and video processing, including resizing, compression and thumbnail generation.

That kept the client applications focused on the interactions people could actually see while the shared system handled the work connecting them.

The architecture followed the shape of the product.

Corner Table wasn't becoming one enormous application.

It was becoming several surfaces around the same network.

Across the two engagements, P23 worked across product shaping and the engineering behind the system that emerged from it.

The founders brought the original idea, the hospitality knowledge and the design work.

Our role was to help turn that into a product that could actually behave consistently across people, venues and different kinds of relationships — and then build the applications and infrastructure behind it.

By the end of Phase 2, that meant a Flutter application serving both guest and industry experiences, a Next.js web product, the existing Remix control panel and the Firebase systems connecting them.

But the more important change was in the product itself.

Corner Table no longer depended on one interaction between a regular and a venue.

Recognition had become one layer of a much larger network.

Both engagements were completed and formally handed over to the client.

The Phase 2 product was not publicly released.

That matters.

We can talk about what we designed, built and delivered. We can't turn a product that never reached the public into a story about adoption, growth or market impact that we don't have evidence for.

What we can show is how far the product itself moved.

Corner Table began with a question about recognition: how could a venue know who really kept coming back?

Answering it forced us to make relationships explicit.

Those relationships became the foundation of the MVP.

Then the ambition grew.

The feed, jobs, events, recipes, masterclasses, conversations and immediate staffing needs made Corner Table useful beyond the moment somebody walked into a venue.

By then, the system we had built first was doing a different job.

It was giving the larger network something a generic social product wouldn't have had:

context.

Corner Table started by recognizing relationships.

Those relationships gave it somewhere to grow.