How to Collect Form Responses Without a Backend

Building a form that collects and stores responses is surprisingly involved when you do it from scratch. You need an API endpoint to receive submissions, a database to store them, authentication to protect the data, and a way to view it. For many use cases - a contact form, an event sign-up, a feedback survey - that is a lot of infrastructure for something that should take 20 minutes.

This guide covers the options available, what to use when, and how to get a form collecting responses without writing any backend code.

1. The problem with the traditional approach

The traditional approach to form submission looks like this:

// The traditional path - a lot of setup for a simple form
const handleSubmit = async (e) => {
  e.preventDefault();

  // 1. You need an API route to receive this
  const res = await fetch("/api/contact", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(formData),
  });

  // 2. That API route needs to connect to a database
  // 3. The database needs to be set up and hosted
  // 4. You need auth to protect reading the data
  // 5. You need a UI to view the submissions
  // 6. You need to handle errors, retries, and rate limiting
};

None of these steps are hard individually, but together they represent hours of work that has nothing to do with the actual purpose of the form. For a contact form or a survey, this overhead is almost never worth it.

2. Options for collecting responses without a backend

There are several approaches, each with different trade-offs:

Email services (Formspree, Netlify Forms)

Send form submissions to a service that emails them to you. Easy to set up, but responses live in your inbox rather than a structured dashboard. Hard to search, filter, or export. Free tiers are usually limited to 50-100 submissions per month across all forms.

Google Forms

Free, stores responses in Google Sheets, easy to share. But it does not look like your product - you get a Google-branded form with limited styling control. Not suitable if brand consistency matters.

Typeform, Tally, Jotform

Polished form tools with good response dashboards. Most require a paid plan for anything beyond very basic usage. None of them let you export the form as React code to embed in your own app.

Publish with ReactForm.co

Build your form visually, hit Publish, and get a shareable URL. Responses are stored securely and viewable in a dashboard. The free plan includes 3 forms and 50 responses each. If you later need the form embedded in your own app, you can export the same form as a React component.

3. How response collection works on ReactForm.co

When you publish a form, it gets a unique public URL at reactform.co/f/[your-form-id]. Anyone with the link can open it and fill it in - no account required for respondents.

When a respondent submits the form:

1. The submission is validated client-side against your configured rules
2. The response data is saved to Firestore under your account
3. The response counter on your form is incremented atomically
4. The respondent sees your configured success message
5. The response appears immediately in your dashboard

Responses are tied to your account and only visible to you. The Firestore security rules enforce this - no other user can read your form responses, even if they know the form ID.

4. What you see in the response dashboard

The response dashboard at /f/[slug]/responses shows a table with one row per submission. Columns are generated from your form field definitions in the order you defined them.

Each row shows:

• Submission number
• Timestamp of when the form was submitted
• One column per field with the respondent value
• Boolean fields (checkboxes) shown as checked or unchecked badges
• Empty values shown as a dash

On the Pro plan you can export the full response table as a CSV file for use in spreadsheets or data analysis tools.

5. Response limits and what happens when you hit them

The free plan allows 50 responses per published form. This limit exists to keep the free tier sustainable. Here is what happens as you approach it:

• Your form card in My Forms shows the current response count
• When a submission would exceed 50, it is blocked with a clear message to the respondent
• You can delete existing responses to free up capacity
• Upgrading to Pro removes the limit entirely

The limit is enforced on the client side when the form loads. If your form has already reached 50 responses, the submit button is disabled before the respondent fills anything in.

6. When you actually do need a backend

There are situations where a no-backend approach is not the right fit:

File uploads

If your form needs to accept file attachments, you need somewhere to store them. This requires a backend with object storage (S3, Cloudflare R2, etc.). This is a Pro feature on the roadmap for ReactForm.co.

Triggering server-side logic on submit

If a form submission needs to trigger a payment, update a database record in your own system, or send a customized transactional email, you need a backend. You can use the webhook integration (Pro feature) to send submission data to your own endpoint, or export the form as React code and wire up your own handleSubmit.

Very high volume

If you expect thousands of submissions per day, you should evaluate whether a dedicated backend with rate limiting and spam protection is more appropriate.

Complex data relationships

If a submission needs to be linked to a user account in your own system, matched against existing records, or processed as part of a workflow, you need your own backend.

For everything else - contact forms, surveys, event registrations, feedback forms, waitlists, and intake forms - a no-backend approach is faster to set up, cheaper to run, and more than sufficient.