Most agencies won't tell you their stack, usually because the answer is a page builder and a plugin. Here's ours in full — including the performance budgets we hold ourselves to and the three things we refuse to take on.
These aren't preferences. They're the reason our builds are cheaper to run and don't degrade eighteen months after launch.
Tracking is designed first and built first. A beautiful site you can't attribute revenue to is a very expensive opinion.
Pre-rendered files on a CDN. No database to query on every request, nothing to patch, nothing to fall over during your busiest week.
Drag-and-drop tools ship four times the code for the same result. We write the markup, so we own the performance.
Repositories, ad accounts, tag containers, analytics properties, warehouse datasets, domains. All in your name, from day one.
Set before design begins and enforced at deploy. A page that busts the budget doesn't ship until it's fixed.
We optimise for the developer who inherits this in three years, not for the framework that's fashionable this quarter.
Published in full. If a supplier won't tell you what they're building on, that's information too.
| Layer | What we use | Why |
|---|---|---|
| Front end | Semantic HTML, modern CSS, minimal vanilla JS | The fastest framework is the one you didn't ship. Most marketing sites need no framework at all. |
| Templating | Python generators, template inheritance, shared context | One template change updates every page it touches. Consistency stops being a manual discipline. |
| Delivery | Edge CDN, atomic deploys, instant rollback | A bad deploy is reversed in seconds rather than restored from a backup. |
| Source control | git, branch-per-change, reviewed merges | Every change is attributable and reversible. Your developers can audit ours. |
| Search infrastructure | JSON-LD schema, XML sitemaps, canonical and pagination discipline, log-file analysis | Crawl budget is finite. Most large sites waste it on pages that should never have been indexable. |
| Measurement | GA4, tag manager, server-side container on your own subdomain | Browser-side collection is increasingly blocked. Server-side restores the signal that bidding algorithms depend on. |
| Data | BigQuery, scheduled pipelines, Looker Studio | Platform dashboards disagree with each other by design. A warehouse gives you one set of numbers. |
| Automation | Webhook-driven workflows, queue-backed jobs, CRM APIs | Lead routing and follow-up run in seconds without a human remembering to do it. |
| Applications | Framework chosen per problem; relational data by default | We pick the tool after the requirements, not before. Most "we need an app" briefs don't. |
These are targets we design to, not results we're claiming for your site. If a page can't meet them, something in the design or the stack is wrong and we fix it before launch rather than after.
When a site needs every service crossed with every location, or every make crossed with every model, hand-building is the wrong tool. The pages get written once as a system, then generated — and regenerated whenever the model changes.
The discipline that matters here isn't generating pages — anyone can do that. It's refusing to generate the ones that shouldn't exist. Thin, near-duplicate location pages are the fastest way to get a large site classified as doorway spam, so combinations that can't support genuinely distinct content don't get built.
Tracking pixels in a browser are blocked, truncated or consent-limited more every year, so platforms optimise against a partial picture. A container running on your own domain collects first-party events and distributes them — to the ad platforms for bidding, to your CRM for follow-up, and to a warehouse so the reporting reconciles.
A longer capability list is easy to write. These sit outside what a team our size can do responsibly, so we refer them out.
A failed campaign costs money. A failed security engagement can end two companies. It needs specialist certification, specific insurance and 24/7 incident response — we have none of those, and we'd rather say so than sell it.
New Zealand has mature AWS and Azure partners who do this every day. You'd be paying us to learn on your infrastructure. We'll handle hosting and delivery for what we build; anything larger goes to a specialist.
Print, radio and outdoor are bought on reach and hope. We can only be judged on revenue where the click, the call and the sale can be tied together, so we stay where attribution is possible.
Plenty of our work sits alongside an in-house team or an existing development partner. We'll take the measurement, search and conversion layers, work to your branch and review process, and write specs your developers can implement rather than sending them a list of requests. If your setup is already good, we'll tell you that too — in the free session, before you've spent anything.
A static page is a file on a CDN. There's no database to query, no plugin to patch, no runtime to exploit and nothing to fall over under traffic. It's faster and cheaper to host, and the security surface is close to zero. When a site genuinely needs frequent non-technical publishing we'll use a CMS — but that should be a decision, not a default.
Pages are built from a data model and a template rather than written one at a time. Define the entities — services, locations, makes, models, categories — write the template once, and the generator produces every valid combination with correct internal links, canonicals, schema and sitemap entries. It's how a site can run to thousands of pages without becoming unmaintainable.
Yes. Everything lives in Git, deploys are atomic with instant rollback, and generated builds are validated before they ship — broken links, missing canonicals, malformed schema and orphaned pages are caught at build time rather than by Search Console three weeks later.
Usually. The first step is an audit of what's there — architecture, performance, tracking, index coverage and technical debt — and an honest answer about whether it's better to fix or rebuild. Rebuilding is more profitable for us, which is exactly why we'll tell you when fixing is the right call.
Cyber security incident response, cloud migration and traditional media buying. The first two need specialists, and pretending otherwise would put your business at risk to protect our invoice. The third we avoid because it can't be attributed, and attribution is the whole basis of how we're paid. We'll refer you on for the first two.
Book a free discovery session. We'll audit what you're running, tell you what's leaking budget, and show you what we'd do differently — no obligation.