PRD ≠ Product

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.

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:

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.

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.

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.