How We Replaced Typeform With a Single Prompt

Technical teams with an engineer and a simple form are overpaying for Typeform — and it has never been easier to replace Typeform with a custom form generated by AI. Typeform's Basic plan costs $29 a month and caps responses at 100, a ceiling a busy application form can hit in weeks, forcing an upgrade to $59 or $99 under pressure. But the monthly fee is the small part. The structural costs are what accumulate: applicant data locked in a third-party silo, an iframe you don't control, and re-syncing integration glue every time a question changes.

This article covers what one prompt session in Claude Code actually produced for Poolside — our own membership application at poolside.co/apply, a ten-field form writing directly to Neon Postgres, with an email notification on every submission, live in under an hour — and why that outcome changes the math for any team that already owns a repo and a database.

It also covers where Typeform remains the right call: non-technical teams, branching logic, and forms that need no-deploy editing. The substitution argument is narrow but precise, and our own form makes the boundary concrete.

What Typeform costs before you collect a single response

Typeform's Basic plan costs $29 a month and caps responses at 100. A membership or waitlist form running for three months lands you somewhere between $90 and $180 before you collect enough responses to matter, and that figure assumes you never breach the cap.

The cap is the mechanism worth understanding. It is not a usage limit in the background that rarely triggers. For a launch with any momentum, 100 responses is a realistic ceiling to hit inside the first few weeks. Once you cross it, Typeform stops accepting submissions until you upgrade. The choice at that point is not whether to pay more but when. You are mid-campaign, your form is live, and the upgrade path is to Plus at $59 a month or Business at $99.

That structure converts what looks like a cheap monthly tool into a tiered commitment you make under pressure. Basic is not really a working tier for a form with any momentum. It is a trial with a hard wall.

The three tiers sit at $29, $59, and $99. The gaps between them are large enough that a modest form can force a jump of $30 to $70 a month at exactly the moment you have the least information about how long the campaign will run or how many responses you will eventually collect. A team that budgets $87 for a three-month Basic subscription and then hits 100 responses in month one is now looking at $177 for the same period on Plus, or $297 on Business. None of those numbers are catastrophic, but none of them were the number you planned for.

The monetary cost is the small part. The response cap is what makes the pricing structure a recurring decision rather than a one-time purchase. Every month you run the form, you are re-evaluating whether the tier you are on will hold. That is a different kind of cost than paying for hosting you already have.

How to replace Typeform with a custom form in under an hour

Poolside's membership application used to run on a hosted form tool — Tally, in our case, the same category as Typeform. One prompt session in Claude Code replaced it. The prompt described the outcome: an application form for a closed community, with name, email, website, three long-form questions about what the applicant is building, a space-preference selector, two optional fields and two consent checkboxes — one row per applicant in Postgres, and an email in our inbox on each submission, with reply-to set to the applicant.

Claude Code generated all of it: the React form with validation, the Zod schema, the server action, the database write and the notification. The whole exercise took under an hour, including reviewing the diff and a live end-to-end test.

The form lives in our own repo and writes to a Neon Postgres table. It deploys with the site, meaning there is no separate form service to coordinate, no iframe pulling in third-party branding, and no integration layer to keep in sync. Each submission triggers an email through Resend; the destination is a NOTIFICATION_EMAIL environment variable, so pointing it somewhere else — a shared inbox, a Slack email gateway, anything — is a one-line config change. The cost beyond that is zero, because the hosting was already paid for.

The schema decisions are captured in code rather than a dashboard. The same Zod schema validates in the browser and again in the server action, so the rules — minimum answer lengths, a real URL for the website field, required consents — live in one file, visible in the repo, and changeable with a normal pull request. In the first week we changed question copy, raised the minimum answer length, and added live character counters and validate-on-blur. Each change was an ordinary commit deployed in the same push as everything else.

The pre-AI equivalent of replacing Typeform with a custom form was one to two developer days of work. The generated version took under an hour including review. That gap is the substitution argument in concrete terms. It is not a question of dollars versus dollars, where you weigh a $29 monthly plan against engineering time. The comparison is hours versus days, and the hours include reading the output carefully before merging it.

Why data silos cost more than the monthly fee

The money is the small part. The real costs are structural — and the structural costs are what most SaaS comparisons avoid, because the monthly fee is easy to calculate and the structural costs are not.

What structural means here is concrete. Applicant data living in a form tool's silo means every answer ends up in a CSV export. Someone downloads it, re-imports it somewhere useful, and that process repeats every time the team wants to query its own applicants. The data is not inaccessible, but it is never where analysis actually happens. The team owns the question, not the answer.

The embedding problem compounds this. An iframe is a dependency that sits outside the team's deployment pipeline entirely. The form renders with someone else's branding on your page, and any integration glue built to connect it to downstream systems is a separate surface that must be maintained independently of the product it serves. When we changed a question in our application form, the fix was a small diff deployed in the same push as everything else. That is what it looks like when the form is a file in the repo rather than a third-party service with its own release cycle.

The re-syncing burden is the part that accumulates invisibly. A team adds a qualifying question to understand their applicants better. Now the CSV schema has changed, the Zapier zap needs updating, and whoever built the import script has to be found. None of these tasks are hard, but each one is a recurring cost that compounds over the life of the form. The $29 monthly fee on Typeform's Basic plan is a fixed line item. The sync overhead is not.

The maintenance argument usually runs in SaaS's favor: let the vendor handle uptime, updates, and fixes so your team does not have to. That framing is accurate for complex products. It is not accurate for a static form. The honest answer is that a form with one insert query has almost nothing to break. Our application form has survived every deploy since it launched without requiring changes. There is no dependency graph to audit, no vendor changelog to monitor, no integration to re-authenticate when an API token expires. The surface area for failure is genuinely small because the implementation is genuinely simple.

This inverts the standard ops-burden argument. The SaaS tool introduces fragile dependencies in exchange for removing the build cost. When the build cost drops to one prompt session, the trade is no longer favorable. The team pays the monthly fee and absorbs the structural costs without getting the main benefit that justified both.

The data ownership point is not abstract. For a membership application, the answers tell us who is applying, what they are building, and whether they fit the community. That analysis happens in our own database, against our own schema, with whatever query we want to run. When the answers live in a form tool's silo, every analysis requires an export step first. The form that writes directly to Neon Postgres removes the step entirely, because the data lands where the work happens — and the notification email means nothing waits unseen in a dashboard.

When Typeform is still the right call

The clearest counter-case is a non-technical marketing team running a fifteen-question lead qualification form with branching logic. Typeform's conditional logic builder is genuinely good, and its completion-rate optimizations — one question per screen, progress cues — are backed by testing that a generated form does not replicate. For that team, the $29 to $99 monthly cost is the correct trade-off, because the alternative is a TypeScript file nobody on the team can open.

Our application form has ten fields and no branching. That shape of problem is where generated code wins. But the boundary deserves stating plainly: if your form is fifteen branching questions run by a marketing team, buy the tool. The substitution argument is not about Typeform being fragile or expensive in absolute terms. It is about whether the structural benefits of ownership — data in your own Postgres, edits as small diffs, no re-syncing integration glue — are accessible to anyone on the team.

Every copy change we made in the first week was a small diff deployed with the site. A hosted form would have survived those changes too, for a monthly fee, through a UI that any team member could use without a deploy. Ownership has value at Poolside because the people editing the form are the people who own the repo. On a team without an engineer, that same small diff sits unmerged, and the form breaks in a different and more expensive way.

This is the constraint the substitution argument requires: an engineer in the team. Without one, the structural ownership benefits disappear entirely. The data still ends up in a silo, but now it is your own unmanaged database instead of Typeform's, and the CSV export you used to download in two clicks now requires someone who can write a query. The SaaS cost, in that case, is not overhead — it is the price of having someone else manage the infrastructure and the interface.

The honest version of the argument is narrow: technical teams with simple, stable forms are paying a monthly fee for ownership they already have the skills to hold directly. Everyone else is paying for a service they actually need.

How the same logic applies to the broader SaaS category

The application form is one instance of a pattern. SaaS products whose core job is a thin interface over a database table — survey tools, feedback widgets, simple booking pages, internal request trackers — are all exposed to the same substitution, typically priced at $20–100 a month for a job that is now a paragraph of English and a code review.

The vulnerability is structural, not competitive. No rival SaaS product is undercutting Typeform on price or features. What has changed is the cost of building the alternative. The gate that used to protect these products was a day or two of a developer's time, plus the ongoing ownership that came with it. When building costs one prompt session and ownership means a file in your repo, the calculus flips for any team with an engineer in it.

This matters because the structural argument applies regardless of which specific tool you are evaluating. A feedback widget that writes to a database table is the same problem as an application form that writes to a database table. A simple internal request tracker is the same problem again. The implementation details differ, but the substitution logic is identical: generated code, your own Postgres, no monthly line item, no data silo.

The tools that survive will be the ones serving people who cannot or do not want to deploy code. That is still most of the market. A marketing team editing a fifteen-question branching survey without a deploy cycle is not going away. Neither is the solo founder who has no engineer and needs a form live in ten minutes. Typeform's conditional logic builder and its completion-rate optimizations are real product value for those users.

What has changed is the composition of the customer base. Startups with engineers were among the loudest early adopters of these SaaS tools, and they are now the segment most likely to defect. They adopted Typeform and its category peers because building was expensive relative to subscribing. That ratio has inverted. A team that already pays for hosting, already owns a Postgres database, and already has Claude Code in its workflow is paying $29–99 a month for a constraint, not a capability.

The same logic will compress the addressable market for every product in this category at roughly the same rate, because the underlying shift is in build cost, not in any one product's competitive position. Survey tools, booking pages, internal trackers: each faces the same arithmetic. The question for any given team is whether they have an engineer and a repo. If yes, the subscription is increasingly hard to justify.

Which teams should actually make the switch

Our own form is the template, not the exception. One engineer, a stable ten-field form, an existing deployment pipeline, and a Postgres database already paid for: that profile is where the substitution pays off immediately, before the first monthly invoice arrives. If your team matches it, the decision is already made.

The practical audit starts with your SaaS line items in the $20–100/month range. For each one, ask a single question: is the core function collecting structured input and storing it somewhere? If the schema fits in a single table and the logic has no branching, you are paying a monthly fee for a thin interface over a database row. That is now a one-prompt exercise. Survey tools, feedback widgets, simple booking pages, internal request trackers all fall into this category, and Typeform is the most common example technical teams encounter first.

The threshold at which generated code wins on every dimension is specific: a flat set of fields, one insert query, one notification destination. At that shape, cost drops to zero beyond existing hosting, ownership is a file in your repo, maintenance is a small diff when a question changes, and deployment happens in the same push as everything else. Our application form has survived every deploy since it launched without requiring changes. That is not a coincidence; a form with one insert query has almost nothing to break.

The teams who should not make this switch are equally specific. If there are no engineers on the team, the ownership benefit disappears entirely, because ownership requires someone who can open the repo. The form lives in TypeScript; editing question copy means editing code. Typeform's editing interface exists precisely for this situation, and it is genuinely good at it. Similarly, if the form has complex conditional logic or needs frequent updates from non-technical stakeholders, the SaaS tool earns its price. A fifteen-question branching survey managed by a marketing team is not a one-prompt replacement candidate.

The distinction is not about company size or stage. It is about who touches the form and what the form does. The question is whether the people who would maintain the generated code are the same people who already own the repo. If yes, the substitution is straightforward. If no, you are trading one coordination cost for another.

When building costs one prompt session and ownership means a file in your repo, the calculus flips for any team with an engineer in it. The $90–180 a form tool would have cost us over three months is the small part; the structural costs of a data silo, an iframe with third-party branding, and re-syncing integration glue on every question change are what actually accumulate. Generated code eliminates all three at once, not as a side effect but as the direct consequence of the data living in your own Postgres table from the first submission. If you want to see the result, the form is live at poolside.co/apply.