Here is the lead-capture setup I see most often on a small business website: a Typeform embedded in an iframe, a Make or Zapier scenario copying each response into a Google Sheet, and a tag manager that can't see the submit because it happened inside someone else's frame. One agency owner on Reddit describes it as a system: "Once a lead fills out the form on our site, Make.com transfers the data into a Google Sheet in real-time." It works. Until the sheet is where enquiries go to wait until Monday.
I'm Gabriel, founder of SharpHaw, a small agency in Lisbon, and the engineer behind SharpOS, the workspace we run every client engagement in. This is part of a series that walks our replacement ledger a row at a time. Row 4: Google Forms and Typeform on the left, Forms on the right. This post is what that row means, how the surface is built, and where it is thinner than the tools it stands in for.
TL;DR: a client's website form is the first row of their work, so we built Forms as the place that row lands, either as a hosted page or as an endpoint the client's own site POSTs to.
What Google Forms and Typeform are for, and where they strain
Both are excellent at the job they were built for: a person writes questions, shares a link, and reads answers in a table. Google Forms is free and everywhere. Typeform made the one-question-at-a-time flow feel like a conversation, and a lot of people finish a form they would have abandoned as a wall of fields.
The strain starts when the form belongs to a client's website and its submissions are supposed to become work. The response lives in a third party's account, so the agency reviewing it needs one more login and the client needs another. Getting it anywhere useful means an automation hop through yet another tool. And the embed sits in an iframe, which is why a thread on r/PPC ends with the advice that if you need to track a Google Form submission you should "switch to a different one". Every one of those seams is a place the enquiry can go quiet, and nobody in the engagement finds out until the client asks why the phone didn't ring.
What Forms does instead
Forms is an org-scoped form builder inside SharpOS. An agency builds a form for a client, in a Tally-style doc builder with 16 field types grouped into sections, rendered either as one scrolling page or as a multi-step flow. You can open the fixture version yourself at showcase/sumi/forms, a browser-only copy of the hub with a fictional sushi counter's data and nothing wired to a backend.
A published form is used one of two ways. The first is a hosted page at its public address, chromeless, white-label, styled from the organisation's Brand Kit by default so a form inherits the client's colours, fonts and corner radius without anyone configuring it. The second is an API endpoint the client's own website POSTs to, which is the mode I care about most: the form on the site stays the client's own HTML, and the submission still lands in SharpOS.
Either way, the submission becomes a record in the client's organisation, reviewed in a Submissions table by the people doing the work, and it fires a form-submitted event that Automations can act on. Every answer is available downstream as the visitor's answers as variables, so "a new enquiry creates a card on the board and notifies the account owner" is a workflow, not a Zapier bill. If the client wants a spreadsheet anyway, a per-form Google Sheets sync appends every submission as a row in a sheet they own.
Roles hold inside the surface: any member can read a client-visible form, editors and above edit it, and submissions are agency-internal whatever the form's visibility. Deleting a response is irreversible, so it sits with owners only. The whole surface is behind the Forms feature flag, enforced in the UI and again in the backend.
How it works
The public side is deliberately small. A form has one public submit address, that address is its only credential (it is scoped to that one form), and the payload is keyed by stable field ids rather than labels, so a client renaming a field later doesn't break their website. From the client's site, the whole integration is a single request on submit: send the field values, get back a submission id. A draft or disabled form answers "not found"; a duplicate email, where the form forbids duplicates, is refused with a clear reason; a caller over the limit is told to back off rather than silently dropped.
Behind that endpoint are the decisions that took the time. The honeypot returns success and stores nothing, so a bot can't tell a dropped submission from a stored one. Rate limits are two buckets, not one: a per-client bucket of 20 a minute keyed on form and IP, and a separate per-form ceiling of 500 a minute, so an attacker spending their own bucket on invalid payloads can't exhaust the form for real visitors. Submissions snapshot every answer with the field's id, label and type at the time, which is what lets a historical response still render after the client renames or deletes a field.
File uploads go through a two-step flow, request an upload slot then register the file, and on submit the server re-verifies that the file belongs to the form's organisation, sits in the form's own Media Center folder, and was created through that flow. A file that didn't arrive that way fails validation. The Google Sheets sync writes values as plain text rather than letting Sheets interpret them, because otherwise a visitor typing a formula into a field would hand the client a live formula the moment they opened the file; the cost is that numbers arrive as text. And the sync is scheduled after the submission is safely stored, never inside the same transaction, so a Sheets outage can flag an error on the card but can never lose or delay an enquiry.
What it doesn't do
Typeform's conversational flow and its depth of conditional logic are real product advantages, and Forms doesn't have them. We render single-page or multi-step sections; there is no branching logic today. Google Forms is free, needs no organisation, and is fine for a one-off survey among friends. If your form is a survey, a quiz, or a research instrument, keep those tools. Forms is for the case where the form is a client's lead intake, feedback, or onboarding surface, and the thing that matters is what happens after the submit.
Where it sits in the service
Forms is part of the Conversion-First Websites work SharpHaw runs for its clients: a site is only doing its job when the enquiry it produces reaches a person who acts on it, and this is the surface that makes the enquiry visible without anyone exporting anything. The feature page is at sharphaw.digital/features/forms; the service it belongs to is described at sharphaw.com/services/conversion-first-websites, and the workspace it ships inside at sharphaw.com/sharp-os.
One question
For those of you running client sites: do you embed a third-party form and pipe it somewhere, or POST to your own endpoint, and what broke first? I've argued the endpoint side here, and I'd like to hear the cases where the embed was the right call.
This is part of SharpOS, surface by surface. Part 1, the ledger and the row we couldn't replace, is here.
Top comments (0)