RepairCMS Form Builder

Every shop asks different questions at intake: the device, the fault, accessories, proof of warranty. Hard-coding those forms meant a release for every shop's change. And a public form on a shop's website is an open door: bots, fake bookings, oversized uploads, and anyone hoping to read another shop's data.

A teammate built the first editor and its drag and drop. I rebuilt the editor and built everything behind it: how forms are stored and published, how a submission becomes a ticket, pricing, insights and the security of the public endpoints. Much of the code was written by AI coding agents working to my architecture, and every change went through my review.

Each form is one MongoDB document owned by one shop: an ordered list of typed steps plus settings. One React runner renders every form type, on a shop's website, as an embed or on a tablet. A submission is checked against the live form, priced on the server and turned into a repair ticket in the shop's account.

Editor

Steps, fields and settings edited as a draft; customers see nothing until the owner publishes.

Form types

Website repair leads, warranty and returns, an in-shop tablet kiosk and a staff desk mode.

Price search

A small embed that lets visitors find a repair and its price, then book it.

Submissions

Each booking becomes a full repair ticket, with its uploads stored in the shop's own space.

Insights

Daily views and bookings per form, counted without storing personal data.

Test bookings

A preview booking creates a real ticket marked as a test, so owners see exactly what customers will produce.

The same pipeline also takes bookings from an external form service, so shops that already used one keep every booking in one place.

1. 01

   Forms as stored data, not code

   A form is a validated document, not a component. Its shape is checked on every create, save and publish, so a broken form can't reach customers, and a new question never needs a release.

   Trade-off Checks the compiler used to give for free now have to be written and tested by hand: more than 300 backend tests cover them.

2. 02

   Draft and publish on the same document

   Edits go into a draft stored on the form itself, and publishing makes it live. A separate drafts collection would need a second shop-scoped query and could fall out of step when a form is deleted. The editor also keeps the form's id in the URL, after a reload once let Save overwrite a different form.

   Trade-off One draft and one live version, not a full version history.

3. 03

   The server sets the price

   Prices are read again from the shop's own services and parts when a booking is submitted. Whatever the browser sends, a booking can't arrive at a price the shop never set.

   Trade-off Every submission costs extra database reads.

4. 04

   Treat a public form as an attack surface

   Public endpoints are rate limited per minute and capped per visitor per hour across every server, using a hashed IP that expires after an hour. Uploads are limited in number and size and checked by their real bytes, and public responses return only an allow-listed set of shop fields.

   Trade-off Several genuine customers on one shop's network share a cap, so the limits trade a little convenience for safety.

4

Form types from one builder

1

Runner for website, embed and tablet

300+

Automated backend tests

Live

With its first shops