This is Part 2 of a two-part series. Part 1 covers why static sites are the right choice for most small businesses in 2026 - the performance, security, and cost arguments. If you haven’t read it yet, start there first. This article picks up where that one left off: the practical how-to.
The most common pushback we get when pitching a static site to a small business is some version of: “But we need a contact form.” Or a booking system. Or a way to take payments. Or a search bar.
These aren’t unreasonable things to ask for. They’re the basic requirements of almost every business website. And they’re the reason a lot of people default to WordPress - because the assumption is that these features need a database and a server to run.
They don’t. Every feature a typical small business website needs can be delivered on a static site. This is the playbook for how.
If you haven’t read why we think static sites are the right call for most small businesses in 2026, that’s the context for this article. This one is the practical how-to.
Contact Forms
This is the objection we hear most. “A static site can’t send an email.”
Technically correct. A static site can’t process a form submission server-side. But what it can do is send that form data to an API endpoint that handles the email delivery - and from the user’s perspective, the experience is identical.
The way this works in practice: the form submits via a JavaScript fetch() call to a third-party endpoint. That endpoint receives the data, sends an email to the business owner (“you have a new enquiry”), sends a confirmation to the person who submitted (“thanks, we’ll be in touch”), and returns a success response. No server. No PHP. No hosting configuration.
Tools like Formspree and Web3Forms solve this out of the box and have free tiers that cover most small business volumes. We started with EmailJS on our own site - it does the same job and works well as a starting point.
Over time, we built our own lightweight form handler for client sites. It works exactly the same way as these services - script tag in the page, data attributes on the form, done - but we own it, which means our clients aren’t exposed to third-party pricing changes or service outages. For agencies building at volume, that kind of ownership makes sense. For most small business sites, EmailJS or Formspree gets the job done without any additional infrastructure.
Booking and Appointment Systems
Tradies, mechanics, physios, beauty therapists, consultants - a large proportion of small business enquiries are really appointment requests. This feels like a backend problem. It isn’t.
Every major booking and scheduling platform provides an embed code. That embed code - a script tag or an iframe - loads their booking calendar directly inside your page. The platform handles availability, confirmations, reminders, payments, and cancellations. Your static site just provides the container.
The important point: that embed code works identically on a static site as it does on WordPress, Wix, or any other platform. The booking system is a third-party application. It doesn’t care what your site is built on.
If your client is already using a booking tool they like, it drops straight in. If they’re starting fresh, the choice of platform is independent of the choice to go static.
Payments
For businesses selling fixed-price services - a maintenance plan, a consultation package, a deposit on a project - Stripe is the cleanest solution. Stripe Payment Links give you a hosted checkout page with a unique URL. Embed a buy button on your static page, user clicks it, they complete payment on Stripe’s servers, done.
For Australian businesses, the question of Afterpay, Zip, and other buy-now-pay-later options comes up regularly. Both are supported through Stripe. When you enable Stripe Checkout, you can activate Afterpay and Zip as additional payment methods - your customer sees them at checkout alongside card payment options. You don’t need separate Afterpay or Zip integrations. One Stripe implementation covers all of them.
The important caveat: direct Afterpay and Zip JavaScript integrations - the kind you’d find in their developer documentation for building a custom checkout - typically require a server-side component to create the order before the payment widget renders. Going through Stripe Checkout sidesteps this entirely and keeps the implementation static-site compatible.
For businesses with complex product catalogues, variants, inventory management, and fulfilment workflows, Shopify earns its cost. But for most service businesses and simple product sellers, Stripe is cheaper, faster, and has no platform fees beyond the payment processing rate.
Email Capture and Marketing
Every major email marketing platform - Mailchimp, ActiveCampaign, Klaviyo, ConvertKit - provides an embeddable signup form. These are, again, script tags. They work on static sites without modification.
The form submits directly to the platform’s API. The subscriber lands in your list. Automated follow-up sequences fire. None of this requires your site to do anything beyond render the form.
The same form handler we use for contact forms can double as a lead capture endpoint that routes to a CRM or mailing list - so for clients who want a custom-styled form rather than an embedded Mailchimp widget, that’s the path.
Site Search
Most small business sites don’t need search. But for sites with large blog archives or resource libraries, it’s a legitimate requirement.
Pagefind is our solution of choice. It runs at build time - when the site compiles, Pagefind indexes every page and generates a set of static search files. At runtime, the search runs entirely in the browser against those pre-built files. No API calls. No search server. No cost per query.
The search index is just files. It lives on the same CDN as everything else. For small business sites, the performance is excellent and the implementation cost is minimal.
Content Updates Without a CMS
This is the one that feels like a bigger problem than it is - and it’s something we covered in detail in the static sites article.
The short version: updating a static site in 2026 doesn’t require a CMS login. Content changes come in as a brief email description. We implement them using AI tools, review the output, and deploy. Most requests are live same-day.
For clients who specifically want a visual editor, git-based CMS options like Keystatic and Tina CMS sit on top of a static site and let non-technical users edit content through a web interface. The site is still static. The CMS is just an editing layer that writes to the source files.
When Static Sites Don’t Work
It’s worth being honest about the ceiling.
Membership sites with gated content and user accounts require real authentication. Static sites can integrate third-party auth tools (Clerk, Auth0) for simple use cases, but complex member portals belong on a dedicated platform.
Heavy eCommerce - hundreds of products with variants, real-time inventory, abandoned cart recovery, fulfilment integrations - is where Shopify earns its place. Trying to replicate that on a static site is the wrong approach.
Real-time features - live chat that requires a persistent connection, real-time dashboards, collaborative tools - need a backend. These aren’t small business website features; they’re application features.
For anything outside these categories - which covers the vast majority of small business websites - the static approach works, performs better, costs less to host, and has a smaller attack surface than the WordPress equivalent.
The “but we need [feature]” conversation almost always has an answer that doesn’t require a PHP server. Knowing those answers is what makes the pitch work.
Frequently Asked Questions
Can you run a blog on a static site?
Yes - in fact, a blog is one of the simplest things a static site does well. Every post is just another pre-built page, generated automatically from your content at build time. This site’s own blog runs exactly this way.
Does live chat work on a static site?
Basic live chat widgets do - tools like Tawk.to, Crisp, or Intercom load via a script tag, the same way booking and payment embeds do, so they work identically on a static site. What doesn’t fit is a fully custom, self-hosted chat system requiring a persistent server connection - that’s genuinely a backend feature.
Can a static site have a members-only or gated area?
For simple cases, yes - third-party authentication tools like Clerk or Auth0 handle login and access control without needing your own server. For a small number of gated pages or a simple client portal, this works well. A complex membership platform with tiered access and its own database of user accounts belongs on a dedicated platform instead.
Do static site forms still work if a visitor has JavaScript disabled?
No - since the form submission relies on a JavaScript fetch() call to reach the third-party endpoint, a visitor with JavaScript disabled won’t be able to submit it. In practice this affects a vanishingly small number of visitors in 2026, but it’s a genuine limitation worth knowing about rather than pretending it doesn’t exist.
If you’re building client sites or thinking about making the move to static, get in touch - we’re happy to talk through how the stack works in practice.
Photo by Christopher Gower on Unsplash
