DEV Community: Menelaos Vergis

A feedback screen for Android and Flutter with no server: what testing taught us

Menelaos Vergis — Fri, 06 Nov 2026 03:30:46 +0000

Originally published on the BootForm blog. I work on BootForm, the form backend these samples send to; the samples are free and MIT licensed.

In short: an app can send feedback straight to a form backend, so you don't need a server of your own. Our open-source in-app-feedback samples do it in one file per platform: device info attached, an offline queue, and an optional screenshot. The biggest lessons from testing: save the report before you send it, expect Android's force stop to pause your queue, give every report an ID so a retry can't send it twice, decide what to do for each kind of answer, and be honest that an app can't keep its form ID secret.

The samples send to BootForm, but the lessons apply to any backend you'd point an app at.

What we built

A "Send feedback" or "Report a bug" screen for an Android or Flutter app, where each report arrives in a dashboard (and by email, Slack or Discord if you like) with what you need to act on it:

Device info, attached automatically: app version and build, OS version, device model, locale.
An offline queue: a report written in airplane mode is kept and sent later.
An optional screenshot of the screen the user was on, which they can see and leave out.

It's not an SDK. Each platform is one file you copy into your app, plus a small demo app: Kotlin with Jetpack Compose and WorkManager for Android, and Dart for Flutter. The whole API is one HTTP request:

POST https://f.bootform.com/{your-form-id}
Content-Type: multipart/form-data
Accept: application/json

We tested both demo apps on an Android emulator (API 36) against the live API, then tried to break them. This is what we learned.

1. Save first, send second

The obvious design sends the report when the user presses Send. That's the wrong moment to depend on the network: people write feedback when something's going wrong, and a bad connection is often part of it.

So both samples save the report on the device first, then try to send it. The button never waits on the network, and the screen says what actually happened. On Android:

Saved. It will be sent as soon as you're online, even if you close the app.

and only "Sent. Thank you!" once the server has answered. Telling a user "Sent" while the report is sitting in a queue is a small lie that turns into a real one if the queue is lost.

2. Android: WorkManager survives the system, not a force stop

On Android the queue is a WorkManager job with a network constraint and exponential backoff, starting at 30 seconds:

val request = OneTimeWorkRequestBuilder<FeedbackWorker>()
    .setConstraints(Constraints(requiredNetworkType = NetworkType.CONNECTED))
    .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 30, TimeUnit.SECONDS)
    .setInputData(data.build())
    .build()
WorkManager.getInstance(context).enqueue(request)

We wrote a report in airplane mode and then tried the ways an app gets closed:

The system kills the process (app in the background, adb shell am kill <package>). Network back on: the report went out without the app being opened. That's the point of WorkManager.
Force stop (Settings, Apps, Force stop, or adb shell am force-stop <package>). Network back on: nothing, until we opened the app again, and then it sent straight away.

The second isn't a bug. A force stop puts the app in Android's "stopped state": its scheduled jobs are cancelled until the user launches it again. WorkManager reschedules them on that next launch. adb shell dumpsys jobscheduler | grep <package> shows whether your job is still there.

What we changed: nothing in the code, but the README says it plainly, and the retries are bounded. WorkManager caps the backoff at 5 hours, and the sample gives up after 15 tries, about a day and a half of trying while online, instead of retrying forever.

3. Flutter: send when the app is open, and keep it simple

Flutter can run background work, but on iOS that means native setup and platform rules that are easy to get wrong in a sample people copy. So the Flutter version makes a different trade: each report is saved as a JSON file (plus the image) in the app's support folder, and the queue is sent when the app starts and whenever it comes back to the foreground:

BootFormFeedback.flush();
_lifecycle = AppLifecycleListener(onResume: BootFormFeedback.flush);

It doesn't send while the app is closed, and reports older than 7 days are dropped. In return it needs only four common packages (http, path_provider, device_info_plus, package_info_plus) and no background setup on either platform. For feedback, "sent next time you open the app" is usually good enough.

4. Retries send duplicates, unless every report has an ID

A queue that retries is "at least once". If the server stores the report but the app never sees the answer (the connection drops, the app is killed mid-request), the retry sends it again, and you get the same bug report twice, in your inbox twice.

The first samples worked around it with a report_id field made on the device, so duplicates could at least be spotted by eye. A reader in r/FlutterDev asked the obvious question: why not let the server drop them? So BootForm now accepts an idempotency key, and both samples send the report's ID as one:

fields["report_id"]?.let { connection.setRequestProperty("Idempotency-Key", it) }

The first request with a key is stored as usual. A repeat answers 200 with "duplicate": true and stores nothing, sends no second notification and doesn't count against the quota. If you build your own queue against any API, make the ID on the device, when the report is saved, not when it's sent: that's what makes every retry carry the same one.

5. Decide what each answer means

"Retry on failure" isn't enough, because some failures will never succeed and some only need part of the report dropped. Each sample has one small, pure function that turns the server's answer into one of four outcomes:

internal fun classify(status: Int, code: String?, hadScreenshot: Boolean): Outcome = when {
    status in 200..299 -> Outcome.Sent
    hadScreenshot && code in SCREENSHOT_REFUSED -> Outcome.DropScreenshot
    status == 408 || status == 429 || status >= 500 -> Outcome.RetryLater
    else -> Outcome.Rejected
}

The server says	The app does
`2xx`	Deletes the report and its screenshot from the device.
The file isn't accepted (plan limit, file too large, form not claimed yet)	Sends the report again without the screenshot.
Too many requests, a `5xx`, a timeout, no network	Keeps it and tries later.
The form is gone or disabled, or the request is invalid	Gives up: sending the same report again would fail the same way.

The "drop the screenshot" row is the one testing proved right. Our first test report, with a screenshot, was refused: the test form hadn't been claimed yet, and an unclaimed form never accepts files (so nobody can use a stranger's form ID as free file storage). The sample sent it again without the image, and it arrived. Without that row the whole report would have been rejected and lost, over an attachment. The same happens on a plan without file uploads, so the text always gets through.

Because classify is pure, it's unit tested without a device. An outside contributor added the remaining cases to both test suites during Hacktoberfest.

6. Screenshots: take them early, shrink them, let the user decide

Take it before the feedback screen opens, so it shows what the user was looking at, not the feedback form.
Shrink it on the device. Android sends a JPEG with its longest side at 1,280 pixels, usually 100 to 400 KB; Flutter sends a PNG of the same size.
Show it, with a checkbox to leave it out. A screenshot can contain anything that was on screen, including personal data.

On BootForm, file uploads start on the Starter plan. On Free the report is still sent, just without the image, because of the rule above.

7. Attach the details nobody types

Users rarely write "Pixel 7, Android 16, version 2.4.1". The samples send it for them, as ordinary fields, so they show up next to the message and in exports:

Field	Example
`app_version`, `app_build`	`2.4.1`, `241`
`os_version`	`Android 16 (API 36)`
`device`	`Google Pixel 7`
`locale`	`en-GB`
`platform`	`android` or `ios`

Locale earns its place quickly: "the text is cut off" is very often a long translation. Add your own fields the same way (the current screen, a user ID, a feature flag): they're just more keys.

8. Be honest: an app can't keep its form ID secret

A website form can be locked to your domain. An app can't: a native app sends no Origin header, so a form used from an app has to allow requests from anywhere. And the form ID ships inside your app, where anyone who unpacks it can read it and post junk straight to the API.

What still protects you: per-IP and per-form rate limits, your monthly quota, and rules that mark matching reports as spam (for example, a message containing http). A CAPTCHA like Turnstile is built for web pages, so it doesn't help here. And the worst case is spam, never a leak: the ID only lets someone send to your form, not read from it. For feedback, that trade-off is usually fine.

Two habits that follow from it:

Use a separate form for app feedback, so a spam wave never mixes with your website's contact form.
Claim the form before you ship. A form ID works before anyone claims it (BootForm holds up to 10 reports for 48 hours), and the first person to claim it owns it. Claim it while you're still developing, and it's yours.

What we haven't tested yet

The Flutter sample on iOS. The code is the same, but we've only run it on Android.
A screenshot accepted on a paid plan, end to end. The refusal path is tested; the success path only by the server's own tests.
A reboot with reports queued. WorkManager's documentation says scheduled work survives one; we haven't checked it ourselves.
A native SwiftUI version waits until it can be built and run on a real Mac.

If you try any of these, an issue on the repo is very welcome.

Try it

Generate your own form ID (any random UUID, for example from our UUID generator) and paste it into the file. Never use one copied from a tutorial, this one included.
Claim it at app.bootform.com/claim/{your-id} with a free account.
Copy the one file for your platform from BootForm/in-app-feedback and add its dependencies: WorkManager on Android, the four packages above on Flutter.
Call it from your own feedback button. The demo apps show a plain screen you can restyle.

The repo is MIT licensed, so the files can go into closed-source apps.

Frequently asked questions

How do I add a feedback form to an Android app without a backend?

Send each report as a multipart POST to a form backend, from a WorkManager job so it survives a bad connection. The Compose sample is one Kotlin file that does this with device info and an optional screenshot.

How do I add a bug report screen to a Flutter app?

Copy bootform_feedback.dart, call BootFormFeedback.send(...) from your screen, and call BootFormFeedback.flush() when the app starts and resumes.

What happens if the user is offline?

The report is saved on the device and sent later: on Android by WorkManager, even with the app closed (unless the user force-stops it); on Flutter the next time the app is opened.

How is this different from a crash reporter?

A crash reporter catches what the app does wrong without the user. A feedback screen catches what the user wants to tell you: a confusing screen, a missing feature, "it's slow on my phone". They work well side by side.

Can I get the reports in Slack, Discord or email?

Yes. That's set on the form in BootForm, so the app code doesn't change.

How to add a contact form to a static website: every option compared

Menelaos Vergis — Wed, 28 Oct 2026 10:35:03 +0000

Originally published on the BootForm blog. I work on BootForm, one of the options compared here.

In short: a static site can't receive a form by itself, so the form posts to a form backend that emails you the message. On any host, BootForm and Web3Forms give the most free submissions, 250 a month. BootForm also includes Cloudflare Turnstile, Discord notifications and an MCP server for AI coding agents on its free plan, and you don't need an account to start. If your site is already on Netlify, Netlify Forms is free with no submission cap. Forminit and Basin accept file uploads for free. Or write a small function yourself, if you want full control and don't mind looking after it.

Every number below comes from each provider's own pricing page or docs, checked on 23 October 2026. Prices change, so check the provider's page before you commit. And yes, we make one of these (BootForm), so we've tried hard to say where each of the others is the better choice.

Why can't a static site send a form by itself?

A static site is a folder of HTML files. Nothing runs on the server when a visitor presses "Send", so there's nowhere for the message to go. That's what makes static sites fast, cheap and hard to break, and it's also the one thing they can't do alone.

The fix is the same in every option here. Your form's action points at someone else's server, which receives the POST, filters out spam, and passes the message on: usually by email, sometimes to Slack, Discord, a webhook or a spreadsheet. The form itself stays plain HTML:

<form action="https://forms.example.com/your-form-id" method="POST">
  <input name="email" type="email" required>
  <textarea name="message" required></textarea>
  <button type="submit">Send</button>
</form>

What differs is how many messages you get for free, how spam is stopped, whether files can be attached, and whether you need an account (or a particular host) before it works.

The comparison at a glance

Free plans first, since that's where most small sites stay:

Option	Free a month	Free forms	Free spam protection	Free uploads	MCP for AI agents	First paid plan
BootForm	250	Unlimited (fair use)	Honeypot, Turnstile, spam folder	No	Yes, every plan	$8/mo, 2,500
Web3Forms	250	Unlimited	Spam filter, hCaptcha, honeypot (Turnstile: paid only)	No	No	$12.42/mo, 10,000
Forminit	100	1	Filters, Turnstile, reCAPTCHA, hCaptcha	100 MB	No	$15.83/mo, 5,000
Formspree	50	Unlimited	ML filter, reCAPTCHA	No	No	$10/mo, 200
Basin	50	1	Filtering, reCAPTCHA, hCaptcha, Turnstile	100 MB	Not yet (rolling out on paid plans)	$12.50/mo, 250
Netlify Forms	No cap (Netlify sites only)	Per site	Akismet, honeypot, reCAPTCHA	8 MB per submission	Netlify's, site-wide	Netlify Personal, $9/mo
Your own function	Up to you	Up to you	Up to you	Up to you	Up to you	About $5 to $25/mo

Paid prices are per month, billed yearly where there is a yearly price, with the submissions a month they include. Turnstile means Cloudflare Turnstile with your own (free) keys. Forminit was formerly called Getform.

Once you outgrow the free plan, the price per message varies a lot more than the headline prices suggest. Here are the first paid plans, cheapest first, paid yearly:

First paid plan	Per month	Included	Cost per 1,000
BootForm Starter	$8.00	2,500	$3.20
Formspree Personal	$10.00	200	$50.00
Web3Forms Pro	$12.42	10,000	$1.24
Basin Starter	$12.50	250	$50.00
Forminit Pro	$15.83	5,000	$3.17

BootForm Starter is the cheapest way to start paying, with more than twelve times the volume of the next cheapest. Web3Forms Pro costs less per message if you need thousands a month.

Netlify isn't in this table because its forms aren't charged per submission at all on its current plans.

BootForm: the most free features, no account needed to start

We make BootForm, so read this section with that in mind.

BootForm's free plan has 250 submissions a month for your whole account, with as many forms as you like. It also includes things the others charge for or leave out:

Cloudflare Turnstile with your own (free) Turnstile keys. On Web3Forms it needs a paid plan.
Discord notifications as well as email. Web3Forms, Forminit and Basin keep chat notifications for paid plans.
A honeypot that's on by default, and a spam folder: rejected messages are kept, not lost. If a form's inbox starts to look like spam, BootForm emails you about it; it never moves a message because of what it says.
A dashboard to search, star and export your messages (CSV or JSON), kept for 30 days in full and six months in all.
Validation rules (required fields, types, lengths) and an IP blocklist, on every plan.

Two more things set it apart. First, nobody else here lets you start without an account: pick your own form ID (any UUID), put it in the form's address, and send a test. Up to 10 submissions are held for 48 hours until you claim the form. Claim it before the page goes public, because whoever claims a form first owns it. Second, the MCP server is built for forms and included on every plan, Free too: if you build your site with Claude Code, Cursor or another AI coding agent, you sign in once in the browser (or create a free account in the same step), and the agent can then create the form, connect your email and read the submissions. There's no API key to copy.

When you outgrow Free, Starter is the cheapest first paid plan here at $8 a month (yearly) for 2,500 submissions, and adds file uploads, Slack, Telegram and webhooks.

Where it's weaker: no file uploads on the free plan, no content filter that reads the message (see spam protection below), and it's newer than the others here.

Pick it if you want the most a free plan gives on any host, to try a form before signing up for anything, or an AI agent is doing the setup. Getting started takes about a minute.

Web3Forms: 250 free a month, email only on the free plan

Web3Forms gives you 250 submissions a month and unlimited forms for free, the same allowance as BootForm, and it works wherever your site is hosted. You sign up with your email, get an access key, and put it in a hidden field. The free plan includes their spam filter, hCaptcha (with a site key they provide) and a honeypot, plus a custom thank-you page and CSV export.

What's paid: Cloudflare Turnstile and reCAPTCHA, webhooks, chat and Sheets integrations, and restricting a form to your own domain all need a paid plan. The cheapest is a yearly-only Starter plan for students, new startups and non-profits, by application, which includes all of those but only one active integration. File uploads, autoresponders and the submissions API need Pro, at $149 a year, which is also the cheapest per message in this comparison by a wide margin. One thing to check for yourself: their FAQ says "We do not store any form submissions of our users", while their pricing page lists 30 days of submission history on the free plan.

Pick it if email is all you need and hCaptcha is enough for spam, or you expect thousands of messages a month: its Pro plan is the cheapest per message here.

Netlify Forms: the easy answer if you're already on Netlify

Netlify Forms is free with no submission cap on Netlify's current credit-based plans. Its billing FAQ says it plainly: "Form usage is free and unlimited." You turn on form detection in the Netlify dashboard, add a data-netlify="true" attribute to your form, deploy, and Netlify finds the form in your HTML at build time. Every submission goes through Akismet, a proper content-based spam filter, and you can add a honeypot or reCAPTCHA on top.

The catch is in the same sentence: it only works for sites deployed on Netlify, because the form is detected during Netlify's build. A form your JavaScript renders after the page loads needs a hidden static copy so the build can find it. And if your team runs out of Netlify credits, Netlify pauses your projects, and a paused project "will not receive new web requests, web traffic, or form submissions." The form goes down with the site.

Pick it if your site is already on Netlify and you don't need much beyond email notifications.

Forminit (formerly Getform): file uploads on the free plan

Forminit is Getform under a new name, and it says so: "the same independent form-backend service operating since 2015." Its free plan is 100 submissions a month on a single form, and it's one of only two options here that accept file uploads for free, with 100 MB of storage. Free submissions are kept until you delete them, rather than for a fixed window.

Webhooks, Slack, Zapier, Google Sheets, Discord notifications, autoresponders and the REST API start on Pro, at $190 a year for 5,000 submissions a month. For spam, its docs cover a honeypot and your own Turnstile, reCAPTCHA or hCaptcha keys, which Forminit checks on its server, and the pricing page doesn't limit any of them to a paid plan.

Pick it if visitors need to attach a file and you only need one form.

Formspree: the long-established choice

Formspree is the name most tutorials use, and it has a long list of integrations. The free plan is 50 submissions a month with unlimited forms and a 30-day archive. It includes Formshield, its machine-learning spam filter, and your own reCAPTCHA. Unusually, Slack, Discord, Telegram and WhatsApp notifications are free too.

The limits show up quickly. Personal is $120 a year for 200 submissions a month, which works out to $50 per 1,000. Webhooks, Zapier, autoresponders and API access start on Professional ($240 a year), and a custom honeypot or your own spam rules need Business ($720 a year).

Pick it if you need a specific integration only Formspree has, or chat notifications on a low-volume form.

Basin: Zapier and uploads on the free plan

Basin's free plan has 50 submissions a month on one form, with 30 days of history, basic spam filtering, 100 MB of file uploads and, unusually, Zapier. reCAPTCHA, hCaptcha and Turnstile are all included on every plan, free too, the widest CAPTCHA choice here; a custom honeypot and the duplicate filter start on Growth. Every paid plan comes with a 14-day free trial.

Paid plans step up gradually: Starter at $12.50 a month (yearly) for 250 submissions and 3 forms, Growth at $24.17 a month for 1,000 submissions with webhooks, Slack and autoresponders.

Pick it if you want Zapier or file uploads without paying, at low volume.

Should you build your own form handler?

You can, and at small volume it's nearly free. A Cloudflare Worker handles 100,000 requests a day on its free plan, and Resend sends 3,000 emails a month (100 a day) for free. About thirty lines of code connect the two:

// A Cloudflare Worker that emails each form submission through Resend.
export default {
  async fetch(request, env) {
    if (request.method !== "POST") return new Response("Not found", { status: 404 });

    const form = await request.formData();
    if (form.get("website")) return new Response("Thanks!"); // honeypot: bots fill it, people don't

    const email = form.get("email");
    const message = form.get("message");
    if (!email || !message) return new Response("Please fill in every field.", { status: 400 });

    const sent = await fetch("https://api.resend.com/emails", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${env.RESEND_API_KEY}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        from: "Contact form <form@your-domain.com>",
        to: "you@your-domain.com",
        reply_to: email,
        subject: "New message from your website",
        text: message,
      }),
    });

    if (!sent.ok) return new Response("Sorry, that didn't send. Please try again.", { status: 502 });
    return Response.redirect(env.THANK_YOU_URL, 303); // a full URL, e.g. https://your-domain.com/thanks
  },
};

That works, but look at what it leaves out. There's no record of messages, so if an email is lost, so is the message. A failed send isn't retried. The honeypot is the only spam protection; adding Turnstile means verifying its token on the server too. There's no limit on how often one visitor can post. And you have to verify a sending domain with Resend, keep the API key secret, and notice when something breaks. None of that is hard on its own. Together it's the work a form backend does for you.

Pick it if you enjoy this kind of thing, need something no service offers, or must keep every message on infrastructure you control.

How do the spam protections compare?

Spam is where free plans differ most. There are three kinds of protection, and they stop different bots:

A honeypot is a hidden field that people never see and many bots fill in. It costs visitors nothing and stops most of the cheap bots. Every option here supports one, though Formspree only lets you set your own on Business, and Basin from Growth.
A CAPTCHA (Turnstile, hCaptcha, reCAPTCHA) asks the browser to prove it's a person, usually without a puzzle. It stops bots that post straight to your form's address. Turnstile is free from Cloudflare; whether you can use it on a free plan depends on the provider (BootForm, Basin and Forminit: yes; Web3Forms: paid plans only).
A content filter (Netlify's Akismet, Formspree's Formshield) reads the message and scores it. It catches spam a person typed by hand, which the other two can't. The trade-off is the occasional real message marked as spam, so check the spam folder now and then.

Start with a honeypot. If bots still get through, add a CAPTCHA. Our spam protection guide walks through both on BootForm.

Which one should you choose?

You want the most free messages and features, on any host: BootForm (Web3Forms matches its 250 a month, without free Turnstile or Discord).
You want to try it before signing up, or an AI agent is building your site: BootForm.
You expect thousands of messages a month: Web3Forms Pro is the cheapest per message.
Visitors need to attach files, and you won't pay: Forminit or Basin.
Your site is on Netlify: Netlify Forms.
You need a particular integration: Formspree probably has it.
You want to own everything: a small function and an email API.

Whichever you choose, the HTML is nearly the same, so switching later is mostly a matter of changing the form's action and the name of the hidden field.

Frequently asked questions

Can I add a contact form to GitHub Pages?

Yes. GitHub Pages only serves static files, so the form posts to an outside form backend, any of the services above except Netlify Forms, which needs Netlify hosting. Our free website guide builds a GitHub Pages site with a working form from start to finish.

Is there a free form backend with no limits?

Netlify Forms has no submission cap on Netlify's current plans, but only for sites hosted on Netlify. Elsewhere, every free plan has a monthly limit: 250 on BootForm and Web3Forms, 100 on Forminit and 50 on Formspree and Basin, as of October 2026.

Do I need JavaScript for a contact form?

No. A plain HTML form with method="POST" works with every option here. JavaScript only comes in if you want to send the form without leaving the page, or to show a CAPTCHA widget.

Which form backend works with an AI coding agent?

Any of them, if the agent writes the HTML and you create the form by hand. For the agent to set the form up itself, the backend needs an MCP server. BootForm's is included on every plan, Free too: after one browser sign-in, the agent creates the form, connects your email and checks for messages. Basin lists one for its paid plans, but says it's still rolling it out, and Netlify's covers forms along with the rest of a Netlify site.

Is my form's address a secret?

Not really: it's in your page's HTML for anyone to read. That's why spam protection matters, and why the providers that offer it let you restrict a form to your own domain.

Where to go next

If you'd like to try BootForm, getting started takes about a minute, and you don't need an account until you want to read your messages. There are step-by-step guides for plain HTML and JavaScript, Jekyll, React, Vue and Angular. Starting a site from scratch? The free website guide gets you a blog with a working contact form on GitHub Pages in about fifteen minutes.

A fast website with a blog, search and a contact form, hosted free

Menelaos Vergis — Sun, 18 Oct 2026 08:17:59 +0000

Originally published on the BootForm blog. I work on BootForm, the form backend used in step 4; the templates are free and MIT licensed.

In short: copy the free vitepress-blog template on GitHub, edit it in the browser, and GitHub Pages publishes it at no cost. You get a blog with tags, search and an RSS feed, plus a contact form whose messages BootForm emails to you on its free plan. It takes about fifteen minutes and nothing to install.

You can have a website with a blog, tags, full-text search, an RSS feed and a contact form that actually sends you the messages, without paying for hosting and without installing anything. This post walks through it start to finish, in the browser.

What you end up with

A blog with a post list, tag pages and an RSS feed, all generated from a folder of text files.
Search across every post, running in the visitor's browser.
A contact page whose messages land in your inbox and in a dashboard.
A live address like https://yourname.github.io/vitepress-blog/, served by GitHub Pages.

Search is built in. Press / or Ctrl K on any page and start typing:

Here is the finished example, if you want to click around before you start.

Is a static site enough for a blog?

For most blogs, yes. A static site is a folder of pre-built HTML files with no server or database behind it, so there is nothing to patch, nothing to break into, and every page loads as fast as a plain HTML file. That is also why it can be hosted for free.

The one thing a static site cannot do by itself is receive a form, because there is no server to send it to. A form backend fills that gap: the form posts to the backend's address, and the backend emails each message on to you. That is the part BootForm does here, on its free plan.

When a static site is the wrong choice: if you sell products, need customer logins, or the person updating the site will never touch a text file, use a shop platform or a CMS instead. A static blog suits people who are happy to write a post as a file.

Two templates, pick one

Both are free, open source (MIT), and ship with a working contact form.

	first-website	vitepress-blog
What it is	One page, plain HTML	A full blog built with VitePress
Blog, tags, RSS, search	No	Yes
Setup	Browser only, about 15 minutes	Browser only (or locally with Node.js)
Good for	Your first page on the internet	A site you will keep adding posts to

The rest of this post builds vitepress-blog. If one page is all you need, first-website's README walks you through the same steps for a single page.

Step 1: Make your own copy

Open github.com/BootForm/vitepress-blog, click Use this template, then Create a new repository. Keep the name vitepress-blog and make it public.

Keeping the name saves you a step. If you rename it, the README's Step 1 lists the two lines to change to match.

Step 2: Turn on GitHub Pages

In your new repository, go to Settings, then Pages, and set Source to GitHub Actions. From now on, every change you save builds the site and publishes it by itself. The template already includes the workflow that does this.

Step 3: Make it yours, in the browser

On your repository's main page, press the full-stop key (.). GitHub opens github.dev, a full code editor in the browser.

Look for CHANGE ME. The places that matter:

docs/.vitepress/config.mts: the blog's title and description.
docs/index.md: the home page text.
docs/.vitepress/theme/style.css: your brand colour.
docs/.vitepress/authors.ts: your name, instead of the example authors.
scripts/generate-rss.mjs: SITE_URL. Put your own GitHub username in place of yourname, otherwise the feed's links point at someone else's address.

Every post is a Markdown file in docs/posts/. The top of each one says its title, date, author and tags:

---
layout: page
title: Your post title
date: 2026-10-15
author: priya
tags: [some-tag, another-tag]
---

To write a new post, copy one of the example files and change it. The post list, the tag pages, the RSS feed and the search index all rebuild from whatever is in that folder, so there is no other file to update.

Don't commit yet. The contact form goes in the same commit.

Step 4: Connect the contact form

The contact page (docs/contact.md) is already built. It just needs somewhere to send messages.

Open BootForm's UUID generator and copy the ID it gives you. That ID is your form. There is nothing to sign up for yet.
In docs/contact.md, find __YOUR_FORM_ID__ in the form's action and paste your ID over it.

A BootForm form ID is a UUID you generate yourself. Pasting it into a form's action makes the form work straight away, and the first person to claim the ID receives everything sent to it. So use the ID that was generated for you, never one you saw in a tutorial (this one included).

Leave the hidden honeypot field in the form alone. It is BootForm's spam trap: bots fill it in, people never see it, and while the honeypot is on (it is by default), a submission without it is treated as spam. More in Spam protection.

Now open the Source Control panel on the left, write a message such as "Make it mine", and click Commit & Push.

Step 5: Go live and send yourself a message

Open the Actions tab of your repository. The deploy run takes about a minute; when it turns green, your site is at https://yourname.github.io/vitepress-blog/.

Open the contact page, fill it in and press Send. Because nobody owns this form yet, BootForm holds the message and shows you a page offering to claim the form. Create a free account there (signing up with GitHub is quickest) and the form is yours: the waiting message shows up in your dashboard, and new messages are emailed to the address you signed up with.

Until it is claimed, a form holds up to 10 messages for 48 hours, so claim it before you share the site.

How much does it cost?

Nothing, for a blog like this one. GitHub Pages hosts a public repository's site for free, within soft limits of 1 GB per site and 100 GB of bandwidth a month. BootForm's free plan adds the contact form, with 250 submissions a month, unlimited forms, email and Discord notifications, and spam protection. See pricing for the paid plans.

A custom domain is optional. The site works on its github.io address; your own domain costs whatever your registrar charges, and Setting up your computer covers pointing it at GitHub Pages.

One thing worth knowing: GitHub's own documentation says Pages is not meant to run an online business, an e-commerce site or software as a service. A personal blog, a portfolio or a small business's information site is the kind of thing it is for.

Frequently asked questions

Is GitHub Pages really free?

Yes, for a public repository. GitHub's published limits are 1 GB per site and a soft limit of 100 GB of bandwidth a month, which is far more than a small blog uses.

Can a static site have a working contact form?

Yes. The form posts to a form backend instead of your own server. With BootForm you point the form's action at https://f.bootform.com/ followed by your form ID, and each message is emailed to you and kept in a dashboard.

Do I need to install anything?

No. Everything in this post happens in the browser: GitHub's web pages and the github.dev editor. GitHub Actions builds the site for you. You can still run it on your own computer with Node.js if you prefer.

What happens to messages before I sign up?

BootForm holds up to 10 messages for 48 hours on a form nobody has claimed yet. Claim the form with a free account and they are delivered to you; after 48 hours unclaimed, they are deleted.

Can I use my own domain?

Yes. GitHub Pages supports custom domains with free HTTPS. You buy the domain from any registrar and point it at GitHub; Setting up your computer walks through it.

Where to go next

Add more to the pages. site-sections has 27 copy-paste sections (heroes, pricing, FAQs, footers) written to work inside these templates.
Let an AI agent do the editing. Each template ships with an AGENTS.md, and the Claude Code plugins can add sections, new kinds of content and a theme for you.
More templates. Starter templates lists the rest, including a one-page business site that ends on your own domain.
Using another site builder? The Jekyll, Vue and plain HTML guides show the same form in each.

Start with the template: the whole thing takes about fifteen minutes.