Building With ARC: RecipeHub

Your product is more than a list of requirements, just like a recipe is more than its ingredients

Project 0001 · GitHub for Recipes

TLDR: We built a complete production version of GitHub for Recipes in less than a day with ARC. This series shows how.

New to the series? Start with 00 · Introducing Building With ARC.

In the Building With ARC series, we're exploring modern software development, taking an idea all the way through to a deployed production application. Along the way, we'll talk about how the best product and engineering teams work and build, and how teams are doing that effectively in the AI era.

This series is for anyone building or learning how to build production applications. In our next article, we'll dig into data models, business logic, and all the other ingredients but first, we need to agree on what we're making.

And we're going to do it by mixing two of my favorite things: cooking and coding.

Idea

The idea was simple to start: GitHub for Recipes.

Part of me thought that version control for recipes was actually a good idea, a great way to connect, share recipes and improve them. Part of me thought it was also a good way to approach software development, that recipes could be the perfect way to explore data modeling and product design.

And part of me thought that "forking" a recipe was just too good to pass up.

Bad puns aside, there is something special about food. A good meal brings people together, reminds you of home or makes new memories in new places. And a really great meal? That sticks with you. I bet you can recall your favorite meal right now. I was definitely thinking about the best things I've ever cooked as I started.

The pot roast that started it all.

All of those meals, at all of those restaurants, cafes and dining tables around the world, started as recipes. A list of ingredients, a handful of steps for turning raw ingredients into something special.

Vision

I might like cooking, but I'm not a professional chef, far from it. I've messed up before and I'll mess up again. Some of those misses are on me, but there are definitely recipes with room for improvement, and not just when it comes to ingredients.

Overly long, complex steps. Tricky timing. Recipes that require a photographic memory for how much of each ingredient you're supposed to add in step 7.

There's probably a whole other post about what software teams could and should learn from highly skilled chefs and kitchens, and the importance of mise en place. But that's for another time.

It's always unfortunate when a recipe goes wrong, so I knew RecipeHub could help there.

But it's even worse when it goes right and then is lost forever. You remember the meal but not what made it so special. I remember the pot roast, but not why it came together so well that night.

I knew I needed a way to track recipes, especially the changes that really worked. And I wanted to be able to share them with friends and family.

As I spent more time thinking about this, the idea turned into the vision.

RecipeHub is the best platform for recipe experimentation and collaboration.

To be the best, RecipeHub must deliver four key experiences for recipes:

1. Create it
2. Cook it
3. Evolve it
4. Share it

Discovery

Every classic recipe started out as an experiment, some curious chef wondering if these ingredients would work well together.

Every great product is an experiment as well, with a hypothesis that X is broken and it would be awesome if we could do Y instead.

The first step of that experiment should always be a prototype. One of the best things about AI-enabled coding is how accessible it has made those early prototypes. Anyone can put together a prototype that shows the vision and tests whether the idea is good, whether the solution works, and whether customers like it, love it or need it.

Prototyping is one of the most important parts of discovery, and it rarely stops with the first attempt. Every experiment teaches you something, and each iteration is an opportunity to build on what worked and improve what didn't.

Think about cooking. Imagine if every meal you ever made was your first attempt at a recipe. You'd spend your life eating under-seasoned dinners, overcooked steaks, and strange combinations of ingredients that sounded better in theory. Great cooking comes from tasting, adjusting, and trying again. Building with AI is no different.

I keep calling it an experiment because that's the best way to approach it. But experiments are driven by creativity, and creativity and curiosity are essential to the discovery process. Not every experiment works. There are misses and dead ends.

But sometimes, someone combines eggs, garlic and anchovies, serves it over romaine lettuce, and the Caesar salad is born.

At ARC, we consider prototyping an integral step of the process. Modern tooling allows for quick, high-fidelity screen mocks and fully interactive prototypes. That lets teams get feedback quickly, refining some ideas and moving away from others. Prototypes give you conviction about a given approach, so you can build even more valuable features on top of what's already working.

Here are a few of the experiments from RecipeHub's discovery.

Diff: what evolving a recipe looks like

Profile: a profile built on the vision

Syntax: structure, emerging from the prose

1. Diff: what evolving a recipe looks like. We started with the classic GitHub view: the diff. What does it look like to evolve a recipe? A side-by-side diff of a draft against the current version tracks every ingredient and step that was added, removed or changed, so each tweak is saved as a new version with a note on why.
2. Profile: a profile built on the vision. Next: what should a cook's profile show? Commits and cooks side by side in a year of activity, pinned recipes with versions, stars, forks and cook counts, and a feed of recent changes. A profile about experimenting and collaborating, not just collecting.
3. Syntax: structure, emerging from the prose. The more we prototyped, the clearer it became that a recipe holds far more structured data than its text lets on. The same ingredient notes, as published and then parsed: ingredients, roles, substitutions and linked recipes pulled out of the writing, without losing the author's voice. That structure is where our next article picks up.

Discovery creates decisions, and decisions define the product.

Those decisions can't be lost. They need to be written down as project documents: a functional spec or PRD defining what the product does. Some products need additional documents, with more detailed explanations of how key features work. As we got clearer on the experiences we wanted RecipeHub to provide, we created several documents that we'll share in our next article.

So now we have our product definition. Or do we?

Alignment

We only have a product definition if all of our decisions, documents, prototypes and the entire team are aligned. Otherwise, we have missing features, bugs and angry customers.

Good teams spend a lot of time and energy making sure they're aligned. Are they aligned on what the product does, and what it doesn't do? Are individual features aligned, creating a cohesive user experience? Most importantly, is what they're building aligned with what customers actually want or need?

Alignment is when the creativity of discovery coalesces into a valid product definition.

Your product isn't your PRD or your prototype. It's your idea, your vision, everything from discovery, and the decisions you make when you see them together.

That's why we built ARCitect, an agentic IDE for writing production-grade specifications. ARCitect works with you, understanding your screens, prototypes, diagrams and documents to define your product spec. It doesn't just pull everything together: it flags conflicts and open questions and refines feature requirements to create the best version of your product. You can read more in the ARCitect 2.0 announcement.

Alignment and a clear product definition have become even more important in the era of AI-enabled coding. Say the PRD says one thing and the prototype shows something different. You can write thousands of lines of code, and burn millions of tokens, working from conflicting definitions.

Conclusion

At ARC, we fully embrace spec-driven development. With ARCitect, we turn product documents and prototypes into complete, coherent functional specifications. Those functional specs become the single source of truth, the authoritative definition of the product.

By creating a single source of truth, we create alignment for every product on our platform. Whether you're coding yourself, working with developers or with agents, everyone is operating from the same definition.

*Originally published on the ARC blog.