Best tech stack for a small business website

The website of a bakery, an accounting firm or a clinic has a simple job: show what the business does, where it is, when it is open and how to get in touch. Even so, it is common to see small businesses running stacks far too heavy for that, which end up slow, outdated and expensive to maintain.

The right choice starts from what the business needs, not from what is trendy. The answer is usually a smaller stack than you would expect, plus a few pieces every site needs: a domain, HTTPS, contact links and analytics.

What does a small business website actually need?#

Almost every local business needs the same things:

• A few pages: home, services or menu, about, contact. Sometimes a blog.
• Direct contact: a click-to-call phone number, a chat button, email and an address with a map.
• Work well on phones, where most local search visits come from.
• Load fast and use HTTPS. See what SSL/TLS is.
• Its own domain, which builds trust and does not tie you to any website vendor.
• Data Google understands: name, address, phone number and opening hours marked up with structured data.

Customer logins, a shopping cart, bookings and an admin area are the exceptions. If your case has none of them, the stack can be very simple.

Which criteria should you use to choose a stack?#

1. Who will edit the content, and how often? If the owner changes the opening hours twice a year, editing a file is enough. If the team publishes posts every week, an editing dashboard helps.
2. Is there dynamic functionality? Orders, reservations and customer accounts need a server and a database. A contact form on its own does not.
3. How much maintenance will you accept? Every server, plugin and database is something to update. Fewer pieces means fewer security holes.
4. Performance and search. Light pages and ready-made HTML help the site load fast on phones.
5. Total cost. Add up hosting, domain, paid plugins or themes and the hours of whoever maintains it. See how much it costs to host a website.

What are the options?#

Hand-written static site#

HTML and CSS written directly and published as files. No application server, no database, no plugins. Pros: the fastest, the safest, minimal cost. Cons: editing means touching the code, and repeating the header and footer across pages gets tedious. See what a static site is.

Static site generator (Astro, Hugo, Eleventy)#

You write pages in Markdown or components, and the generator produces static HTML at build time. With Astro, a project starts with npm create astro@latest. Pros: the speed and safety of static, with reusable layouts and a Markdown blog. Cons: someone needs to know how to run the build and publish. The difference between rendering modes is in SSR vs SSG vs static.

WordPress#

A PHP CMS with a MySQL or MariaDB database, an editing dashboard, themes and thousands of plugins. The official documentation recommends running the newest PHP version whenever possible, with a still-supported version of MySQL or MariaDB, and HTTPS support. Pros: anyone can edit through the dashboard, and there is a plugin for almost everything, including a store. Cons: core, theme and plugins need constant updates, the database needs backups and many plugins slow the site down.

Site builder (Wix, WordPress.com and similar)#

A visual editor, templates and hosting in one service, billed monthly. Pros: no code, no server, online the same day. Cons: you accept the tool's limits, the monthly cost grows with extra features and leaving usually means rebuilding the site.

Full-stack framework (Next.js, Laravel, Django)#

An application with a server, routes and a database. Pros: it can do anything: orders, bookings, a customer area. Cons: it is software to develop and maintain. For a brochure site, it is more than the problem asks for. See the difference in web hosting vs app hosting.

How do the options compare?#

Which stack should you pick for each scenario?#

• Restaurant, salon, repair shop, service provider: a static site or generator, with a chat or call button, a map and structured data. This is the most common case.
• Office or practice that publishes articles every week: WordPress, or a static generator with a Markdown blog if the writers know Git.
• Small shop with few products: start with a static catalog that takes orders by message or phone. When volume justifies it, move to a store with a cart and payments.
• Bookings, a customer area or a custom system: a full-stack framework with a database. See how to host a website for the steps.
• Nobody at the company handles tech and there is no budget for someone who does: a site builder is an honest choice, as long as you know leaving it is costly.

Which pieces complete any stack?#

Domain and DNS. Buy the domain in your own name from a registrar and point the DNS records to your host. See how to use a custom domain.

Contact and structured data. Make the phone number clickable with tel:, and if your customers use WhatsApp, a wa.me link opens a chat with a prefilled message (the number goes with the country code and no + or dashes, and the text must be URL-encoded). Alongside, mark up the business details with the schema.org LocalBusiness type, whose required fields for Google are name and address:

<section id="contact">
  <h2>Get in touch</h2>
  <!-- Replace with your number: country code + area code + number -->
  <a href="https://wa.me/15125550100?text=Hi!%20I%20found%20you%20on%20your%20website%20and%20would%20like%20a%20quote.">Chat on WhatsApp</a>
  <a href="tel:+15125550100">(512) 555-0100</a>
  <a href="mailto:hello@example.com">hello@example.com</a>
</section>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Bakery",
  "name": "Example Bakery",
  "url": "https://www.example.com",
  "telephone": "+1 512 555 0100",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "100 Example St",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78701",
    "addressCountry": "US"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"],
      "opens": "06:00",
      "closes": "20:00"
    }
  ]
}
</script>

Bakery is a subtype of LocalBusiness; use the most specific type that exists for your business. After publishing, check the page with Google's Rich Results Test.

Business email. Email on your own domain is a separate service from the website, set up with MX records in DNS.

Analytics. Analytics tools that use tracking cookies may require a consent banner under privacy laws such as the GDPR or Brazil's LGPD. Cookieless analytics removes part of that friction when you only want to know how many people visit and where they come from.

How to do this on Square Cloud#

Square Cloud is self-service hosting: you publish the site and stay in control. For the most common stack in this article, use the static sites runtime: upload the ready-made HTML (or the folder built by Astro, Hugo or Eleventy) as a ZIP in the dashboard, with the CLI or from GitHub. On that runtime nginx is always online serving the files, and every update goes live right away. If the site has a server, there are several runtimes, such as Node.js, PHP and Python; see the runtimes available today on Runtimes.

Every web application gets an HTTPS *.squareweb.app subdomain on every plan, and a web application uses at least 512 MB of the plan's RAM pool. A custom domain starts on Standard, from R$44.99 per month: you create the DNS records shown in the dashboard at your registrar, follow the validation in real time and TLS is issued automatically. The domain stays in your name, at your registrar.

Every plan includes cookieless web analytics, collected on the server, with visits, routes, countries and status codes. See more on the Sites page.