Web development is the technical build behind a website: the code, the integrations, the forms, the hosting and the security. We hand-code small business sites in PHP, HTML, CSS and plain JavaScript, connect the booking, ordering and payment services you already use, and set up your domain, SSL and email authentication so everything keeps working after launch.
What We Build With, and Why It Stays Simple
Our toolkit is intentionally small. PHP runs on the server and handles shared page parts, form processing and the few things that need to change on the fly. HTML carries the content in a structure that validates. CSS is written for the specific site rather than pulled from a utility framework with thousands of unused classes. Plain JavaScript handles the handful of interactive pieces a business site actually needs: the mobile menu, accordions, form checks and click-to-load embeds.
That combination runs on ordinary, affordable hosting, has no build pipeline to break and no dependency tree to audit every month. A well-written PHP and HTML site can run for years with little more than keeping the PHP version current on the server. Every page arrives as finished HTML, so a phone, a search crawler or an AI assistant can read the content before a single script runs.
Why We Skip Heavy Frameworks for Small Business Sites
React, Vue, Next.js and similar frameworks are excellent tools for web applications: dashboards, logged-in portals, tools people use for hours a day. A small business website is a different kind of thing. It is mostly documents: what you do, what it costs, when you are open, where you are and how to reach you.
Rendering that kind of content through a JavaScript framework adds download weight to every page, a build process that someone has to maintain, and a long list of packages that need security updates. When a package is deprecated or a build tool changes, a site that has not been touched in two years can suddenly refuse to rebuild. On a mid-range phone with a weak signal at the beach, the extra script is also the difference between a page that appears right away and one that shows a blank screen for a moment too long. For a restaurant, a contractor or a charter captain, none of that buys anything the customer will notice.
Being clear about scope matters too. We do not build native iPhone or Android apps, and we do not build custom e-commerce platforms or large online stores. If your business needs those, a dedicated app developer or store platform is the right tool, and we will gladly link it from the site we build. For a few products, deposits or gift cards, a payment provider's hosted checkout usually does the job.
Integrations: Connecting the Services You Already Use
Most coastal businesses already pay for at least one outside service: a booking calendar, an ordering platform, a reservation book, a payment processor. Our job is to connect those cleanly, not to replace them with something custom you would have to maintain.
Booking and scheduling widgets
We link or embed the scheduling service you already use, place it where customers look for it and give the button a clear label such as "Book a Lesson" rather than a vague "Go." Booking widgets are often heavy, so we load them only on the page that needs them, or only when someone taps the button, which keeps the rest of the site quick. We test the full path on a phone, and we put a phone number next to every widget for anyone who would rather call.
Online ordering and reservations
For restaurants and cafes, the ordering or reservation provider owns the checkout; we make sure customers reach it in one tap. That means deep links that go straight to your store or booking page instead of the provider's home page, buttons that appear in the header on mobile, and separate links for each location when you have more than one.
Google Business Profile
Your website and your Business Profile should tell the same story: the same business name, address, phone number and hours. We match the site's structured data to what the profile says, link to the profile so customers can read and leave reviews, and set the profile's website link to the right page. Our local SEO service covers the profile itself in much more depth.
Maps as click-to-load facades
A standard embedded map pulls in a large bundle of third-party code the moment a page loads, whether or not anyone looks at it. We replace it with a facade: a lightweight preview of your address with a button to load the interactive map and a link for directions. Google's Lighthouse documentation describes a facade as a static element that looks like the embed but is much less taxing on the page load (opens in a new tab), swapped for the real thing when someone interacts. A side benefit is privacy: the map provider is not contacted until the visitor asks for the map. We use the same approach for video players.
Payments through hosted checkouts
When you need to take a deposit, sell a gift card or collect an invoice payment, we connect a payment provider's hosted checkout or payment link instead of building a card form on your server. The customer types card details on the provider's secure page. Stripe's integration security guide (opens in a new tab) explains that its lower-risk integrations send payment information directly to Stripe without it passing through your servers, which reduces your PCI compliance obligations. Square and PayPal offer similar hosted options. Card numbers never touch your website, and that is exactly how we want it.
Contact Forms That Stop Spam Without Punishing People
Picture-puzzle CAPTCHAs cost real leads. Some customers simply give up, and the W3C's note on the inaccessibility of CAPTCHA (opens in a new tab) explains that the puzzles inherently exclude many people with disabilities. We stop spam with layers that a person never notices:
- Honeypot fields: inputs hidden from people but filled in by bots that complete every field they find.
- A timing check: forms submitted faster than any human could type are set aside.
- A browser token: a value set by JavaScript on the page and verified by the server, which most automated scripts never produce.
- Server-side validation: every field checked for length and format on the server, not only in the browser.
- Plain-language errors: when a real person makes a mistake, the message says which field and how to fix it.
The second half of a good form is what happens after a successful submission. Every lead is written to a log file on your server first, and only then is the notification email sent. If the mail server has a bad day, the inquiry is still sitting in the log. With SimpleCMS you can open a Leads view in your browser to read every submission and delete old ones. Email is a delivery method, not the place your leads live.
SimpleCMS: Self-Editing Without a Database
AldoMedia SimpleCMS is Aldo's own content editor, and it works differently from most. There is no database behind it. You log in from a browser and edit text, photos, galleries and PDFs, manage repeating cards such as staff bios or menu items, and view contact-form leads. Because the site is made of plain files, it backs up as plain files, and there is no database server to patch or tune. It is optional on every site we build.
Hosting, SSL and DNS in Plain English
Three things often get confused, and the confusion causes most launch-day emergencies. The registrar is where you rent your domain name each year. DNS is the address book that tells the internet where your website and your email live. Hosting is the server that stores and delivers the site's files. Your email may sit with yet another company, such as Google Workspace or Microsoft 365. We write down who holds each piece, so you are never locked out of your own business.
Every site we launch runs on HTTPS with a certificate that renews automatically, and plain HTTP requests are redirected to it. We pick one official version of your address, with or without www, and redirect the other. We also send the Strict-Transport-Security header (opens in a new tab), which tells browsers to use HTTPS for every future visit. Before any DNS change we lower the record's time to live a day ahead, so the switch takes effect quickly, and we copy the mail records exactly so email keeps flowing.
Email Authentication: SPF, DKIM and DMARC
Your contact form sends email, your staff send email, and your booking system probably sends confirmations. Mailbox providers check whether mail that claims to come from your domain is actually allowed to. Three DNS records answer that question:
- SPF lists the servers that are permitted to send mail for your domain.
- DKIM adds a digital signature to outgoing messages, with a matching public key published in your DNS, so receivers can confirm the message is genuine and unaltered.
- DMARC tells receiving servers what to do when a message fails those checks, and where to send reports about it.
Gmail's email sender guidelines (opens in a new tab) require everyone who sends to Gmail accounts to set up SPF or DKIM, and require senders of 5,000 or more messages a day to have SPF, DKIM and DMARC. Most small businesses are nowhere near that volume, but properly authenticated mail is simply more likely to reach the inbox. We set up all three for your domain, start DMARC in monitoring mode and tighten it once the reports show every legitimate sender is covered.
Security Headers That Do Real Work
Security headers are short instructions your server sends with every page, telling the browser how to treat it. The OWASP Secure Headers Project (opens in a new tab) documents them in detail. On a typical site we configure:
- Strict-Transport-Security for HTTPS only
- Content-Security-Policy listing trusted sources
- frame-ancestors to block clickjacking
- X-Content-Type-Options set to nosniff
- Referrer-Policy to limit what leaks to other sites
- Permissions-Policy to switch off unused features
Content Security Policy is the most valuable and the most fiddly. MDN describes it (opens in a new tab) as a way to help prevent cross-site scripting by restricting the resources, particularly JavaScript, that a page may load. Every integration needs its own entries, so when we add a booking widget or a payment provider, we add exactly the sources that provider documents and nothing more. A hand-coded site makes this practical, because we know every script on every page.
Replacing an Old Website Without Losing What It Earned
An old site may look tired, but its URLs have collected links, bookmarks and search visibility over the years. Google recommends permanent server-side redirects (opens in a new tab) as the best way to send both people and Google to a page's new address, and its site move guide (opens in a new tab) advises keeping redirects for as long as possible, generally at least a year. This is how we handle it:
Inventory every old URL
We collect addresses from the old sitemap, Google Search Console, analytics and known backlinks, including PDFs and image pages people link to.
Map each one to its best match
Each old address points to the most relevant new page. A visitor looking for pool cage repair lands on that service, not on the home page.
Write permanent redirects on the server
The map becomes 301 rules in the server configuration, tested before launch on a staging copy.
Launch and test every redirect
On launch day we run the full list against the live site and confirm each one returns a single hop to a working page.
Update the links you control
Your Google Business Profile, social profiles and directory listings are pointed at the new URLs directly.
Watch for stragglers
For the following weeks we check Search Console for not-found errors and add redirects for anything the inventory missed.
Plain-English tip: if a designer suggests sending every old page to your home page, ask why. It is quicker for them and worse for you, because visitors lose the page they were looking for.
Maintenance After Launch
A hand-coded site has far fewer moving parts than a plugin-driven one, but it is not maintenance-free. Hosts retire old PHP versions, so we test and upgrade when needed. Certificates renew automatically, and we confirm they did. Booking and ordering providers change their embed codes from time to time, and the security policy has to follow. Content changes as your menu, prices and staff change. We also rerun Lighthouse and our AldoMedia Ultimate Website Scanner periodically, which catches drift in performance, accessibility and security headers before customers notice it. You can hand all of that to us, or handle content yourself with SimpleCMS and call us for the rest.
Frequently Asked Questions
Why do my contact form emails land in spam?
The most common cause is missing or broken email authentication. If your domain has no SPF, DKIM or DMARC records, or the form sends through a server those records do not authorize, mailbox providers treat the message as suspicious. We fix the records and send form mail through an authorized route.
Can you connect the booking or ordering system I already use?
Usually, yes. Most booking, reservation and online ordering services provide a link or an embed code. We place it where customers expect it, load it only where it is needed so other pages stay fast, and test the whole path on a phone before launch.
Do you build mobile apps or online stores?
No. We build fast, hand-coded websites. If you need a native app or a large online store, a dedicated app developer or e-commerce platform is the right fit, and we can link to it from your site. For a few products, deposits or gift cards, a payment provider's hosted checkout usually covers it.
Will moving my website break my email?
It should not, as long as the mail records in your DNS stay intact. Website hosting and email are separate services that share a domain. Before any switch we document your current DNS records, copy the mail records exactly and test sending and receiving after the change.
Do you use CAPTCHA on contact forms?
No. We use layered checks that real visitors never see: hidden honeypot fields, a timing check, a token set by the browser and validation on the server. Every submission is also saved to a lead log on your server before the email is sent, so a real inquiry is not lost.
Who hosts the website, and who holds the passwords?
We can host it for you or set it up on a host you choose. Either way, the domain stays registered to you, and you get a written record of where the domain, DNS, hosting and email live, along with the logins you need.
Sources and Further Reading
- Google Search Central, How to move a site with URL changes (opens in a new tab)
- Gmail Help, Email sender guidelines (opens in a new tab)
- MDN Web Docs, Content Security Policy (CSP) (opens in a new tab)
- OWASP Foundation, OWASP Secure Headers Project (opens in a new tab)
- Chrome for Developers, Lazy load third-party resources with facades (opens in a new tab)
- Stripe Documentation, Integration security guide (opens in a new tab)