The Problem
Building a form on the frontend is easy.
The annoying part comes afterward: where do the submissions go?
For a simple contact form, portfolio, landing page, or small website, setting up an entire backend, database, API, validation and deployment can be unnecessary overhead.
I built FormTake to solve that problem.
What FormTake Does
FormTake provides a backend layer for your forms.
Instead of building and maintaining your own form-handling backend, you can connect your existing form to FormTake and manage the submissions through a dashboard.
Basic flow
Website / App
ā
FormTake
ā
Form Submission
ā
Dashboard
Features
- Create and manage forms
- Receive form submissions
- View submissions from a dashboard
- Simple form integration
- API-based submission handling
- Authentication
- Support for modern frontend frameworks
Supported
FormTake can be used with:
- HTML
- React
- Next.js
- Vue
- Astro
- Svelte
- Other applications capable of making HTTP requests
Why I Built It
I've built multiple websites where the actual form wasn't difficult to create ā handling the submissions was.
I wanted something that sat between:
"Build your own backend"
and
"Use a huge form platform for a simple form."
FormTake is my attempt at keeping that middle layer simple.
Built With
- React
- TypeScript
- Node.js
- MongoDB
- REST APIs
- Vite
- Authentication
- Cloud deployment
Demo
A short video showing the product in action is included above.
Try FormTake:
What's Next
I'm currently looking for feedback from developers who actually build websites and applications.
The biggest questions I'm trying to answer are:
- Is the setup simple enough?
- What features are actually necessary?
- What would make you choose this over building your own endpoint?
- What integrations would be useful?
FormTake is live, and I'm continuing to improve it based on real usage and feedback.

Top comments (5)
try now : formtake.owsam22.com
For choosing this over my own endpoint, I'd want the retry contract clear. A useful fixture is a submission that reaches storage but loses its response, followed by the browser retrying the same request. The dashboard should show one submission, while a genuinely new submission with identical fields should still be accepted. Does the API support a per-submission idempotency key, and does the frontend distinguish a confirmed save from an unknown outcome? That matters more to me than another framework integration.
Thanks for pointing this out. FormTake's main goal is to make receiving submissions from static websites and landing pages simple, without requiring developers to build their own backend.
The current focus is on that core workflow rather than advanced retry handling. I understand the distinction you're making between a failed request and a submission that was saved but whose response was lost. That's a useful edge case to consider as the product evolves.š
Pointing a contact or waitlist form at an endpoint instead of standing up a whole API is the useful shortcut. When you invent submissions to prove the dashboard path, use domains you control and look up MX / Null MX before you treat a quiet thank-you as "user ignored the reply" (timeout = unchecked). Reserved fiction phones if the form collects one (US 555-0100 to 555-0199, UK 020 7946 0xxx).
Thanks for the suggestions! The main purpose of FormTake is to make form submissions simple for static websites, portfolios, landing pages, and waitlists without requiring developers to build and maintain a separate backend.
FormTake handles receiving and storing the submitted form data and making it available in the dashboard. Form validation, email or phone verification, and any follow-up emails are outside its current scope and should be handled by the website's form logic or separate services.
That said, using safe test data and distinguishing successful submission storage from email deliverability are useful points to keep in mind. Appreciate the input!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.