The restaurant had no clear online presence and most customers were finding them on their phones, so the site needed to be mobile-first from the start.

Primary users were customers checking menus, hours, and location on mobile. The main constraints were a limited budget, no existing brand system, and a strong need for simplicity both for users and for the owners managing content long-term.

I started with conversations with the owner to understand their goals and frustrations. Based on that, I scoped the site around what mattered most to users: the menu across multiple categories, key information like hours and location, and an events gallery. From there I moved into wireframes, UI design, and implementation, building reusable components and integrating content through the CMS API to keep the architecture maintainable as the menu grew.

I prioritized clarity, fast load times, and accessibility over visual complexity. Given the volume of menu items, information architecture was the central design challenge, which was getting 300+ items to feel navigable without overwhelming users. I chose a headless CMS early on so the owners would have full independence from developers for content updates, which mattered more than any individual design decision given their constraints.

Since launch I've continued making small improvements such as migrating static content into the CMS, refining layouts, and keeping dependencies updated. It's been more of an ongoing relationship than a clean handoff, which in retrospect reflects how I'd approach similar projects from the start: designing for ongoing iteration rather than a one-time delivery. If I revisited it, I'd rework the desktop hero though, given that most traffic comes from mobile, it's never been the priority.