The Form Backend I Use for Client Landing Pages
A personal developer review of Forminit and why it became my go-to form backend for client websites, landing pages, lead forms, validation, analytics and UTM tracking.
UUmur
June 1, 2026
10 min read
A personal developer review of Forminit and why it became my go-to form backend for client websites, landing pages, lead forms, validation, analytics and UTM tracking.
June 1, 2026
10 min read
I build a lot of marketing websites, landing pages, and small web products for clients. Most of the time my stack is Astro or Next.js, often with a headless CMS like Hygraph. The frontend part is usually fun. You design the page, connect the CMS, make it fast, ship it, and everyone is happy.
But forms have always been the annoying part.
On paper, a contact form sounds simple. Add a few inputs, submit the data somewhere, send an email, done. In real client projects, it never stays that simple.
A single form submission can be very valuable. It might be a sales lead, a booking request, a partnership enquiry, a job application, or someone ready to pay. Missing even one submission is not acceptable. That is why I stopped treating forms as "just send an email" and started treating them as a serious part of the website infrastructure.
Recently we started using Forminit, formerly Getform, much more seriously across client projects. We had already used Getform for years, but Forminit feels like a much bigger shift than a simple rebrand. It brings a different mental model to form backends.
The first option many developers choose is building a small backend endpoint with Nodemailer, Resend, Postmark, or another email service.
Technically, it works.
Until it does not.
The biggest problem is visibility. If the email stops working, you may not know immediately. Maybe DNS changed. Maybe the email provider rejected something. Maybe the client's inbox rules moved it somewhere weird. Maybe the email landed in spam. Maybe someone changed an environment variable. Maybe the client deleted it by accident.
And even when email works perfectly, it is still a poor database.
Client submissions get mixed with normal email conversations. They are hard to search, hard to filter, hard to report on, and hard to manage as a team. Clients want one clear place where they can see every submission, not a chaotic inbox thread.
Then there is the configuration problem. A client asks:
Can you add another person to the notification email?
Can we change the email template?
Can the reply-to address be the sender?
Can we BCC the sales team?
If this is hardcoded, we have to change code, redeploy, test again, and become the middleman for something the client should be able to manage themselves.
That becomes painful very quickly.
The second option is building our own internal form service.
This sounds attractive at first. We could create our own API, store submissions in a database, send email notifications, and maybe build a simple dashboard.
But that is not a small side task. That is a product.
Once clients start using it, they naturally ask for more:
Suddenly we are not just a web agency anymore. We are building and maintaining a form backend product.
That is not the business I want to be in. I want to build great websites and digital experiences for clients, not spend my time maintaining form infrastructure.
The third option is using a form backend service.
There are many of them, and the space is very competitive. But in my experience, many of them still feel like a slightly better email-forwarding tool. You submit a form, they send an email, and maybe they give you a basic table where you can see submissions.
That is useful, but it does not fully solve the real problems.
We used Getform for a long time, nearly seven years, and it already solved a lot for us. But with Forminit, the product feels more opinionated and more developer-focused. It is not just "send form data somewhere." It feels more like a proper backend layer for forms.
The idea I really like is simple:
That is exactly the separation I want.
My favourite new idea in Forminit is Form Blocks.
Traditionally, form backends accept arbitrary field names. You send name, first_name, fullname, phone, telephone, message, or whatever you decide. That flexibility is nice, but it also creates messy data.
Forminit uses predefined field conventions through its Form Blocks system:
<input name="fi-sender-email" type="email" />
<input name="fi-sender-phone" type="tel" />
<textarea name="fi-text-message"></textarea>At first, this looks like a small naming convention. But it is actually much more useful than that.
Because Forminit understands the type of field, it can validate the data on the server side. If I use a phone block, Forminit validates the phone number. If I use an email block, it validates the email. URL, date, rating, country, file fields, and many others all have their own validation rules.
That removes a surprising amount of boring work.
I do not need to install another validation library just to make sure a client's contact form is not receiving broken phone numbers. I do not need to write the same validation logic again and again. I do not need to trust only frontend validation.
The backend understands the field.
That is a very good model.
Another feature I really like is field-level analytics.
For normal text fields, you usually just want to read the submission. But for select boxes, checkboxes, and radio buttons, the answers themselves are data.
For example, imagine a landing page form with a select field like:
<select name="fi-select-budget">
<option value="under-5k">Under £5k</option>
<option value="5k-10k">£5k to £10k</option>
<option value="10k-plus">£10k+</option>
</select>Or a radio group for project type:
<input type="radio" name="fi-radio-project-type" value="website" />
<input type="radio" name="fi-radio-project-type" value="ecommerce" />
<input type="radio" name="fi-radio-project-type" value="branding" />Forminit can show how often each option was selected and the percentages. That is extremely useful for marketing pages.
Instead of exporting everything to a spreadsheet and doing manual analysis, the client can quickly understand what people are choosing.
That makes forms feel less like a passive inbox and more like a source of business insight.
Marketing attribution is another area where forms usually become messy.
Clients run ads. They have Google campaigns, Meta campaigns, maybe LinkedIn or TikTok. They want to know which campaign generated which lead.
In theory, you can capture this yourself. You can read URL parameters, store them, pass them into hidden fields, handle different click IDs, preserve them across pages, and make sure they are submitted correctly.
In practice, it is annoying and easy to get wrong.
With the Forminit SDK, this is handled automatically. We use the CDN version on some projects, and it can capture UTM parameters and ad click IDs like Google gclid, Meta fbclid, Microsoft msclkid, and others.
That means the form submission is not just:
John submitted the contact form.
It becomes:
John submitted the contact form from this campaign, this source, this medium, and this ad click.
For landing pages, this is a big deal. It helps clients see which marketing channels are actually producing leads, not just traffic.
Another thing I like is Forminit's authentication model.
For simple static sites, public mode is fine. You can submit directly from the browser with stricter rate limits.
But for more serious use cases, Forminit supports protected mode, where submissions require an API key. With Next.js, they provide a proxy helper so the API key stays on the server and is never exposed to the browser.
This is useful for normal forms, but we also started using it for lightweight logging and tracking inside Next.js dashboards.
For example, imagine a client dashboard where we want to track important user actions:
Not every event needs a full analytics pipeline or custom backend table. Sometimes we just need a reliable, searchable, structured place to collect operational events.
Using Forminit in protected mode works very well for that. We can send structured data from our server-side route, keep the API key private, and use the Forminit dashboard as an inbox for important events.
It is not replacing a full analytics product. But for many agency and SaaS projects, it is a very practical pattern.
This part is less technical but still important: I really like the Forminit UI.
The dashboard is fast, clean, responsive, and reliable.
It feels like an inbox, not a clunky admin table.
That matters because clients actually have to use it. A form backend is not only for developers. After we hand over a website, the client's team needs to read submissions, search them, mark them, follow up, and manage them without asking us every time.
The real-time dashboard experience also feels very polished. New submissions appearing live gives it more of a native app feeling than a traditional web admin panel.
Good job to the Forminit team on that.
For agencies and freelancers, forms are one of those things that look small but create long-term support work.
Every new client website needs forms. Every form needs notifications. Every notification can become a support request. Every submission matters. Every client eventually wants exports, integrations, analytics, or changes.
That is exactly the kind of repeated problem where a good product saves time.
Forminit lets us keep building websites the way we want. Astro, Next.js, custom UI, headless CMS, whatever the project needs. We do not have to compromise the frontend design or embed an ugly form builder.
But after submit, we get a proper backend:
That is the right division of responsibility.
I used to think of forms as a small feature.
Now I think of them as infrastructure.
A form submission can be a lead, a sale, a booking, or a very important customer message. It should not disappear into an inbox with no visibility. It should not depend on a small custom script that nobody checks. And it should not force an agency to build and maintain a whole internal product.
Forminit gives us a clean way to handle this.
We can keep full control over the frontend, build forms that match the website perfectly, and let Forminit handle the difficult backend parts. The Form Blocks model, server-side validation, field analytics, UTM tracking, protected mode, and fast dashboard make it feel like a modern form backend rather than just another email forwarding tool.
For the kind of client work we do, that is exactly what we need.
If you're building marketing websites, landing pages, or client projects and you're tired of reinventing form infrastructure, I highly recommend checking out Forminit and especially their Form Blocks documentation. It is one of those tools that quietly removes a lot of complexity from your workflow while giving clients a much better experience.