Form Backend for Freelancers and Agencies

If you build websites for clients, the form is the part that repeats. Every client wants a contact form, most want quote or lead forms too, and every one of those forms needs the same small piece of infrastructure behind it. This page describes how freelancers and small agencies handle that piece once, as a service, instead of rebuilding it per project. The client side of the same picture is the small business page; the concept is in What Is a Form Backend?

The repeated problem

A client site is usually frontend only: static pages, or a frontend application, hosted somewhere simple. Then the client asks for a contact form, and the choices are all heavier than the form deserves. Build a small backend for this project and host it, patch it and answer for it when it breaks. Wire the form into whatever the platform happens to offer and accept its limits. Or skip the backend entirely and watch inquiries go nowhere.

Multiplied across projects, the first option is the expensive one, not in any single build but in the tail: a fleet of tiny, slightly different form backends, each with its own hosting, its own spam problem and its own way of failing silently at the worst moment.

The reusable pattern

A hosted form backend turns the per project backend into a per form address. The flow is the same on every project: the client's form posts to its endpoint at Form Backend, the submission is checked (format, size, rate limit, the honeypot spam trap), stored first, and then delivered to the dashboard and to a notification email. Nothing about the client's hosting changes, and the pattern is identical whether the site is static HTML or a framework build, which is what makes it reusable. The static websites guide walks through the no-framework case in full.

A repeatable delivery workflow

  1. Create one form per client form. A contact form and a quote form get separate forms in the dashboard, even on the same website, so their submissions stay sorted and each can notify a different address.
  2. Set the notification email to the client's address. It must be verified once, and from then on the client receives every inquiry directly in their own inbox. The client does not need dashboard access for this to work.
  3. Connect the website form to the endpoint. The implementation depends on the stack, and each one has a guide: the step by step tutorial for a first static form, the HTML reference for existing forms, and the React and Next.js guides for frontend builds.
  4. Test before handover. Submit the live form yourself, confirm it in the dashboard and in the client's inbox, and check the thank-you page. The same three checks, every project.
  5. Decide who owns the account. See the next section; it is the one decision that matters, and it is better made at delivery time than later.

How multiple clients actually work, stated plainly

There is one account, and the account holds the forms. On the Free plan an account can hold up to 3 forms. On Pro and Agency there is no cap on the number of forms; what is limited per form is the monthly submission quota (2,500 on Pro, 10,000 on Agency). Each form has its own endpoint and its own notification email, which is what makes two honest working models possible:

  • Your account, their inbox. You hold one account with a form per client site. Clients receive their inquiries by email at their own address and never need to log in anywhere. You keep the dashboard, including spam review and CSV exports. This suits ongoing maintenance relationships.
  • The client's own account. You set the forms up in an account the client owns, connect their site, and hand over the login. The client has the dashboard and the plan is theirs. This suits one-off builds with a clean handover.

What does not exist today, so it is not promised here: there are no team seats or sub-accounts, no organisation level permissions, no white labelled dashboard for your clients, and no per-client billing inside one account. Billing is per account, which is exactly why the ownership decision above matters. If your agency model depends on those features, this is not the tool for that model yet, and the support page is the place to say so.

Use cases across client projects

  • Client contact forms: the standard form on almost every site you ship, pointed at its own endpoint with notifications to the client.
  • Quote and request forms: structured fields for the job details, so the client's first reply can already move the conversation forward.
  • Service inquiry forms: one form per service page, submissions sorted by service without any extra tooling.
  • Lead capture: short forms for callbacks and price lists, with the same delivery and spam handling as every other form.
  • Several forms, several sites: the same setup repeated, with the live demo available when a client wants to see the receiving side before you build anything.

When this is a good fit

  • You deliver marketing and business websites whose forms start conversations rather than run transactions.
  • Your clients are small businesses whose inquiry volume sits comfortably inside the plan quotas, as the owner-focused page describes from their side.
  • You would rather standardise on one form pattern you know well than maintain a different small backend per project.
  • The sites are static or frontend only and you want to keep them that way.

When to build custom instead

  • The form must receive files. File uploads are not stored here; a form built around document or image intake needs its own handling.
  • Submissions must flow into other systems automatically. There are no outgoing webhooks, so nothing is pushed into a CRM or automation tool. What exists is the dashboard, email delivery and CSV export.
  • The client expects an automatic reply to the visitor. There is no autoresponder; confirmation is the thank-you page.
  • The form is really an application. Accounts, payments, bookings or multi-step state belong in a real backend you control, as the concept article also concludes.
  • Volume beyond the quotas. 25 KB per submission, 50 fields, a rate limit of 10 submissions per 60 seconds per form per visitor, and the monthly per-form quotas in the documentation are the ceilings. A form that will live above them is a custom build.

Pricing for repeat work

Free covers up to 3 forms at 250 submissions per form per month, enough to prove the workflow on real projects. Pro is $12 per month with no cap on the number of forms and 2,500 submissions per form per month, including WhatsApp notifications. Agency is $35 per month with no cap on the number of forms and 10,000 submissions per form per month, and it is the plan the product itself positions for freelancers and small agencies running forms for multiple sites. The figures are the live ones in the pricing section. Because billing is per account, the ownership model you choose per client decides who pays, which is a conversation to have with the client at delivery time, not a feature to assume.