ProveCalc — Project Story
What Inspired Me
I'm not a classically trained engineer. I'm a former heavy equipment operator from Graham County, Arizona — six years at Freeport-McMoRan's copper operations between the Safford and Morenci mines, starting as a Haul Truck Driver II in 2018 and finishing as a Rubber Tire Dozer Operator in 2024. Zero safety incidents across my entire tenure. Top 5 on the crew scorecard for two consecutive years. I trained new hires and wrote standardized procedures.
When I transitioned to engineering studies at Eastern Arizona College, I did it the hard way: Calculus I and II, Statics, Dynamics, Thermodynamics, and Mechanics of Materials — all in a single academic year while working. That earned me Engineering Student of the Year in April 2022. Not bad for someone who'd spent the previous six years hauling 235-metric-ton loads of copper ore.
When I needed calculation software, I used what I could afford: SMath Studio. It was free. It worked. I loved it — the XML-based document format, the plugin ecosystem, the way it treated worksheets as living documents rather than static spreadsheets. But SMath is Russian-developed software, and in the current environment, that's not a risk I or my colleagues could keep accepting. Organizations flagged it. The recommendation was to move on.
The alternative was Mathcad. $2,700 a year. As a student. A solo developer. Someone who works split shifts at a school cafeteria and DoorDash to keep the lights on while building tools because I need them, not because I have a VC check. That number is a joke.
So I built the in-between.
ProveCalc is the tool I needed when I couldn't afford the one that existed and couldn't trust the one that was free. It's priced the way it is because my overhead is three AI subscriptions — Claude, OpenAI, and Gemini — not a sales team, a licensing department, or a cloud server farm holding your data hostage. I can charge less because I am less overhead. That's the point.
Buy once. Own forever. No rent economy.
The five-year math speaks for itself: Mathcad costs $13,500. Maple Flow costs $12,475. Even Blockpad runs $2,400. ProveCalc is a one-time payment. Because when I was sitting in Professor Udalls' statics class at EAC, watching classmates struggle with tools they couldn't afford, I didn't think "here's a subscription opportunity." I thought "here's a problem I can solve permanently."
The Core Idea: Dimensional Analysis as Epistemology
Unit analysis isn't a feature. It's a truth condition.
I've written about this across my work — what I call "The Omega Protocol," the idea that civilization is the progressive elimination of latency between need and fulfillment. In engineering, that latency often lives in the gap between believing your math is right and proving it. Dimensional consistency is the cheapest, most powerful correctness guarantee you can build into any system. The Mars Climate Orbiter failed because of a unit mismatch between newton-seconds and pound-force-seconds. A deterministic system would have caught it in milliseconds.
$$\text{If } F = ma, \text{ then } [\text{N}] = [\text{kg}] \cdot [\text{m/s}^2]$$
This isn't optional. The engine enforces it. You cannot add meters to kilograms. You cannot assign a velocity to a force variable. Pint + SymPy don't negotiate — they either confirm the math or they don't. That binary is the whole product.
The AI layer sits on top of that certainty, not underneath it. The LLM proposes structure. It explains. It suggests. It never computes. Every claim it makes gets verified by the deterministic engine before it enters the worksheet. This is the core philosophy I apply to everything I build: the database is the intelligence, the agent is the hands. The AI is powerful because it's constrained — not despite it.
A Learning Tool First
Engineering students and interns inherit powerful tools before they're taught to think about what those tools are doing. I've seen someone run a spreadsheet calculation, get a number, and move on — without checking whether the units survived the journey. I tutored math, science, and engineering at EAC. I know what confusion looks like, and I know it usually starts when the tool hides the reasoning.
ProveCalc is built to be a teaching environment as much as a professional one. The 109-equation library isn't a convenience — it's a curriculum scaffold covering Statics (12 equations), Dynamics (15), Kinematics (10), Mechanics of Materials (18), Thermodynamics (12), Heat Transfer (10), Fluid Mechanics (15), and Electrical Engineering (12). Over 100 material constants for Steel, Aluminum, Concrete, Wood, Copper, and Titanium, plus gas and fluid properties at standard conditions.
A student working through beam deflection — δ_max = PL³/48EI — has the governing equation, the material constants (E = 200 GPa for structural steel), and the unit enforcement all in one place. They see the provenance badge on every value: 👤 User, 🤖 LLM (pending verification), ✓ Verified, or 📚 Library. They learn by building, not by being told. They see what gets enforced and why.
That's what I wanted when I was sitting in Spencer Udall's class at EAC, working through thermodynamics problems.
How I Built It
I'm a systems thinker. No formal CS background. My training is in heavy equipment, in solar sales. My experience and passion is in Systems and how we optimize them
What I brought to this project was a philosophy that scales: scope control is the most important aspect of software development led by LLM labor. I describe myself as "a telescope strapped to a brick mason" — I see decades ahead while building solid foundations. AI coding assistants are extraordinary — but they solve the problem you describe, not the problem you have. Every session with Claude Code (Opus 4.5, Claude 4.6) was an architectural negotiation: define the contract precisely, validate the output against the design, catch violations before they become debt. The scalpel, not the hammer.
That discipline is what made the three-layer architecture possible solo:
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ React Frontend │ ←→ │ Rust Backend │ ←→ │ Python Sidecar │
│ (Tauri Shell) │ │ Document Model │ │ SymPy + Pint │
│ KaTeX Render │ │ Verification │ │ Compute Engine │
│ Zustand State │ │ History/Undo │ │ Unit Analysis │
└─────────────────┘ └─────────────────┘ └─────────────────┘
Tauri 2.x wraps it native. React 19 with TypeScript 5 handles the interface. Zustand with Immer manages immutable state. KaTeX renders the LaTeX. Rust (Tokio, Axum) owns the document model and verification gates. Python 3.10+ with SymPy and Pint handles the actual symbolic computation and dimensional analysis. Structured logging across both layers — categories for API, Verification, Sidecar, Document, and Compute in Rust alone.
Keeping these three layers in consistent contract — while building alone, during a two-hour daily build window between my cafeteria shift and DoorDash — required treating every interface as a formal boundary. The document model is the single source of truth. Any layer that starts making assumptions about state it doesn't own breaks things in ways that are hard to trace. I learned this the hard way. It's also exactly what the "database is the intelligence" principle says at the architectural level.
Challenges
The hardest was the three-layer architecture itself. Rust, React, and Python each have their own opinions. Getting them to agree on a document model that all three respect — without letting any one layer bleed into another's responsibility — required constant discipline.
The deepest lesson I learned — and this shapes how I build everything now, including my MCP servers, my NLS compiler, and my Quest Keeper game engine — is that scope control is the most important aspect of software development led by LLM labor. An AI will confidently build exactly what you specified, even when what you specified is wrong. The developer's job becomes less about writing code and more about maintaining intent under constant pressure to expand. Every session needs a boundary. Every feature needs a contract. The scalpel, not the hammer. I call this principle "validate intent, control scope, persist state."
The other challenge was myself. I'm an INTJ-A who can see the whole architecture before writing a line. The temptation to plan forever is real. I have a specific blind spot here — I metabolize fear too quickly into plans without allowing proper processing time. The answer I imposed: ship what's proven, queue what's next. Phase 1 is done. Phase 2 earns its turn. I run every decision against what I call "The Tuesday Test" — five years from now, my son is in kindergarten, the bills are paid, the software is selling, the family is together. If a feature doesn't serve that Tuesday, it's a distraction.
What I Learned
That the most important constraint in any engineering tool is also the most important constraint in any AI tool: you must be able to show your work.
Dimensional analysis enforces this in physics. Scope control enforces this in software. An audit trail enforces this in professional practice. Natural Language Source — my intermediate representation language where "NLS is the source code and Python is just an artifact" — enforces this in how we talk to machines.
The mine taught me that. Six years of moving earth in 235-ton trucks, where a miscalculation doesn't throw an error message — it buries someone. The worksheet implements it.
I'm not a developer teaching coding. I'm a systems thinker teaching philosophy through building. ProveCalc is proof that the philosophy works.
Log in or sign up for Devpost to join the conversation.