I run a small project called CanineCalc that publishes free dog calculators and research-backed care guides — puppy weight and size estimators, calorie and feeding calculators, a crate size finder, and more.
Most of the tooling gets prototyped with a repeatable prompt workflow before I write production code. Here is the version I keep coming back to:
1. Spec first, code second
My opening prompt never asks for code. It asks the model to write a plain-English spec: inputs, outputs, edge cases, and the formulas the calculator needs. Reviewing that spec first catches most of the mistakes that would otherwise hide inside generated code.
2. Make the model state its assumptions
Pet care is full of rules of thumb that change by breed, age, and activity level. I prompt the model to list every assumption it bakes into a formula and to flag anything it is uncertain about. The flagged items become the parts I research and pin down myself, which keeps the final tool honest.
3. Generate the unhappy path
The most useful prompt in the sequence asks for edge cases: empty inputs, extreme values, mixed units. I keep that list next to the calculator and turn it into validation rules and test cases.
4. Iterate in the open
Once the calculator ships, real users find the inputs I never imagined. Each round of feedback becomes a new prompt: describe the confusing case, ask for the cleanest way to handle it, and update the tool. The loop is slow but it compounds.
One example of the result is a free dog calorie calculator — it estimates daily calories from a dog's weight and activity level, and every assumption it uses is spelled out on the page.
The takeaway: prompts are cheap and published tools are forever. Write the spec with the model, verify the assumptions yourself, and ship the calculator.
Top comments (0)