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 product launch can hit in weeks, forcing an upgrade to $59 or $99 under campaign 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 to Claude Code actually produced for Superstables — a six-field waitlist form writing directly to Neon Postgres, with a Slack webhook, deployed in under half 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 the Superstables case 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 pre-launch waitlist 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 product launch, 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 waitlist 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 waitlist 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, as the source brief puts it, "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 half an hour

One prompt to Claude Code produced a six-field waitlist form for Superstables, a payment router for AI agents. The prompt described the outcome: an email field, five multiple-choice qualifying questions about the applicant's role and stage, an optional free-text field, one row per applicant in Postgres, and a webhook to Slack on each submission. Claude Code generated all of it. The whole exercise took under half an hour, most of that time spent reviewing the diff.

The form lives in the team's own repo and writes to a Neon Postgres table. It deploys with the product, 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 POSTs to Slack via an EARLY_ACCESS_WEBHOOK_URL environment variable. The same variable accepts Zapier or any other JSON endpoint, so the destination is a one-line config change. The cost beyond that is zero, because the hosting was already paid for.

The schema makes a deliberate choice about resubmissions: the API route upserts one row per email address. Resubmitting updates the existing record rather than creating a duplicate. That is not a toggle in a dashboard. It is a decision captured in the generated code, visible in the repo, and changeable with a normal pull request. Two weeks after launch, when the team changed one of the qualifying questions, the update was a one-line diff deployed in the same push as everything else.

The form also applies noindex headers across the entire flow. An unlaunched product collecting early-access signups has no reason to appear in search results, and the header ensures it does not. This is the kind of detail a Typeform embed cannot handle at the form level, because the form does not control the page it sits on.

The pre-AI equivalent of replacing Typeform with a custom form was one to two developer days of work. The generated version took under half 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." That sentence is the honest version of an argument 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 Typeform's silo means every qualifying 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 leads. 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, whether Zapier or anything else, is a separate surface that must be maintained independently of the product it serves. When Superstables changed a question two weeks after launch, the fix was a one-line 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 static form with one insert query has almost nothing to break." The Superstables form survived every deploy after launch 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. Qualifying answers are the reason the form exists. For a pre-launch waitlist, those answers tell the team who is applying, what stage they are at, and whether they fit the product. That analysis happens in the team's own database, against the team's own schema, with whatever query the team wants to run.

When the answers live in Typeform's silo, every analysis requires an export step first. Over three months of waitlist collection, that step happens every time someone wants a fresh cut of the data. The form that writes directly to Neon Postgres removes the step entirely because the data lands where the work happens.

The iframe and the silo and the re-syncing integrations are not incidental features of using a SaaS form tool. They are the structural consequence of the data living somewhere else. The $90 to $180 Typeform would have cost Superstables over three months is the visible part of the cost. The invisible part is every CSV download, every re-import, every Zapier update, every moment a qualifying answer was one step removed from the system that needed it.

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.

The Superstables waitlist had six fields and no branching. That shape of problem is where generated code wins. But the source brief is honest about the boundary: "If your form is fifteen branching questions run by a marketing team, buy the tool." That sentence matters because 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 one-line diffs, no re-syncing integration glue — are accessible to anyone on the team.

The two-week question change at Superstables was a one-line diff deployed in the same push as everything else. The Typeform equivalent would have survived that change too, for $29 a month, through a UI that any team member could use without a deploy. Ownership had value at Superstables because engineers owned the repo. On a team without one, that same one-line 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 tools that survive this shift will be the ones serving people who cannot or do not want to deploy code. That is still most of the market. A solo founder running a newsletter, a growth team iterating on onboarding surveys, a recruiter managing application forms — none of these teams have an engineer watching the repo. For them, Typeform's completion-rate optimizations and no-deploy editing are worth more than structural ownership they cannot exercise.

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 waitlist 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 and ownership means a file in your repo, the calculus flips for any team with an engineer in it. That is the source brief's exact framing, and it is correct.

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 a waitlist 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

The Superstables case is the template for how to replace Typeform with a custom form, not the exception. One engineer, a stable six-field form, an existing deployment pipeline, and a Postgres database they 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: six fields, one insert query, one webhook destination. At that shape, cost drops to zero beyond existing hosting, ownership is a file in your repo, maintenance is a one-line diff when a question changes, and deployment happens in the same push as everything else. The Superstables form has survived every deploy since it launched without requiring changes. That is not a coincidence; a static 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. A seed-stage startup with one engineer and a simple waitlist is a better candidate than a Series B company where the growth team owns form content. 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 and ownership means a file in your repo, the calculus flips for any team with an engineer in it. The $90–180 Typeform would have cost Superstables 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.