Cloud Menu

The opportunity I chose to work on was straightforward: give restaurants a better way to publish and manage their menus, and give guests a clearer way to explore them.

Changing a price, updating an item, reorganizing a menu, or presenting an offer should not require a new development project. At the same time, the public experience needs to do more than display information. It should feel considered, reflect the restaurant's identity, and make browsing comfortable on a phone.

That became the product brief: make the everyday work simpler without stripping the experience of its character.

I designed Cloud Menu around the people on both sides of the screen.

For restaurant teams, the priority is control over menus, categories, items, images, and pricing, supported by clear management workflows.

For guests, the priority is a readable, responsive storefront that makes the menu easy to navigate and the food inviting to explore.

These experiences share the same underlying system, but they serve different needs. The management side needs structure. The public side needs clarity, speed, and personality.

I was responsible for both the product and the business decisions behind it. That included defining the scope, deciding what to build and what to defer, designing the interface, and implementing the application.

I also owned the database, APIs, authentication, permissions, billing, deployment, and ongoing technical work. Alongside development, I worked on pricing, plan limits, onboarding, positioning, and launch preparation.

The decisions were connected. A subscription plan affected access rules. Supporting multiple restaurant locations affected the data model and permissions. An analytics feature needed to produce information worth showing, not simply add another dashboard.

• Keep the purpose clear.

  I focused the product on the digital menu experience: publishing, presentation, management, and engagement. That gave me a clearer basis for prioritizing features instead of treating every restaurant-related idea as part of the initial scope.

• Build for everyday changes.

  The content model supports the practical details behind a menu, including categories, items, images, pricing variations, offers, and operational notes. The goal was to make those details manageable within the product rather than handle each change as a custom request.

• Treat locations as part of the business model.

  I structured subscription billing around restaurant locations, with account roles and plan limits informing what each user can access and manage. Product access, pricing, and implementation needed to follow the same logic.

• Make browsing behavior visible.

  Engagement analytics are part of the product, giving restaurants a way to understand how people explore their menus. I kept that purpose distinct from sales reporting: a menu interaction is useful information, but it is not the same thing as an order.

• Consider discovery alongside presentation.

  Search visibility, structured content, and indexation controls are part of the architecture. I wanted the menu to be useful as a public web experience, while allowing control over what should be discoverable.

The earlier version used Laravel and MySQL. After a period on hold, I returned to Cloud Menu and rebuilt the platform with a separate API, a modern web frontend, and PostgreSQL.

The purpose was to support the product I wanted to operate next, including self-service management, subscriptions, location-based access, and a clearer separation between the public storefront and the administrative experience.

AI-assisted tools also changed how I approached the work. I used them for research, development, debugging, documentation, and iteration, making a broad rebuild more manageable as a one-person venture. Product judgment, architecture decisions, and review remained my responsibility.

The rebuild brings menu management, public storefronts, user permissions, subscription billing, engagement analytics, and search controls into a connected product.

It also gave Cloud Menu a more defined operating model. Plans, access rules, onboarding, and location management are part of the application rather than separate considerations around it.

The earlier version served restaurant clients. The 2026 rebuild develops that foundation further, with a focus on self-service and the practical work involved in running a subscription product.

Building Cloud Menu made the relationship between product decisions and implementation very tangible. Pricing affects architecture. Content structure affects the browsing experience. Onboarding affects how much explanation a customer needs. Hosting decisions affect the cost of operating the business.

The work was about keeping those decisions aligned while preserving a simple experience for the people using the product.

That is the kind of product work I enjoy: understanding the business, shaping the experience, and staying close enough to the implementation to make the details hold together.