Replace Google Forms with a custom app, and when not to

The request usually arrives as a complaint about the form. It is ugly, it does not match the brand, somebody typed their phone number into the email field again. Those are real annoyances and none of them is a reason to build software. The reason to build software is almost always downstream of the form, in what has to happen to a submission before it is any use to anyone.

So the useful question is not "can we replace Google Forms". It is "what are we doing to these submissions by hand, and how many of them are there". If the answer is forty a month and two minutes of copying each, you have an eighty-minute problem and a rewrite is a bad trade. If it is four hundred a month, three people touching each one, and a decision that depends on what the last submission said, the form is no longer the system. A spreadsheet behind it is pretending to be one.

What Google actually documents as a limit

Worth separating the published constraints from the folklore, because the folklore has numbers in it that Google does not publish. There is no documented maximum number of questions or responses on a form. What is documented, and what catches teams out, sits around file uploads and around automation.

On uploads, Google's help page for the file upload question type is specific: "To answer this question, responders need to sign in to a Google Account", and for the owner "uploaded files are stored in a new folder on Google Drive". The same page lists two conditions under which the question type is simply unavailable: you cannot use it if the form is stored in a shared drive, and you cannot use it if your administrator has turned on Data Loss Prevention. The owner sets the maximum file count and size, but Google does not state a ceiling for either, and the practical ceiling is the owner's own Drive quota.

Read those together and the shape of the problem appears. A public intake form that needs a document attached requires every member of the public to have a Google account and be signed in. For an internal HR form that is fine. For a supplier onboarding form, a grant application, or anything a customer fills in, it is a wall, and no amount of form design gets around it. Details are on Google's page for choosing a question type in Google Forms.

Symptoms, and what each one actually calls for

Write your own version of this before you commission anything. The middle column is the one that saves money.

The pattern in the right-hand column is that only the bottom three are software. The rest are configuration, a script, or a decision to live with something. Teams that skip this table tend to buy the bottom three when they needed row two, which is the general case covered in signs you need custom software, and signs you do not yet.

The step in between, which is usually the right one

Before a rewrite there is an option people forget: keep the form, and automate what happens after it. Forms has a documented API, and for the "somebody retypes this" problem it is normally enough.

The quotas are published and they are not tight. Google's usage limits page for the Forms API gives 975 read requests per minute per project and 390 per minute per user, 450 per minute for the expensive read that lists responses, and 375 write requests per minute, with the note that "provided you stay within the per-minute quotas below, there's no limit to the number of requests you can make per day". Exceeding a quota returns HTTP 429 and the documented remedy is truncated exponential backoff.

One line on that page is worth putting in a budget note rather than a technical one: standard use is free today, and Google states that exceeding quota limits is planned to incur charges to a Google Cloud billing account later in 2026. That does not change the decision for a form taking four hundred submissions a month, which is nowhere near these numbers. It does mean an integration built on polling every few seconds across many forms has a cost attached to it that did not exist when it was designed.

If this route works, you have solved the actual complaint for a fraction of a rewrite. The question of where that stops is the whole of no code versus custom development.

What a custom app buys that a form cannot

Three things, and they are the only three worth paying for.

• Identity that is not Google. Anyone can submit, with or without an account, and you still know who they are.
• State. A submission that is pending, then in review, then approved, with a history of who moved it. A form produces a row; a row has no lifecycle.
• Rules at the point of entry. Not "this looks like an email address" but "this supplier already exists", "this date is outside the window", "this amount needs a second approver".

Everything else on the usual wish list is cosmetic or can be bought. If the three above are not what you need, the honest answer is that the form is fine and the problem is elsewhere, usually in the spreadsheet behind it. That migration is its own piece of work and is covered in migrate from spreadsheets to a database without losing the history.

What it costs, honestly

A replacement for a single intake form, with its own authentication, a real database, validation rules and one approval step, is a small build and not a trivial one. The form itself is a day. The rest is the week or two, and the maintenance is the part that keeps going: Google maintains Forms for you and nobody maintains yours.

That is the trade in one sentence. You are exchanging a free, maintained, limited tool for an owned, unlimited, unmaintained one. It is a good trade when the limits are costing you more than the maintenance will. It is a bad trade when somebody simply wants the form to look nicer. The broader version of this calculation is in internal tools for a small business, and when to stop using Excel.

Before you build, fix the destination

One sequencing point that is cheap to get right and expensive to get wrong. If the submissions end up in a CRM, the discipline at that end decides whether a better form helps at all. A clean intake feeding a CRM nobody maintains produces tidier mess. BDG Labs set out the rules that survive contact with a small team in CRM hygiene for small sales teams, and the first two of those are worth settling before anyone writes a line of this app.

When to stay on Forms

Stay if your respondents all have Google accounts and no attachments are involved, or no attachments at all. Stay if the submission is read once and then filed. Stay if the volume is low enough that the manual step costs less than an hour a week. Stay if the only complaint is appearance.

Leave when a submission has a life after arriving, when people outside your organisation have to attach documents, or when two people editing the same record can produce two different answers. Those are structural and they do not get better with a nicer form.

The honest limits of this note

We have not given you a response ceiling for Google Forms, because Google does not publish one and the figures circulating are third-party guesses that disagree with each other. If you are near a limit you believe exists, test it on a copy of your form rather than trusting a blog, including this one.

We have also not priced your build. Anyone quoting a number for "replace a Google Form" without asking how many approval steps exist and who has to sign in is quoting for the easy day and not the hard fortnight. Count the states a submission can be in, and count the people who can change them. Those two numbers are the estimate.