Most of the small firms I worked with ran a template site, and most of them were perfectly well served by it for the first three years. The trouble, when it arrives, never arrives as a design problem. It turns up as a contact form that quietly stopped sending, a disclosure page nobody can edit properly, or a quote to move forty pages somewhere else. This is not an argument for one approach over the other - it is an attempt to work out where the line sits for a firm your size.
A firm with two partners, one administrator and six pages of content does not have a website problem that a custom build solves. Home, services, about, team, contact, and something resembling a resources page - that is the whole shape of it, and every hosted site builder handles that shape competently.
I have watched firms spend fifteen thousand dollars on a site a template would have produced for a fraction of that, because someone had convinced them their practice was unusual. It was not. Accounting practices are structurally similar to one another, which is exactly why the template category exists and why it holds up.
The useful test is not whether your firm is distinctive. It is whether the distinctiveness lives anywhere a website can express it.
The pitch is usually about price. Price is the less interesting half.
What a template actually buys is the removal of decisions. Someone has already chosen the navigation pattern, the mobile breakpoints, the way a team page looks. For a practice manager doing the website in the gaps around a real job, that matters more than the invoice. A custom build asks you roughly forty questions you have no basis for answering, and every unanswered one stalls the project.
The firms I saw come off badly on custom builds were rarely burned on cost. They were burned on elapsed time - eleven months for a site quoted at three, because the approvals sat with a partner who was in the middle of provisional tax.
Custom builds arrive with a maintenance relationship whether or not anyone writes it into the contract. An open-source content system needs updating, and an unpatched install is a real liability for a firm holding client contact details.
A hosted builder absorbs that. The vendor patches the platform, renews the certificate and keeps the thing online without asking you anything. The monthly fee is buying a job you would otherwise have to remember to do.
Work out your firm's actual maintenance capacity before you decide - not what you intend it to be, but what it has been. If a practice management update sat pending for six months, self-hosting is a commitment you will not meet.
Financial services sites carry pages that most businesses do not:
- disclosure information and adviser details
- complaints and dispute resolution steps
- a privacy statement that reflects what the site actually collects
Those pages are read by people checking whether you are legitimate, and occasionally by someone with a regulatory interest.
Templates handle them awkwardly. Not because the page cannot be built - because the page needs to be structured, findable and versioned. A disclosure statement that changes needs the old version retained and the new one published without breaking the URL. Most builders treat every page as interchangeable content, so the firm ends up with a PDF bolted to a menu item.
That is workable. It is also where template sites start to feel improvised: the marketing pages polished, the obligation pages obviously an afterthought.
An enquiry form on an accounting firm's site collects personal information, and sometimes financial detail the sender should never have typed into a web form at all. Where that data goes, how long it is held and who can read it are questions the Privacy Act 2020 expects you to have answered, and the Office of the Privacy Commissioner publishes plain guidance on what that means in practice.
Hosted builders route submissions through their own infrastructure, often offshore, and keep them in a dashboard indefinitely by default. Nobody at the firm knows this until someone asks. A custom build lets you decide: deliver to an inbox and store nothing, or store it somewhere you control.
This is the point where "it is just a contact form" stops being true.
Every platform is easy to move onto. The differences show up on the way out.
Ask what leaves with you. Some hosted builders export content as a structured file another system can read. Others produce something that technically contains your words but arrives with the formatting stripped, the images unlinked and the URLs changed. If you have five years of articles and a few pages earning search traffic, that difference is most of the cost of the decision.
Lock-in is not a moral failing on the vendor's part. It is a design consequence - a platform that owns the templates, the hosting and the editor has no structural reason to make leaving comfortable. Just price it. If moving off costs eight thousand dollars in three years, the monthly fee was never the real number.
Compare five-year totals, not the build quote against the monthly fee.
A custom build for a small New Zealand practice generally lands somewhere between eight and twenty-five thousand dollars, depending on content volume and how much of it is genuinely bespoke, plus hosting and maintenance after that. A hosted builder runs a modest monthly subscription, plus whatever you pay someone to write and load the content - which is the line most firms forget, because it costs the same either way.
Over five years the two numbers sit closer together than the opening quotes suggest. What separates them is year six: one path leaves you with a site you can extend, the other with a subscription and a redesign decision.
On a Thursday afternoon the contact form stops sending. Who do you ring?
With a hosted builder the answer is a support queue - usually adequate for platform-level faults and useless for anything specific to your setup. With a custom build the answer is whoever built it, which is excellent while that relationship holds and a genuine problem when it does not. I have inherited more than one site whose original developer had moved to Australia and stopped replying to email.
Get the answer in writing before you commit: who responds, in what timeframe, and what happens when they are unavailable. A firm that cannot take enquiries for a week has a revenue problem, not an IT problem.
The most common failure I saw was not a bad website. It was a good website that nobody at the firm could change.
Whichever path you take, insist on a demonstration before sign-off: someone from your own team, not the developer, adding a staff member and publishing a short update while you watch. If it takes them twenty minutes and a phone call, the site will be out of date within a year regardless of what it cost.
That distinction does not follow the template-versus-custom line cleanly. I have seen custom builds with editing interfaces a practice manager could use one-handed, and hosted builders so fiddly the firm gave up and went back to ringing someone.
The question is rarely template or custom. It is whether the constraints of the cheaper path collide with anything your firm genuinely needs to do, and for plenty of small practices they never do. Work out where your own collision point sits, price the exit before you take the entrance, and the decision tends to make itself.
