Compiling Dinner
When you read a recipe, you’re already programming. Ingredients are inputs. Actions—chop, stir, simmer—are instructions. The kitchen is your runtime environment, and you, the cook, are the processor. If you follow the recipe to the letter, you get the expected output: a finished dish. Miss a step, and you’ve introduced a bug. Burn the onions, and you’ve hit a runtime error.
Seen this way, recipes are languages, and cooking is compilation.
⸻
Recipes as Grammar
Sketching Compilers Beyond Code
Every programmer remembers the first time they encountered a compiler not as a tool, but as a system. The pipeline—lexing, parsing, semantics, code generation—was presented as the machinery that turned human-readable source into machine-executable instructions. It felt both arcane and essential, a rite of passage into serious computer science.
But the notion of a compiler has always been broader than C turning into assembly. A compiler is any bridge between intent and execution. It takes structure in one domain, transforms it through rules, and produces something runnable in another.
For decades, that metaphor lived mostly inside programming languages. With Large Language Models, it’s beginning to expand.
⸻
Great — here’s a pitch deck skeleton built directly from your transcript themes and the memo. Each slide has the core idea + bullets you could expand with visuals later:
⸻
Pitch Deck Skeleton: The World’s Best List App
⸻
The Anatomy of a Good List
Five years ago, I made a list of every independent coffee shop in my city. It was nothing fancy — just a quick way to decide where to go on Saturday mornings. But people started sharing it. Friends passed it to friends. Strangers sent me suggestions to add. Before long, it had a life of its own.
That’s the thing about a good list: once it’s useful, it stops belonging only to you. Some lists fade after a single use. Others become part of how people think and decide.
⸻
Most software today is a patchwork. A customer complains to support. That request is passed to the product manager. The product manager writes a ticket. A developer implements it with whatever context made it through the game of telephone. The result isn’t a cohesive product. It’s a stack of reactions.
Protoflow rejects this cycle.
We aren’t building yet another productivity tool. We’re not selling infrastructure, or a new way to host your app, or a fancy wrapper around an LLM. We’re offering a way to think. A way to develop—in the full sense of the word.
Protoflow is an ideology about building software that feels whole.
Every new app begins the same way. You reach for a familiar scaffold: a Flask app, a Next.js starter, maybe a Spring Boot template. It’s muscle memory. You’ve done this before. Your mental model is primed—the stack, the setup, the steps. You scaffold the project, install dependencies, spin up the dev server. There's comfort in the ritual.
Early progress comes easy. You wire up the ORM, sketch your data models, add the first CRUD endpoints. The tests pass. The API returns exactly what it should. It feels like progress because it is progress. But it’s also the part of the project you’ve already solved in every previous app.
Then the real work begins.
You’re asked to implement a new feature—a more opinionated search, a billing integration, group permissions—and suddenly your momentum halts. Your elegant user model collides with the new requirements. The schema that once seemed minimal now feels rigid. Your CI pipeline complains about a version mismatch. That starter template you grabbed three weeks ago didn’t
The most successful CLIs follow a core principle:
Minimize surface area. Maximize momentum.
Protoflow’s purpose is simple but powerful: Help builders stay in flow while turning tasks into working, testable prototypes.
Let’s start from use cases, distill the mental model, and then define a minimal CLI that truly serves its purpose.
🔁 Distilled Workflow (Mental Model)
| func CreateTodo(req CreateTodoRequest) (CreateTodoResponse, error) { | |
| // Implementation would go here | |
| return CreateTodoResponse{}, nil | |
| } |
At Apple, ideas weren’t just encouraged—they were expected to become. In the early days, Steve Jobs didn't simply ask, “What can we build?” He asked, “What wants to exist?” It was less a question of invention, more a matter of listening carefully to the future.
The personal computer, the iPod, the iPhone—each one arrived as if on cue, just as the world was ready for them. Apple, and the culture Jobs built there, was uniquely positioned to notice the signal before it became obvious. They didn’t will these ideas into being. They caught them—like a wave cresting at just the right time.
This is the paradox of entrepreneurship: ideas that will make someone money are inevitable. The internet was always going to have marketplaces, search engines, video platforms. The only question was: who would build them, and when?
Many first-time founders overemphasize ideation. They try to sit down and think up something that will make money. But value isn’t conjured from a blank page. Money is a contract—an agreement between
| package main | |
| import ( | |
| "fmt" | |
| "io" | |
| "net/http" | |
| ) | |
| type Node struct { | |
| Name string |