The form backend we stopped debating
Partner
Basin takes a form's action attribute and turns it into a working backend: spam filtering, email notifications, file uploads, and a submission inbox, without a server to write or maintain. It isn't exciting, and that's exactly why it shows up across our client work more than almost anything else we build with.
We wire it into Jamstack and static sites that have no other reason to run a server, from nonprofit donation forms to enterprise event registration. It's held up across more than a dozen projects without becoming its own maintenance problem, which is the actual bar for infrastructure like this.
Why
Why it's the default
- No server for the sake of one form
A contact form or an event registration doesn't justify standing up backend infrastructure. Point the form's action at a Basin endpoint and the submission, spam filtering, and email notification are handled without a line of server code.
- It scales down as easily as up
The same setup works for a single contact form and for a multi-step registration flow with file uploads and routing rules. We don't reach for something heavier until the requirement actually calls for it.
- Spam filtering that doesn't need tuning
Basin's spam detection runs without us building or maintaining a filter ourselves, which matters because nobody budgets time to revisit form spam rules after launch. It keeps working quietly, which is the whole point.
- It shows up across very different builds
We've used it on a game studio's marketing site, a Midwest grocery chain's event registration, a behavioral science firm's contact forms, and our own site. The common thread isn't the industry, it's that none of them needed more than a form.
