AskForth — AI Form Builder SaaS

Every AskForth form is a single JSON document, {id, config, stages, rows, columns, fields}: a normalised graph in which pages, rows, columns and fields are keyed by id. That shape came from formeo, an MIT-licensed form builder, and it is the part we kept.

Why a hard fork

In July 2026 we looked for a builder to stand on. The free options either kept the builder behind a paywall, added a watermark or came with a copyleft server. formeo was MIT-licensed and active again, but run by one maintainer. Our research suggested vendoring it; we chose a hard fork instead, because the builder experience is part of what we sell and we wanted full control of it. Twelve days later we deleted formeo's own editor and renderer, a commit that removed about 21,500 lines, and replaced them with our own, which also removed a runtime fetch of assets from the upstream CDN. The MIT licence notice stays in the repository.

Four paths, one law

• AI-built: Forth turns a description into the JSON.
• Hand-built: drag-and-drop in our editor, which ships as a library mounted with mountEditor().
• Hybrid: build by hand, then ask Forth for changes; each batch is one undo step.
• Templates: the 33 system templates are stored JSON, built with the same kit.

What makes them interchangeable is a round-trip law: anything the builder can express re-opens in the builder and renders from the JSON alone. Machine edits go through one small set of operations in a shared ai-kit. The AI, the template seeder and a six-tool MCP server all call it, so there is a single code path for changing a form.

Drafts are saved as they are; publishing takes an immutable version snapshot, so a live form never changes under a respondent. The 68 field types, 10 themes and 7 font stacks live in one registry, which is why the public templates page can re-skin every form with a single theme dial.

Our first AI builder had the model write form operations itself. It handled simple forms and fell apart on structured ones: on a priced-menu test, 18 to 25 operations per run failed because totals pointed at price fields that did not exist. We redrew the pipeline, internally called Blueprint, around one principle: the model designs, code constructs.

The stages

1. Route. A short call classifies the message as build, edit or chat. Edits and chat apply operations directly, with up to two self-correction rounds.
2. Architect. The model turns the request into a typed FormPlan of sections, questions, kinds and prices. It never writes ids, references or formulas. Output that does not parse gets one stricter retry, and unknown field kinds are normalised against the registry.
3. Design. Deterministic rules add a theme, title, headings and layout and drop junk fields. If design gaps remain, the architect gets one corrective retry.
4. Assemble. Code builds the fields and writes every reference and total from the plan's own data, so a total cannot point at a missing field.
5. Cross-check and repair. A second model call compares the built form with the request and lists up to eight gaps, and a repair call fills them. The loop is capped at two rounds and never fails the build.
6. Finalise. Totals and the submit button go in last, so items added during repair are still counted.

The whole exchange has one 60-second deadline, runs at temperature 0 with JSON output, and caps user messages at 2,000 characters.

What the records show

On the priced-menu test, the same model went from 18–25 failed operations to zero. Across a 15-form benchmark (menus, bookings, quizzes, job applications, RSVPs and more), the pipeline built 15 of 15 forms cleanly on one model, and 14 of 15 on a cheaper one that used about 30% fewer tokens. Which provider runs it is a configuration setting, not a rebuild.

A form embedded on a customer's website runs under that website's security policy, and many sites forbid eval and new Function. Conditional logic and calculated fields are exactly where form engines reach for them, so we wrote our own evaluator.

A small expression parser

eval-expr.js is a hand-written recursive-descent parser of about 170 lines. It understands numbers, + - * /, brackets, comparisons and a fixed list of functions such as SUM, IF, ROUND and PCT. Field references like {Quantity} are replaced with numbers before the parser sees the string, so it only ever handles arithmetic. Division by zero, or anything it does not understand, returns null instead of throwing. A validator twin, expr-check.js, lets the editor and the AI reject a bad formula before it is saved.

The same parser on the server

The API imports the same renderer module. When a submission arrives, the server re-evaluates every show-if condition before enforcing required fields, so a hidden question cannot block a respondent and a visible required one cannot be skipped by editing the request. If an expression cannot be evaluated, the server treats the field as visible.

Hosted pages and the widget

Hosted form pages send their own policy: default-src 'none', scripts only with a per-request nonce, no unsafe-eval, and frame-ancestors built from the workspace's registered domains. Inline styles stay allowed on purpose, because the engine paints themes with them; CSS injection is contained by the engine's own value guards instead. The Google sign-in origin is added only on forms that require sign-in. The TypeScript embed widget renders each form inside a Shadow DOM and receives the form JSON only after the server matches the page's origin against the workspace's active domains.

A regression test throws nine XSS payloads at every control in the registry. The no-eval rule is enforced by how the code is built; we confirmed it by searching the built bundles, not with a committed test.

AskForth's billing reuses the engine we built for Storafleet, our storage SaaS, together with the lessons from auditing it.

Subscriptions only

AskForth never creates one-off Razorpay orders. Of its four tiers (Ask, Forth, Forte and Force), the paid self-serve plans are Razorpay Subscriptions, and an order record is written already paid when the subscription.charged event arrives. The webhook receiver:

• checks an HMAC-SHA256 signature over the raw request body with a constant-time comparison;
• drops events that belong to other apps on the shared Razorpay account;
• stores each event under a unique id, so a duplicate delivery does nothing;
• answers 200 before doing the work.

A replay job sweeps failed events every ten minutes, up to six attempts with doubling back-off.

The invoice series

GST invoice numbers have to run in an unbroken sequence. Each financial year (April to March, computed in UTC) has one counter document, and numbers such as INV/AF/FY26-27/00042 are reserved with a single atomic $inc. The order of operations matters: build the invoice, validate it, then reserve the number, then save. A validation failure cannot burn a number, and a unique index stops two invoices being issued for one Razorpay order. The guarantee rests on that write order and on unique indexes, not on a multi-document transaction. Storafleet taught us both rules: its first invoice of each financial year had been numbered 00000, and a failed enterprise invoice used to consume a number.

Tax and reconciliation

The tax branch follows the seller's registration and the buyer's location: no GST when the seller is not registered, a zero-rated export for foreign buyers, CGST plus SGST within the state and IGST across states. Before issuing, a guard refuses any invoice whose total differs from what Razorpay actually collected.

Industry packs keep a separate series for invoices a workspace raises to its own customers, such as a coaching centre's term fees, numbered in the workspace's time zone. Until launch, checkout answers 503 PAYMENTS_COMING_SOON unless real keys are configured and payments are switched on.

Forms are the input; the industry packs are what an organisation does with the answers. AskForth has 24 packs, from schools, clinics and coaching centres to housing societies, event planners, salons and insurance advisers. Inside each pack, roles called desks see the tools for their job: a clinic has a doctor, a nurse and a front desk; a school has management, teachers, office and accounts. The registry defines 70 desks in all.

Shared screens or full copies?

At first every industry reused the education screens in a different costume, with a "student" relabelled as a patient or a traveller. It was quick, and it leaked: in our own demo data, school students showed up on a travel agency's Travelers page, because both read the same collection.

In late July 2026 we chose full separation. Every industry with directory tools gets its own models, MongoDB collections, services, controllers and routes on the backend, and its own API layer, interfaces and pages on the front end, under its own URL subtree such as /clinic/patients or /travel/travelers. Today 22 of the 24 packs have their own stack; food and marketing do not need directory tools yet and get a folder the day they do.

We named the trade-off when we made the call. A fix that applies to every industry now costs one edit per industry, and adding an industry means scaffolding folders rather than adding a registry row. In return, each industry evolves on its own: a patient record can grow a medical history and a traveller can grow passport fields without touching each other, and a leak between industries is impossible by construction because they no longer share a collection.

What a pack adds

The clinic pack turns appointment requests into a patient-journey board (enquiry, visited, treated, follow-up) with one-click conversion to a patient record. The coaching pack raises term invoices per student and batch and records desk payments with numbered receipts. The events pack rolls RSVPs into live headcounts and per-question tallies.