Inspiration
Every hardware project starts the same way: a schematic, a parts list, ordering PCBs, buying sensors — and the quiet confidence that you know what you need. Mine kept proving that confidence wrong. I'd order a premium part for a role a basic one could fill, or keep something on the list simply because cutting it felt risky, not because I'd actually checked. I'd ask an AI to generate the parts list in the first place, and it would hand one back without ever asking whether the list itself made sense.
Nobody was auditing the audit. So I built the thing that would.
What it does
- Generate your list. Copy the provided prompt and paste it into whichever AI you already use for your hardware/electronics project.
- Bring it to BudgetForge. Paste the output — each item, why you need it, and roughly what it costs.
- Get a real audit, on two independent axes at once:
- Do you need this at all — critical, important, nice-to-have, or redundant.
- Are you overpaying for it — a part can be completely necessary and still be the wrong purchase.
- Flagged items get an honest alternative — pro and con stated plainly, never a bare "cheaper option."
- Overlapping parts get a tradeoff, not a silent cut. When two items are quietly doing the same job, BudgetForge hands you the choice instead of deciding for you.
How we built it
- Next.js on Vercel, with Groq underneath for speed that keeps the tool feeling alive instead of making you wait on a spinner.
- The rubric was earned, not assumed. The four buckets, the price-tier logic, the redundancy handling — all tested against my own real hardware projects by hand, until it stopped getting things wrong.
- No arithmetic left to the model. Every dollar total, every savings figure, every flagged boolean is computed in deterministic code, never asked of the LLM — because a tool that gives a different answer to the same question twice isn't a tool anyone can trust.
- Optional live grounding. Flagged alternatives can be backed by a real web search via Groq's Compound model, with a hard timeout so a slow lookup never breaks the result it was supposed to improve.
- Claude Code carried the implementation. Prelint reviewed every pull request against a written spec, so the product's decisions stayed decisions — documented, not just remembered.
Challenges we ran into
- The rubric survived exactly as long as it took to meet real data. My own parts list broke it twice in one pass: a genuinely redundant display slipped through because it was cheap, and a genuinely critical soldering iron went unflagged because the logic assumed "necessary" and "overpriced" couldn't both be true of the same item. They can. Treating necessity and cost as two independent questions — not one — was the single most important architectural decision in the whole build.
- Non-determinism was a harder, quieter problem. The same input could produce a different verdict on a borderline item between two identical runs. Lowering temperature helped. Removing every piece of math from the model's hands helped more.
- A silent production bug, on the day I thought I was done. The live "Analyze" button did nothing — zero errors, despite working perfectly on every local test. The cause was invisible until I compared a real click against an automated one side by side: a hydration-timing gap between the page painting and React actually attaching its handlers. The kind of bug that hides until the exact moment someone who isn't you tries to use it.
Accomplishments that we're proud of
- Teaching the tool to separate should I own this from am I paying too much for it — a distinction that's easy to get wrong and expensive to get right.
- Teaching it to leave intentional redundancy alone — like independent safety mechanisms — instead of flagging every duplicate as waste.
- Catching a production bug invisible in every local test, before a stranger's first click could have been the one that found it instead.
What we learned
Watching your own overspending get named, line by line, is a strange kind of satisfying. There's something clarifying about a tool that won't let you rationalize a bad purchase just because you already convinced yourself it was fine — it turns out that's most of what "saving money" actually requires: someone, or something, willing to say so plainly.
What's next for BudgetForge
- Goal-1 -> More training for the Web app with more test cases and increasing the quality of the rubric, increasing overall accuracy
- Goal-2 -> Change the model from Groq to Grok (Owned by xAI), best for keeping up with new products and the market, or Claude for better reasoning
- Goal-3 -> Adding more features to the web app; for example BudgetForge could be a connector for models like Claude/Chatgpt so everything works in background without going to the actual website
- Goal-4 -> Expand to other Hobbyist domains
Log in or sign up for Devpost to join the conversation.