Leading Design for a Food-tech Startup

The situation

Amici had a real events business but no product. The founders had a few directions in mind, and the most ambitious one was a full operational tool for event firms. My first job wasn't to draw screens. It was to decide what we should build first, before we sank months into the wrong thing.

The bet I made (and had to sell)

I pushed for starting light and going B2C first. In practice that meant treating the product as a single, high-intent booking from a simple website, instead of a heavy recurring-bookings tool with all the work-level machinery the founders had been picturing.

This was the hard one. It meant gently telling the founders that their dream product could wait, and then actually backing it up. So I owned the argument: a smaller, faster bet would teach us more, cost us less, and not paint us into a corner. I made the case, it landed, and that one decision shaped everything that came after.

I did sneak one thing in though. Even in the lean version I kept a login, so we wouldn't slam the door on recurring business customers down the line. Go light, but don't make it a one-way street.

Where AI fit (and why not yet)

AI was a big part of the founders' vision. I talked it out of the first release. With no product and no traffic, there was nothing for it to stand on yet. But I made sure the data model wouldn't fight us later, so it stays a genuine option once there's something real to build on. Not now, but not never.

Designing to learn, not to ship

Since this is a beta, success isn't a launch. It's knowing what to build next. So the whole thing is set up to surface gaps. Do people actually want recurring bookings? Are they expecting us to sort out transport too? Which type of customer leans in hardest? Every flow is really just a question we're asking the market.

Mapping the operational flows

Before any of the screens, I spent real time aligning the team on the operational flows: what the early product needed to support, and which steps we could happily leave out.

Wireframing the main screens

I sketched the key screens in low fidelity first, so we could argue about structure and flow before anyone got attached to pixels.

The end-user experience

Working closely with our developer, I designed the full booking flow, from landing on the site to receiving an offer. A closer look:

Behind the scenes

Every booking is handled manually for now, so I also designed the admin side the team uses to run things: tracking request statuses, looping in chefs and partners, building offers, and chasing payments.

A foundation to build on

Underneath it all I built a simple but capable design system, so both the customer and chef-facing flows stay consistent and the next features don't start from scratch.

Beyond the screens

Owning the product also meant owning how it showed up elsewhere. One example: a one-pager I designed for sales and marketing to pitch the service.

An early nibble

We're also in early conversations with an event agency about partnering up to find synergies between their day-to-day and our tool. Nothing signed yet and still very much to be decided, but it's a nice early sign that the direction resonates with the people who do this for a living.

Leading the team

I was the only designer, working alongside two non-technical founders and one developer. I owned the product decisions in the room with the founders, turning a broad vision into something we could actually build. And I worked closely with our developer on the classic startup question: where to take smart shortcuts, and where to build something solid so the lean beta wouldn't quietly turn into a dead end.

Status

Right now it's a beta on its way to launch. The whole point of this phase is validation: confirm who it's really for, sharpen the pitch, and let real demand decide what graduates out of beta.