Case study · engineering software · August 2026

A verified motor-sizing application, built to a 36-page industrial specification in one week

A UK motion-control supplier published a detailed functional specification for a web application that sizes electric motors from real mechanical data — thirteen drive mechanisms, jerk-limited motion profiles, thermal duty, gearbox validation, and a hard rule that every number must show its working. We built a working, tested proof of concept against that document. This is a record of what was built, how it was verified, and why the same approach de-risks your project.

7 — drive mechanisms, incl. one position-dependent family

77 — automated regression checks, all passing

0.2% — agreement with the spec's own acceptance test

5 — integration bugs caught by testing before any user could

<300 ms — recalculation, entirely client-side

Note: Figures are from the build's verification suite and in-app acceptance runs, reproduced throughout this document.

The results dashboard: required speed, peak and RMS torque with safety factors shown separately, reflected inertia, warnings with stable codes, and a ranked motor shortlist. Branding was applied as part of the proof-of-concept exercise.

The brief

The specification — written by the client's own engineers — is unusually demanding for a web application. It asks for a deterministic calculation engine covering ball screws, belts, rack-and-pinion, chain drives, conveyors, rotary tables, cranks and more; trapezoidal, triangular and seven-segment S-curve motion; signed force models that handle overhauling vertical loads; gearbox reflection without double-counting inertia; and motor matching that must never extrapolate beyond published torque-speed data. Section 21 requires unit tests for every formula and independent verification of a worked example to within 0.2%.

In other words: not a form with a lookup table, but numerical engineering software with an audit trail. That framing drove every decision below.

Architecture: the maths is untouchable

The core risk in AI-assisted or rapid app development is that calculation logic gets smeared through UI code, where the next cosmetic change can silently corrupt it. We eliminated that risk structurally: every formula lives in a single protected engine file, written and tested outside the app builder, and pasted in whole. The UI layer is forbidden — by standing instruction and by review — from containing any sizing arithmetic.

Box 1 — calculations.ts — the engine: Pure, versioned functions. SI units only. Every formula carries the spec's identifier (SCR-01, GEA-02…) and returns a full substitution trace. Never edited by the app builder.

Box 2 — Thin adapter: Converts entry units (mm, rpm, %) to SI at the boundary; applies the two safety factors, defined once; passes results through untouched.

Box 3 — Interface: Wizard, charts, sharing, enquiries. Free to change daily without any risk to the numbers.

Every result in the app carries a version line — engine v0.7 · catalogue v0.1 — so any report can be traced to the exact logic and product data that produced it. That is the spec's traceability requirement (§20), present from day one rather than retrofitted.

Trust: tested against the client's own numbers

The specification includes a hand-worked ball-screw example with expected intermediate values. We turned it into an executable test before writing any interface, then grew the suite with a hand-derived example for every mechanism added — 77 checks in total, re-run on every engine change. The screw example agrees to within 0.02%, fifty times tighter than the required tolerance.

The specification's own acceptance test, reproduced end-to-end through the live interface: 0.287 N·m design torque at 3,000 rpm, with the deceleration segment correctly negative and flagged as regenerative. (Tag: verified vs. spec §18)

This discipline paid for itself immediately. During the build, five integration bugs — a unit conversion off by 1,000×, a form silently substituting a default efficiency, a wrong safety factor quietly excluding borderline motors from a recommendation table — were each caught the same hour they appeared, because every screen was checked against a pre-computed expected answer. Every one of them produced a plausible-looking screen. Without anchored numbers, all five would have shipped.

Trust also means honesty in the interface itself. Torque that goes negative is never clamped to zero — it is preserved and flagged, because it means the load can drive the motor. Missing inputs produce disclosed, incomplete answers with a warning, never silent guesses. And when nothing in the catalogue can do the job, the app says so:

A 17 N·m duty that no catalogued motor meets. The application recommends nothing and says why — the specification's rule that commercial pressure must never make a failing product look suitable.

Capability: real mechanics, not lookup tables

Seven of the specification's twelve release-one mechanisms are implemented and verified: ball/lead screw, belt and pulley, rack-and-pinion (entered by pitch diameter or module and tooth count), chain and sprocket, conveyor with breakaway starting loads, direct rotary, and crank-slider / Scotch-yoke — the first of the spec's position-dependent family, where torque varies continuously with mechanism angle.

An inclined conveyor with a 200 N breakaway force: starting torque (38.8 N·m) exceeds the running cycle and governs the peak — shown as its own result, included in peak sizing but correctly excluded from thermal RMS, with the reasoning stated on screen.

Scotch-yoke drive at constant speed: the engine samples the full revolution and produces the textbook sin 2θ torque wave, with regenerative half-cycles shaded. This case has an exact closed-form answer — the sampled peak matches it to four decimal places. (Tag: closed-form check)

The same machine with a real 200 mm connecting rod: the wave turns asymmetric and the peak rises 26%, with the worst-case angle reported (36.5°). Rod angularity is exactly the effect hand calculations tend to miss.

Motion is equally complete: trapezoidal, triangular, and full seven-segment jerk-limited S-curve profiles, with segments collapsing automatically when a move is too short to reach its limits — and the collapse disclosed, never smoothed over.

A jerk-limited move plotted from the engine's samples: speed and torque against time with the regenerative region shaded, plus position and velocity. The S-shaped corners are the point — smooth motion that spares the machine.

The acceleration trace shows the seven-segment signature: jerk-ramped edges and flat tops at exactly the requested ±2 m/s². Engineers verify a profile by this shape, so the application draws it rather than asserting it.

Decision support, not just answers

Sizing is a negotiation between speed, torque and inertia, and the gearbox ratio is the lever. The ratio adviser evaluates thirteen standard ratios — each one a complete, independent recalculation, a property enforced by an automated equality test — and shows how the candidate motor list changes. One click adopts a ratio.

The ratio adviser on a heavy chain axis: direct drive suits nothing; candidates climb as the ratio rises; the first clean pass appears at 7:1. Each row states its motor speed, design torque and reflected inertia. (Tag: every row recalculated)

Inside a motor row: the manufacturer's published torque-speed curve with the application's operating points plotted on it. The dot sitting just beneath the curve is an 11.2% margin, drawn. Lines stop where the published data stops — the engine never extrapolates.

Sharing, privacy and security

Calculations travel as links, never as screenshots

Every result has a copyable URL that encodes the inputs only — never the results. Opening a link recomputes everything through the current engine, so a shared calculation can never show stale numbers, and a colleague receives a live, auditable, editable calculation rather than a picture of one. Tampered or malformed links fail to a clear message and a fresh start, never a half-broken form.

Nothing is stored unless the user acts

The application keeps no accounts and writes no personal data. The enquiry feature composes a structured message — contact details, the calculation summary, active warnings, the share link, the engine version — only when the user submits it, behind an explicit consent checkbox. This mirrors the specification's privacy posture (collect personal data only on request, with consent) and means there is simply no stored dataset to breach.

Defence in depth on inputs

All inputs are validated at entry (positive-only geometry, efficiency bounded 0–1, rod longer than crank); the engine independently re-validates and throws on impossible physics; and the S-curve generator self-checks its own kinematic closure and refuses to return an inconsistent profile. Unit conversion happens once, at the form boundary, through a single shared path — the class of bug that produces confident wrong answers is designed out rather than tested out.

Speed and scalability

The entire engine runs client-side: recalculation is effectively instant (the specification asks for 300 ms; typical runs are far under it), works on any device, and puts zero calculation load on a server — a thousand simultaneous engineers cost the same to serve as one. Sampled mechanisms compute hundreds of points per cycle without perceptible delay.

Scalability here is less about traffic than about growth of scope, and the architecture is built for it. The engine grew from three mechanisms to seven across six versions with the full test suite passing unchanged at every step — the strongest evidence that the remaining mechanisms, the real product catalogue, PDF reports and CRM integration bolt on without rework. The catalogue is a data file in a defined shape, so the demonstration data (deliberately marked EX-, with plausible engineering values) swaps for approved manufacturer data without touching a line of logic. The engine is a dependency-free library callable from any front end, a server API, or a batch process — exactly the separation the specification's §20 requires.

Honest boundaries

Every results page and printed summary carries the engineering boundary in the client's own specification language: results support preliminary motor selection and do not replace a competent engineer, detailed machine design or safety assessment. The demonstration catalogue is labelled as example data throughout. Five of the specification's mechanisms (winding rolls, cam drives, indexers among them), its advanced validation modules, accounts and CRM integration remain as scoped, costed phase-two work — the proof of concept exists to demonstrate that the architecture and testing discipline they will be built on already works.

What this says about working with us

We read the specification. The formula identifiers, the warning wording, the safety-factor presentation and the privacy posture in the app come directly from the client's document — including requirements usually deferred, like jerk-limited motion.

We prove correctness, not plausibility. Every number in this document traces to a hand-worked calculation, a closed-form identity, or the specification's own acceptance test — and the same suite guards every future change.

We build so speed is safe. The protected-engine architecture is what let this be built in days without gambling on the maths: the fast-moving interface and the slow-moving, verified engine never share a file.

We tell you when the answer is no. An application that refuses to recommend an unsuitable product — and a supplier that flags its own boundaries — is the one whose recommendations mean something.

If your project involves calculation, configuration, or recommendation logic that has to be right — engineering, pricing, compliance, quotation — this is the working method we would bring to it. We are happy to walk through the live application, the test suite, and the specification side by side.

Proof of concept built against the Mclennan Servo Supplies "Motor Sizing & Selection App" functional specification v1.6 (August 2026). All screenshots are from the live application; motor data shown is illustrative example data. Engine v0.7 · example catalogue v0.1 · verification suite: 77 checks, passing.