The Website That Joined the On-Call Rotation

Phoneware sells cloud business phone service. We spent two weeks making sure their website answers, then handed it back so their own team could run it without us. This is how.

What we started with

Their old site was WordPress with a WooCommerce store bolted on, the arrangement most small companies end up with because it's what was available when they last needed a site. It listed plans, it listed phones, it had a contact form. It did what a brochure does. What it couldn't do was carry any weight when a customer arrived with a real problem or a ready-to-buy question, which, for a phone company, is most of the reason anyone visits.

Construction was the short part

Here's the thing that surprises people about a rebuild done well: the building is fast, and it isn't where the time goes. The new site, a full static Astro build, came together on the first day. The next eight days weren't construction. They were refinement: the store rebuilt from their real product catalog, the support library ported over, the concierge, the search, the SEO work, the details that separate a site that exists from a site that earns its keep. It went live on day nine, when we flipped production to phoneware.us in a controlled cutover, and we spent a few more days polishing after real traffic arrived.

That ratio is the whole discipline. Anyone can stand up a site in a day. The value is in the eight days most shops skip, and in launching on day nine instead of shipping the day-one draft and calling it done.

The part that actually answers

Every page carries a concierge, and it's built on Claude. Ask it about a plan, a phone, or how to set up a feature, and it answers from Phoneware's own content rather than inventing an answer, because the entire site's knowledge is compiled at build time into one corpus the assistant reads from. We skipped the usual vector database; for a site this size, scoring its own text in memory is simpler, cheaper, and has nothing to fall out of sync. The site is its own source of truth, and the assistant is grounded in it.

Answering questions is the easy half. The concierge is wired into the team's Microsoft Teams. Every conversation mirrors into a channel in real time, and a staffer can step into the same thread and take over, with the visitor never knowing they crossed from software to human. It knows business hours and routes accordingly. When a customer signs in through the portal, the site knows who they are, so the assistant greets an account, not a stranger. And when it detects an emergency, someone whose service is down, it confirms who it's talking to and pages the on-call rotation.

That's the reframe worth keeping. We didn't add a chatbot to a website. We put the website on the on-call rotation. It's a member of the support team that happens to be made of software, and it hands off to the ones made of people at exactly the moment that matters.

The part where we hand back the keys

A website that only its builder can change is a liability wearing a nice suit. So the most important thing we shipped never appears on the page: Phoneware's own team, none of them engineers, now maintains the entire site themselves, in plain English, through Claude.

Someone who wants to add a blog post, put a new phone in the store, publish a customer story, or redirect an old link opens Claude Code Desktop and describes what they want the way they'd tell a coworker. Claude makes the change, shows a preview, and it publishes itself once it builds cleanly. Nobody has to know what a "content collection" or a "commit" is. The guardrails that keep the site on-brand and correct are written into a skill Claude follows every time, so the same rules we worked to apply are applied on every edit, whether we're in the room or not.

We didn't hand Phoneware a website. We handed them the ability to run one. That's the difference between a deliverable and a dependency, and it's the part small businesses almost never get, because the usual arrangement quietly requires you to keep paying the person who built the thing every time you want to change a sentence.

Fast by construction, which is also an SEO decision

Pull up the live site in Google's Lighthouse and it scores 100 for performance, 100 for accessibility, 100 for best practices, and 100 for SEO. A perfect sweep. Largest Contentful Paint lands at 1.4 seconds, layout shift is effectively zero, and the main thread is never blocked. Those aren't numbers we tuned for at the end. They fall out of the architecture.

A static site is fast the way a printed page is fast: the work happened before you asked, so there's no database query, no server rendering, no plugin chain to wait on. The pages are built once and served as flat files from a global CDN. Speed isn't a feature we added. It's a property of the shape we chose.

And speed is not just a courtesy to visitors. Google uses page experience, including Core Web Vitals like loading speed and layout stability, as a ranking signal. So the decision that makes the site pleasant to use is the same decision that helps it rank. We got to stop treating performance and SEO as two separate chores, because for a static site, they're the same chore solved once.

The migration protected the rest. Relaunching a site is the easiest way to quietly delete years of search ranking along with the old URLs, so we led with the unglamorous, load-bearing work: a redirect for every old WordPress address pointing at its specific new home, a clean sitemap, structured data describing the company to search engines, and a "where we serve" map that expands into a page for every state and 159 major metro areas, which is how a regional company shows up when someone three states over searches for business phone service in their own city.

Enterprise plumbing, small-business bill

None of this is worth much if it takes a hero to deploy or breaks the first time someone's out. So the site runs on the same engineering practices a serious software team would expect, and Phoneware never has to think about any of it.

Every proposed change opens a pull request, and every pull request spins up its own live preview URL, so a change gets seen in a real browser before it merges. Merges deploy themselves. The infrastructure is defined as code and version-controlled, not clicked together in a console, so it's reproducible and auditable rather than a configuration nobody remembers making. Even the production launch was staged as code: the domain attached in one controlled step, traffic flipped in the next, with the old site kept reachable as a safety line rather than deleted on faith. Secrets never live in the codebase. Access to deploy is granted by short-lived, federated identity instead of a long-lived key sitting in a file waiting to leak.

This is standard practice at a company with a platform team. It is almost unheard of at a company with a phone and a website. The gap between those two worlds isn't budget. It's whether someone bothers to bring the practice.

What it adds up to

A phone company's website should behave a little like its phones: pick up, know who's calling, and get a person on the line when it counts. Phoneware's now does, it runs at a perfect score, it maintains itself in plain English, and it ships on the kind of automation that used to require a whole team.