Frank
Every recipe app I ever tried made me feel like I was doing it wrong. Not the cooking. The cooking was fine. The app.
Here’s the thing nobody tells you when you go looking for a recipe manager: most of them weren’t built by people who cook. They were built by people who thought cooking was a content problem. And so what you get is an app that’s great at displaying beautiful food photography, organizing recipes by season or “vibe,” and helping you build a collection you’ll never actually use. Gorgeous. Useless.
If I could go back five years and tell myself one thing before I spent time trying every recipe app with a decent star rating on the App Store, it would be this: the app you’re looking for doesn’t exist yet, and you’re going to build it yourself. Save yourself the audition process.
I tried a lot of them. Paprika was probably the best of the bunch, and I used it longer than I should have. But even Paprika had this fundamental assumption baked into its design, which is that your main problem is collecting recipes and not losing them. That’s not wrong exactly. But it’s the wrong priority. My actual problem was standing in a kitchen at six o’clock trying to figure out what I could make with what I had, at a scale that worked for the number of people eating that night. No app I found treated that as the central problem. They all treated it as a secondary feature, if they handled it at all.
The scaling thing alone should have been table stakes. It’s not exotic. It’s not some advanced power-user feature. If a recipe makes eight servings and there are two of us eating, I need to make a quarter of it. That math isn’t complicated. But getting most recipe apps to do it cleanly, without rounding errors that ruin ratios or having to manually do the conversion in my head anyway, was more trouble than it was worth. So I’d end up doing it in my head, which meant the app was just decoration.
Then there’s the import problem. Every recipe app in existence wants you to import from a URL. Great. Except about forty percent of the recipes I care about aren’t on a website. They’re in my head, or they’re from my mother-in-law, or they’re something I’ve made twenty times and modified into something that doesn’t resemble the original anymore. Those apps have no real answer for that. The manual entry forms are always clunky, the tag systems are always either too rigid or completely freeform with no structure, and you end up with a collection that’s half-organized at best.
I also got real tired of paying a subscription for something I could barely tolerate using. That’s not me being cheap, that’s me being a Gen-X IT guy who remembers when software cost money once and then you owned it. The SaaS model for recipe management specifically has always felt like a bad deal. You’re paying monthly to store data about food you already know how to make, on servers you don’t control, in an app that might pivot or shut down or change its pricing model the moment it gets acquired. No thanks.
So I built Cookslate. PHP and MySQL, hand-crafted from scratch with Claude Code doing a lot of the heavy lifting on the parts where my coding ability runs out, which happens faster than I’d like to admit. I am not a developer. I want to be clear about that. I’m a 28-year hardware and systems guy who has figured out enough code to build things that actually work for me, and Cookslate is one of those things.
The design philosophy was simple. Solve the problems the other apps ignored. That meant real scaling, where you type in how many servings you want and the ingredient list adjusts without you doing any math. It meant a tag and category system that’s structured enough to search but flexible enough to accommodate the way real people actually think about food. It meant manual entry that doesn’t feel like filling out a government form. And it meant running on infrastructure I own, so there’s no monthly bill and no corporate entity deciding what features I get this quarter.
What I didn’t anticipate was how much the act of building it changed the way I use it. When you build your own tool, you build it around your actual habits instead of trying to adapt your habits to fit someone else’s assumptions. Cookslate knows how I think about recipes because I’m the one who designed how it stores them. That sounds obvious, but it took me probably two years of frustration with other apps before I understood that the mismatch wasn’t my fault, it was by design. Those apps were built for a market. This one was built for a kitchen.
The curiosity that made me want to build it in the first place is the same thing that’s kept me tinkering with it since launch. I’ve added features I didn’t plan for because I ran into a problem while actually using the app to cook. That feedback loop doesn’t exist when you’re a subscriber. You file a feature request and wait. When you’re the developer and the user, you just fix the thing.
If you’re sitting on a similar frustration, where you’ve tried the market solutions and they all feel like they were built for someone adjacent to you but not quite you, that feeling is probably telling you something. Not necessarily that you should build your own version. But maybe that the gap between what’s available and what you actually need is wider than the people selling you subscriptions want you to believe.
Cookslate is live and open at cookslate.app. Freemium, open source, built by someone who actually cooks. If you use it and something’s broken or missing, tell me. I’m the whole dev team, but I’m also the guy who eats the food, so I’m already motivated.
