The Short Version

The second free, local-first cooking utility: you enter the protein, weight, and target dinner time, and it outputs the entire backward schedule — preheat, in, out, rest, serve. The honest part of this post is why modeling cooking time accurately is four separate engineering problems, not one multiplication.

The Second Tool in the Kit

A few weeks ago I shipped the Universal Recipe Scaler — a free web utility that scales ingredient amounts and converts units instantly. No signup, no email, no data collection, runs entirely in the browser.

The Reverse Roasting Timeline Calculator is the second tool. Same philosophy, different problem.

The recipe scaler handles the ingredient math. If a recipe is for four servings and you're cooking for two, it scales the amounts and converts the units. That's the easy half of a holiday dinner. The hard half — the one that actually causes the stress on Thanksgiving morning — is the timing math.

If guests are eating at 6:00 PM and the turkey takes 15 minutes per pound plus a 30-minute rest, when do I turn the oven on? If the prime rib is the centerpiece but the salmon needs to finish at the same time, what's my actual schedule? If I'm running the oven at 325°F for the bird and 425°F for the roast vegetables, when do I switch and when do I preheat?

This is the math that home cooks get wrong, and it's the reason holiday meals end up served forty-five minutes late or — worse — with one dish cold and another still raw in the middle. The calculator answers it. You input the protein, the weight, and the target dinner time. It outputs the entire backward schedule: when to preheat, when to put it in, when to take it out, when to start the rest. Copy the result to your phone, hand it to your spouse, follow it.

That's the whole tool. It's free. It's local-first. It has no account system, no analytics tracking you, no ads. It will stay that way.

Why I Built It

The premise behind both tools is the same: home cooks shouldn't have to do mental math under pressure when a free web utility can do it for them in zero seconds.

Recipe blogs and cooking sites generally don't help with timing. They tell you a turkey takes "15 minutes per pound." They don't tell you that fifteen-minute-per-pound figure assumes a specific oven temperature, assumes the turkey is fully thawed, doesn't account for the rest period, and is wrong for the smaller turkeys that most home cooks actually buy these days. They especially don't help when you're trying to land three dishes simultaneously on a single oven.

The calculator handles all of that. It knows that a turkey at 325°F needs about 13-15 minutes per pound. It knows that prime rib at 325°F needs about 17-20 minutes per pound for medium-rare. It knows that a leg of lamb needs different time-per-pound than a pork shoulder, that pork ribs don't scale by weight at all, and that a side of salmon needs five minutes of rest while a whole turkey needs thirty.

You don't need to know any of that. You pick the protein. You enter the weight. You enter the dinner time. The tool does the rest.

Why Cooking Math Is Harder Than It Looks

This is the part of the post I actually wanted to write, because building the calculator turned out to be a more interesting engineering puzzle than I expected when I started.

Cooking math is not linear. It looks linear — minutes per pound sounds like a simple multiplication — but the moment you try to model it accurately, you run into four different problems that have to be handled separately.

Problem 1: Weight-scaled cooking versus fixed-time cooking. Most roasts scale with weight. A bigger prime rib takes proportionally longer than a smaller one. But pork ribs don't work that way. A rack of ribs takes roughly five hours regardless of whether it's a small rack or a large one, because the cook is about breaking down connective tissue at low and slow temperature, not about reaching an internal temperature through a mass of meat. Brisket has similar quirks. Most "minutes per pound" calculators on the internet apply the same multiplication to everything, which produces hilariously wrong answers for the cuts that don't scale.

The calculator handles this by branching at the protein-selection step. When you pick a weight-scaled protein (turkey, prime rib, chicken, pork loin, etc.), the weight input is active and the math is minutes-per-pound × weight. When you pick a fixed-time protein (ribs, brisket), the weight input dynamically disables itself and the algorithm shifts to a fixed total cook time. This is a small UX detail that prevents the user from accidentally generating a wildly wrong schedule.

Problem 2: Temperature matters as much as time. A turkey takes 15 minutes per pound at 325°F. At 350°F it cooks faster. At 300°F (the low-and-slow method some cooks prefer) it cooks dramatically slower. You can't give someone a timing answer without also telling them what temperature the oven needs to be.

The calculator's data dictionary attaches the target oven temperature to every protein entry and outputs that temperature on the "preheat" step of the timeline. So the schedule doesn't just say "turn the oven on at 1:15 PM" — it says "preheat oven to 325°F at 1:15 PM." Both Fahrenheit and Celsius, because someone outside the US is going to use this eventually and converting temperatures isn't on the user's job.

Problem 3: Rest times are protein-dependent. Every roast needs to rest after it comes out of the oven. Resting allows the muscle fibers to relax and the juices to redistribute, which is why a steak that's been rested for ten minutes is juicier than one sliced immediately. But the right rest time isn't fixed. A whole turkey needs about thirty minutes to fully rest because there's so much mass holding heat. A side of salmon needs about five minutes — any longer and it goes from "perfectly rested" to "cold." A standing rib roast needs fifteen to twenty.

The calculator factors rest time as a distinct step in the timeline, with the duration set per-protein based on its density and mass. The rest period gets its own line item on the schedule, which matters because most home cooks treat resting as optional or as something to "do quickly" — they pull the bird out, carve it immediately, and lose the juices. Having the rest step on the official schedule makes it harder to skip.

Problem 4: The math has to work backward, not forward. Most cooking calculators online work forward: I'm starting at 2:00 PM, when will it be done? That's the wrong direction. Home cooks don't choose their start time; they choose their dinner time, and they need to know when to start.

This sounds like a trivial flip — just subtract the cook time from the dinner time — but in practice the timeline includes multiple steps that all need to fit together correctly. Preheat the oven (10-15 minutes, depending on the temperature). Insert the protein. Cook for the scaled or fixed time. Remove from oven. Rest for the protein-specific rest duration. Serve.

If the user says "we eat at 6:00 PM," the calculator has to subtract the rest time first to get the take-out-of-oven time. Then subtract the cook time to get the put-in-oven time. Then subtract the preheat time to get the turn-the-oven-on time. Three sequential subtractions with three different durations that depend on the protein and weight, all happening in the user's head every Thanksgiving morning, all now handled in zero seconds by the calculator.

The Disclaimer That Has to Be There

There's one thing the calculator can't do, and the UI is honest about it: the math is an estimate.

Ovens vary. Meat varies. A turkey that's not fully thawed will take longer. A roast that came out of the fridge cold will take longer than one that sat on the counter for thirty minutes. The "15 minutes per pound at 325°F" is an averaged guideline that works for most home cooks most of the time — but it's not a guarantee.

The only real measure of doneness is a calibrated digital thermometer reading the internal temperature of the protein. The calculator says this directly in a small disclaimer block. The schedule tells you approximately when to do things. The thermometer tells you when the food is actually done. Both matter.

This is the same principle as the rice post earlier — measurements and tools are starting points, not endpoints. The schedule gets you close. The thermometer verifies.

The Sidebar and the Ecosystem

If you open the calculator, you'll notice a small sidebar linking to the rest of my work — the recipe scaler, the main website, the Tynkr Tools shop, and a few of the cooking posts on this blog. That's deliberate. The free utilities are positioned as a top-of-funnel entry point to the broader catalog. Someone finds the calculator on Google when they search "when to start cooking a turkey for 6pm dinner." They use the tool. They notice there's a sidebar. They click through and find out the person who built the calculator also makes Notion templates, premium spreadsheets, and a bunch of other free stuff.

This is the same pattern the recipe scaler uses. The free tool is genuinely free and useful on its own. The sidebar is the bridge to the rest of the work, for the people who care to look.

What It Looks Like to Actually Use

The flow is short:

  1. Open the calculator.
  2. Pick a protein from the dropdown (turkey, prime rib, leg of lamb, ribs, salmon, etc.).
  3. Enter the weight in pounds (the field is disabled if you picked a fixed-time protein like ribs).
  4. Enter the target dinner time.
  5. Click the button.

You get a chronological schedule that looks something like:

Preheat oven to 325°F (165°C): 1:15 PM
Put turkey in oven: 1:30 PM
Take turkey out of oven: 5:30 PM
Rest (covered, 30 minutes): 5:30 PM – 6:00 PM
Serve: 6:00 PM

There's a one-click "Copy to Clipboard" button so you can text the schedule to whoever is helping you, or paste it into your phone's notes app for the morning of. That's the entire experience. Open, input, output, copy, close.

What's Next

The recipe scaler and the timeline calculator are the first two utilities in what's going to be a small but growing set. The premise is the same across all of them: free, local-first, no signup, no data collection, hosted as static pages on GitHub Pages with formal WebApplication schema identifying Built by Josh Studio LLC as the publisher. Each one solves a specific cooking-adjacent problem that home cooks shouldn't have to think about.

If you're hosting a Sunday roast, a Thanksgiving dinner, or any meal where multiple things have to land on the table at the same time, bookmark the calculator. It'll be there when you need it. And like everything else under the Tynkr Tools umbrella: it will stay free, it will stay ad-free, and it will stay accessible to anyone who wants it.

Try the Tool

Open the Reverse Roasting Timeline Calculator.

Free, instant, no signup. Pick the protein, enter the weight and your dinner time, get the whole backward schedule.

Open the Calculator →
About the Author

Josh is the founder of Built By Josh Studio and Tynkr Tools & Co — a one-person creative operation based in Kansas building Notion templates, spreadsheets, zodiac digital art, and the occasional vanilla-JS side project. He's also the author of Overlayed Echoes.

Learn more →