SnapMenu started inside Alex’s sales process, not on a product roadmap. His instinct for cold outreach was to show, not tell — rather than describe what Edible could do for a restaurant, send the prospect a live demo of their own menu, already rendered in Edible. When a restaurant saw their menu working — formatted, allergen-aware, ready to share — the value landed in a way no generic demo could match.

The problem was the process behind it. For every prospect, Alex would find what menus they had publicly available on Google or their site, then use Edible’s existing dashboard — a series of forms and steps — to recreate the menu by hand: create a menu, add a section, write the section title, add a menu item, define allergen information, repeat for every item and every section. The dashboard ultimately produces a JSON object that powers Edible’s menu viewer; Alex was effectively transcribing a restaurant’s menu by hand into that JSON, item by item, so the viewer could render a demo link he could send.

Edible could already render menus from JSON — the viewer was the cheap, reliable part of the pipeline. The slow part was upstream: turning a photo of a menu, or a photo of an allergen spreadsheet, into the structured JSON the viewer needed. So we built SnapMenu as an LLM-backed microservice that automates exactly that step.

SnapMenu accepts photos — menu cards, allergen spreadsheets, whatever Alex finds while prospecting — and runs them through an LLM with a prompt we wrote against Edible’s existing JSON schema. The output drops straight into the same pipeline the manual dashboard produces, so the rendered demo is indistinguishable from a hand-built one, just produced in a fraction of the time.

Alex uses SnapMenu as a service: upload the photos he collected during prospecting, receive back a generated menu JSON and a demo link he can send. What used to take an evening became a review and a send — and combined with the menu embed, the demo link is something a restaurant can place natively on its own site rather than only on a hosted URL. The sales process didn’t change. The ceiling on it did.

The purpose at the outset was to solve Alex’s sales-time problem. In doing it, we ended up creating a feature for the application itself. The same SnapMenu service is now used in two places inside the product:

• Onboarding. New users no longer face the same form-by-form click-through Alex was doing manually. They upload a few photos of their existing menu, and SnapMenu generates an initial draft to refine.
• Inside the dashboard. Existing users can seed new menu creation via SnapMenu rather than building from a blank form every time.

That matters specifically because of what Edible is for. A large part of Edible’s value proposition is removing the operational friction between the kitchen (who drafts a menu) and the front-of-house (who has to publish it and pass on the allergen information). The form-by-form transcription was exactly the kind of friction Edible exists to remove — and SnapMenu now removes it at onboarding and at every menu update.

There is also a tighter link between sales and product now. The thing that greets a new user on day one is the same thing that powers Alex’s outreach. What gets shown in a demo is what someone gets when they sign up.

Edible was constructed around a builder that generates JSON. From the start, we hosted the menus on Edible’s own domain at whatisedible.com/<restaurant>/menu — the dashboard produced the JSON, a hosted viewer rendered it, restaurants got a link. The viewer worked well enough that we could ask restaurants to add it to their Google profile or link to it from their own site.

That viewer still exists, and it is not going away. It is moving toward a different purpose: a directory where end users — diners, especially those with dietary restrictions — can discover and search across restaurant menus that use Edible. A complementary use case, not a replacement.

Most restaurants Edible serves already have a website. Their own domain, their own branding, their own fonts and colours — a site that is already part of their digital presence. Asking them to send their customers off to a whatisedible.com URL was the wrong fit. The challenge was giving them something more useful inside the ecosystem they already have, rather than asking them to point away from it.

We built a menu embed: a way for a restaurant’s Edible-managed menu to live directly on their own website. The architecture has two parts that we publish and distribute separately.

The data is the JSON the builder has always produced — but when a restaurant publishes their menu, that JSON is published to a bucket. It becomes accessible as a published asset rather than only consumed internally by Edible’s hosted viewer.

The component is the embed itself — a small static application layer, published as an asset rather than as an application hosted per-restaurant.

The two pieces are tied together by a snippet the restaurant receives when they publish their menu. They paste it into their web page; it loads the static embed component and the menu JSON; the menu renders inside their site. No hosting, no build step, no developer involvement beyond pasting it in.

The embed is set up so that, when placed on a restaurant’s site, the styles lift from the surrounding page. The font, the background colour, the surrounding type weight — the menu conforms to the restaurant’s digital space rather than looking like a foreign object pasted in.

On top of that, we are adding controls for restaurants to deliberately custom-style their embed — so they can set how the menu looks rather than only relying on inheritance. Sensible defaults, opt-in customisation.

The embed is what makes the SnapMenu workflow land end-to-end. Photo → SnapMenu → JSON → embed. A live, brand-respecting demo link in minutes — exactly the artefact that turns Alex’s outreach into a real conversation. The two pieces were built independently, for different reasons. They end up doing more together than either does alone.