Productivity · App Starter
Build forms, collect responses, chart the results — a complete forms platform generated into code you own.
Every team eventually hits the form tool's ceiling: response caps, per-user pricing for viewers, data living in someone else's export queue. This starter generates the whole apparatus — builder, public fill pages, response analytics — as your own application, where a form is a row and responses are just data in your database.
01 · Data model
Forms look simple until you model them honestly: questions change after responses exist, answers need to stay queryable, and respondents recur across forms. Six tables handle the whole lifecycle without painting you into a corner.
| table | what it holds |
|---|---|
forms | Each form with its title, settings, status, and publish state — the container everything else hangs from. |
form_versions | Immutable snapshots of a form's structure at publish time, so responses always reference the questions as they were asked. |
questions | Typed fields — text, choice, scale, date, file — with ordering, validation rules, and conditional display logic. |
responses | One submission per row, stamped with time, source, and completion status, linked to the exact form version answered. |
answer_items | Individual answers within a response, stored per question — the normalized layer that makes charts and filters possible. |
respondents | Known or anonymous submitters, linkable across forms — so the person who answered three surveys is one record, not three strangers. |
02 · Screens
Compose forms from typed questions with validation, required flags, and show-if logic, then publish when ready. Publishing cuts a version snapshot, so editing a live form never quietly corrupts the meaning of responses already collected.
Each published form gets a clean public page under your domain — no third-party branding, no response caps, mobile-friendly by default. Partial progress can persist, and completion redirects wherever your process goes next.
Choice questions chart themselves, scales show distributions, and text answers list with search and filters. Because answers are normalized rows, any question you can ask of the data is a query — not a premium analytics add-on.
Responses export to CSV per form and version, or skip the export entirely: your other systems can read the tables directly. The data was never trapped, so 'integration' is mostly just access.
03 · Process
Contact forms, applications, internal requests, surveys — describe what you collect and from whom. The starter generates the builder plus your first forms in the same pass.
Add a question type you need, tighten validation, put a form behind a login, or route submissions to email — conversational changes that arrive as readable code.
Deploy with approval gates and an audit trail on your infrastructure. Every response lands in your database from the first submission — nothing to migrate later.
04 · Fit
The free tier ends at exactly the response volume where the tool became useful, and unlocking your own data costs a monthly fee per seat. Generating your own forms platform ends that cycle: unlimited forms, unlimited responses, and the bill is your hosting.
When submissions carry personal or regulated data, 'where does this form tool store responses?' is a compliance question with an unsatisfying answer. Here it's your database, your region, your retention policy — the form is inside your boundary from the start.
Intake flows, onboarding questionnaires, and request forms often need to live inside an existing product, sharing its users and design. A forms engine you own embeds natively — same auth, same styling, same database — instead of iframing a stranger into your UI.
A form is rarely the point; the workflow after it is. When responses are rows you own, 'new submission opens a ticket' or 'approved request updates the register' is a small piece of code away — no automation platform subscription bridging two tools that refuse to talk.
05 · Yours
Start with the question types and rules your work needs: add a signature capture type, a file-upload limit, address autocomplete, or scoring logic that grades a quiz on submission. Show-if conditions, multi-page layouts, and progress saving are all behaviors defined in your code — extend them in Vibe mode by describing what you want.
Then make forms a capability instead of a product: require login for internal forms, prefill known respondent data, trigger notifications or downstream records on submission, or expose an endpoint so other systems create responses programmatically. The generated app is a normal full-stack codebase with no runtime dependency on Dual7 — a forms engine, permanently yours.
Form SaaS inverts the natural ownership of data: people hand you their answers, and a vendor holds them, meters them, and charges you for access tiers and seats. This starter restores the obvious arrangement — submissions go straight into your database, the builder is your admin screen, and the public pages run under your domain. Response caps and per-viewer pricing stop being concepts.
Owning it means operating it, and the governed pipeline keeps that disciplined: changes ship through approval gates with an audit trail, and version snapshots protect response integrity even as forms evolve. For a system whose job is collecting other people's information, that control is worth having.
06 · Industries
Pre-visit packets, consents, and insurance capture — patient intake that runs inside your practice's own boundary.
Enrollment windows, guardian consents, and application review — registration forms built for how schools actually admit.
Donor feedback and program outcome surveys on your own platform — evidence for funders, collected without per-response fees.
Six connected entities — forms, form_versions, questions, responses, answer_items, respondents — plus a builder admin with validation and conditional logic, public fill pages, response charts, and export. All generated as full-stack source code you own.
Because editing a live form silently changes what old answers mean. Publishing cuts an immutable snapshot, and each response links to the version it answered — so analysis across a reworded question stays honest instead of quietly wrong.
Yes — questions carry show-if conditions based on earlier answers, and validation rules per type. Because the logic is code rather than a settings tree, arbitrarily specific branching is possible when your use case demands it.
None imposed — it's your application and database, so limits are whatever your infrastructure handles, which for form workloads is a very large number on very modest hardware. Volume stops being a pricing lever entirely.
Respondents are a first-class entity, so authenticated or identified submitters link across every form they've answered. For anonymous surveys, skip the linkage — both modes are supported, and the choice is your policy to make.
That's a natural use: public fill pages run under your domain with your styling, and embedding a form in an existing page of your app is straightforward since it's all one codebase. No iframes, no external branding, no data leaving your stack.
Dual7 App Starters
Build forms, collect responses, chart the results — a complete forms platform generated into code you own. Describe your version to start — the output is a project you own.