How to Build an App Like Typeform

The form builder is the interface your team (or your customers' teams, if you are building a white-label product) uses to create and edit forms. The builder has two modes: a design mode where form creators add, reorder, and configure questions, and a preview mode where they see the form as respondents will experience it.

Question types cover the standard set: short text, long text, multiple choice (single select), checkbox (multi-select), dropdown, rating scale, number input, date picker, file upload, email, phone, URL, and statement (display text without collecting input). For specialized use cases, custom question types -- a signature field, a drawing pad, a location input -- are added on top of the standard set.

The one-question-at-a-time interface with animated transitions between questions is the feature that drives Typeform's completion rate advantage. Each question fills the screen. The respondent presses Enter or clicks Next to advance. The transition animation (slide, fade) reinforces the conversational feel. Progress indication -- a thin bar across the top or a "Question 4 of 12" label -- manages the respondent's expectation of how much remains.

The form builder needs to be usable by non-technical users. Drag-and-drop question reordering, click-to-edit question text, and a panel for question settings (required, placeholder text, character limit) keep the interface simple. Conditional logic is the most complex part of the builder interface -- it needs to be visual and forgiving, not a scripting environment.

Conditional logic determines what the respondent sees next based on what they have already answered. A rule consists of: a trigger (if the answer to Question 3 is "Yes"), a condition (and the answer to Question 1 is "Individual"), and an action (skip to Question 7). Multiple rules can be combined with AND and OR logic. A question can have multiple rules that point to different destinations.

Branching is conditional logic applied to the entire form path rather than individual questions. A branching point routes the respondent to a different sequence of questions based on their answer. An insurance intake form might branch into auto, home, health, and life claim paths based on the first question. Each path has its own sequence of questions before converging at a common submission screen.

The logic engine needs to handle complex rule sets without creating conflicts or loops. A rule conflict occurs when two rules apply to the same question and point to different destinations. A loop occurs when logic routes the respondent backward in the form. The builder should detect and prevent these conditions, not silently break the form at runtime.

For domain-specific forms with complex logic, the rule-building interface needs to support the domain's natural expression. A clinical assessment builder might express logic as "if PHQ-9 score is greater than 15, show the crisis resource question" -- the score is computed from earlier answers, not entered directly. This requires the logic engine to support computed values as trigger conditions, not just direct answer comparisons.

Scoring assigns a numeric value to each answer option. A lead qualification form scores each answer: company size over 500 employees scores 10 points, budget over $100,000 scores 15 points, decision timeline under 90 days scores 20 points. The total score is calculated when the respondent submits. Score thresholds determine routing: a score over 50 triggers an immediate notification to a sales rep; a score between 25 and 50 enrolls the lead in a nurture sequence; a score below 25 receives a self-service resource.

Custom scoring formulas extend basic point addition. A clinical assessment might use weighted scoring where some symptoms contribute more to the total than others. A financial qualification form might calculate a debt-to-income ratio from multiple inputs rather than assigning fixed point values. The scoring engine needs to support arithmetic operations on collected values, not just fixed point assignments.

Score outputs can drive conditional logic: "if the total score is greater than 70, show the high-priority response message and skip the standard follow-up questions." Score outputs can also drive downstream routing: send a webhook to the CRM with the score included in the payload, so the CRM automation can trigger the appropriate follow-up sequence without a human reviewing each submission.

File upload questions let respondents attach documents, images, or other files as part of their form submission. A patient intake form might request insurance cards and photo identification. An insurance claims form might request photos of the damage and a police report. A legal intake form might request relevant contracts or correspondence.

Storage management determines where uploaded files go, how long they are stored, how they are accessed after submission, and how they are deleted when a retention policy requires it. For HIPAA-compliant platforms, uploaded files containing PHI must be stored on BAA-covered infrastructure with encryption at rest and audit-logged access. For general-purpose platforms, cloud storage (S3 or equivalent) with signed URL access is the standard approach.

File size limits, accepted file types, and virus scanning are standard requirements. The upload interface on the form needs to show progress for large files, handle upload failures gracefully, and confirm that the file was received before the respondent advances to the next question. On mobile, camera integration lets respondents take a photo directly rather than navigating to a saved file.

Webhook integration is the minimum viable integration layer. When a form is submitted, the platform sends a POST request to a configured URL with the response data as JSON. The destination -- a CRM, a Zapier workflow, a custom API, a Slack channel -- processes the data according to its own logic. Webhooks decouple the form platform from downstream systems and let you connect to any tool that accepts HTTP requests.

Direct CRM integrations go deeper. A Salesforce integration can create a new Lead or Contact record, populate standard and custom fields from form answers, associate the submission with an existing Account, and trigger a Salesforce workflow. A HubSpot integration creates a Contact, associates it with a Deal, and enrolls it in a workflow sequence. A Pipedrive integration creates a Person and a Deal with properties mapped from form answers.

For platforms handling sensitive data, the integration architecture matters for compliance. Webhooks that send PHI to a non-BAA-covered endpoint violate HIPAA. Direct integrations with compliant downstream systems (a HIPAA-covered CRM, an internal system) are the safe path. The integration configuration interface should warn form builders when they configure a destination that cannot accept PHI and offer alternatives.

Response analytics tell form creators how their forms are performing. Completion rate is the headline metric: what percentage of respondents who started the form submitted it. Drop-off analysis breaks this down by question: which question do most respondents abandon the form on? A high drop-off rate at a specific question indicates a problem with that question -- it is too long, too personal, or too unclear.

Answer distribution shows the breakdown of responses for each question. For a multiple-choice question, a bar chart shows what percentage of respondents selected each option. For a rating scale, a distribution curve shows the spread of ratings. For a numeric input, a histogram shows the value distribution. These distributions let form creators identify whether their answer options are well-calibrated and whether the response distribution matches their expectations.

Time analytics show how long respondents spend on each question and on the form overall. A question where respondents spend much longer than expected may be confusing. Average completion time for the full form helps set expectations in the form description and helps the creator estimate whether the form is an appropriate length for the context.

For platforms with multiple forms across multiple users or teams, a dashboard aggregates metrics across the form library: total submissions in the last 30 days, average completion rate across all forms, forms with below-average completion rates flagged for review.

Custom branding replaces Typeform's visual identity with the form creator's brand. This includes the logo, colors, typography, background images or gradients, button styles, and the completion screen. For a SaaS product embedding forms in its user experience, the form should look and feel like an extension of the product -- not a tool from a third-party vendor.

White-label extends branding to the form platform itself. A white-label form builder gives the purchaser (typically an agency or a SaaS company) a form creation tool under their own brand that they sell or give to their clients. The clients see only the purchaser's brand throughout: the builder interface, the form URL (on the purchaser's domain), the respondent-facing form, the completion screen, and the response dashboard.

Custom domain support is a baseline requirement for white-label. Forms are served from the purchaser's domain (forms.yourdomain.com) rather than the platform's domain. SSL certificates are provisioned automatically. Custom domains need to work for both the form creation interface and the respondent-facing forms.

Embedding lets form creators put their forms directly inside another web page or application rather than directing respondents to a separate URL. An iframe embed is the simplest option: a snippet of HTML that inserts the form as a contained element within the host page. This works well for landing pages and blog posts but breaks on mobile if the iframe cannot resize to the screen.

A JavaScript SDK provides more control. The SDK renders the form in an overlay (popup or slide-in drawer) triggered by a button click, or as an inline element that responds to the host page's layout. The SDK passes context from the host page -- the logged-in user's email, their account ID, their plan name -- to the form as hidden field values. This lets the form pre-populate fields and route responses to the right place in the downstream system without asking the respondent to re-enter information your product already has.

The headless API is for product teams that want complete control over the respondent-facing UI. The API returns the form definition (question types, order, conditional logic, validation rules) and accepts response submissions. The product team builds their own UI, styled and behaving exactly as they need, using the API as the backend. This is the right approach for deep product integrations where the form experience needs to be indistinguishable from the rest of the product.

We build the drag-and-drop form builder with a complete question type library. The conversational one-question-at-a-time interface with animated transitions and progress indication is built and tested across browsers and devices. The builder interface is designed for non-technical form creators: clear affordances, immediate preview, and a settings panel that does not require engineering knowledge to navigate.

Custom question types specific to your domain -- a signature pad, a product configurator, a location picker, a clinical scale -- are built on top of the standard question type library using the same extension architecture.

We build the conditional logic engine with rule-based show/hide logic, multi-path branching, and computed value conditions. The logic builder in the form creation interface is visual: select the trigger question, select the condition, select the destination. Rules are tested in preview mode before publishing. Conflict detection prevents invalid rule configurations from reaching respondents.

For domain-specific logic requirements, we extend the engine with the expression types your forms need: score thresholds as trigger conditions, arithmetic operations on collected values, and lookup table conditions for state-specific regulatory routing.

We build the scoring engine with per-answer point assignment, weighted scoring, and formula-based score calculations. Score thresholds drive conditional logic within the form and routing decisions at submission. The scoring configuration interface in the form builder lets non-technical users set up scoring rules without code.

Submission routing based on scores, answer values, or computed properties sends responses to different destinations: a CRM record creation, a webhook to an internal system, an email notification to a specific team member, or an automated response to the respondent. Routing rules are configurable without engineering involvement.

We build webhook infrastructure with configurable payloads, retry logic, and delivery logs. Direct integrations with Salesforce, HubSpot, and Pipedrive are built for the highest-value connections, with field mapping configuration that non-technical users can manage.

For HIPAA-compliant platforms, the data pipeline is designed to keep PHI within BAA-covered infrastructure throughout its lifecycle: from form submission to storage to CRM sync to audit log. We design the integration architecture to route PHI only to compliant downstream endpoints.

We build the response dashboard with individual response review, bulk export (CSV and JSON), and aggregate analytics. Completion rate, drop-off by question, answer distributions, and time-on-question metrics are displayed for each form. A cross-form dashboard shows performance across the full form library.

The individual response view shows all answers in a structured layout, with file attachments accessible via signed download links. Response filtering and search let team members find specific submissions by date, answer value, or score range. For regulated platforms, response access is logged with user, timestamp, and action.

We build the white-label infrastructure with custom domain support, automatic SSL provisioning, and a theming system that covers logo, colors, typography, and completion screen. The white-label configuration is managed from the platform admin without requiring code changes.

The embedding SDK handles iframe, overlay, and inline embed modes with context passing from the host page to the form. The headless API returns form definitions and accepts submissions, enabling product teams to build fully custom respondent interfaces on top of the platform backend.