NexusByte
The site you are reading is the one we are hardest on. nexusbyte.com.au first went live in March 2014, and it has been rebuilt once since — a full migration off the stack it was born on. It is where we test the decisions we recommend to clients before we recommend them.
2014: React and Contentful
The original build paired a React front end with Contentful as the content store. In 2014 that pairing was still an argument rather than a default. Most of the Sydney market was putting brochure sites on WordPress, and choosing a decoupled front end talking to a hosted content API meant explaining to people why the CMS no longer drew the page. What it bought us was a clean separation between the content and the thing displaying it, and that one decision is the reason the migration years later was survivable at all — the content was never entangled with the templates, so it could be moved without being rewritten.
The migration to Next.js and Strapi
Next.js changed the calculation. A React application that rendered only in the browser was pleasant to build and weak at precisely the thing this site has to be good at: arriving complete for a crawler, on a phone, on the first request. Next.js gave us server rendering and static generation without walking away from React, so the front end could be migrated rather than started again from an empty folder.
Contentful went at the same time, for a different reason. We wanted the content store on our own infrastructure instead of metered per API call, and we wanted to model content types freely rather than have a plan tier decide how many we were allowed. Strapi gave us both, self-hosted and open source. It was a genuine migration on both halves rather than a re-skin — every content type remodelled, every entry moved, every template rewritten, and every existing URL preserved or redirected in a single hop so a decade of accumulated search equity survived the move. We did it on our own site first, deliberately, because this is the one project where we can afford for a migration to be hard. Several of the client builds in this portfolio run the same pairing today, which is not a coincidence: we do not put a client on a stack we have not lived with ourselves.
Content at build time, not at request time
The architectural decision everything else follows from is that Strapi is a build-time source, not a runtime dependency. Every page is rendered statically at deploy, so nothing is fetched when a visitor arrives. There is no database call between the request and the response, which means no query that can be slow, no API that can be down, and no cache layer to reason about at three in the morning.
What we give up is obvious: an edit is live at the next deploy rather than the next save. For a newsroom publishing hourly that would be the wrong call, and we build those to render on demand instead. For a site where content changes deliberately rather than continuously, and where every page is a considered piece of writing rather than a feed item, taking the CMS out of the critical path is straightforwardly better. Being honest about which of those two you are is most of the job.
Three hundred pages that have to stay distinct
The site runs past three hundred pages: seven service families, their sub-services, suburb and city coverage, a portfolio, and a library of long-form articles. A site this size does not fail by being slow. It fails by repeating itself — near-duplicate pages that dilute each other until none of them is worth ranking, which is the standard fate of programmatically generated location pages.
The discipline we hold ourselves to is that no page copy is ever generated. Every page is written by hand, one at a time, including the ones that look like they could be templated. It is slower and it is the reason the site works. We have also removed pages rather than accumulate them — a set of duplicate suburb pages was retired and redirected once it became clear they were competing with their own parents rather than adding reach.
Structure that cannot silently break
Several things are wired so that the common failure modes become impossible rather than merely unlikely. The sitemap is derived from the filesystem at build time, so a new page cannot ship missing from it and a deleted one cannot linger. Metadata cannot drift from the page it describes, because it lives beside the content it belongs to. Last-modified dates come from real commit history rather than the build clock, so the sitemap does not tell Google that all three hundred pages changed today.
On top of that sits a set of checks that run against the source: broken internal links, orphaned pages with no inbound link, metadata outside the length Google will display, and text corruption from bad character encoding. They run as a script, which means a structural regression shows up in a terminal in seconds instead of in a ranking drop three months later. That is the part most sites never build, and it is the part that keeps this one honest. It is also the standard behind our web development work generally.
The SEO build
Every page on this site owns its own metadata: title, description, canonical, Open Graph and Twitter card, and its own JSON-LD graph. None of it is inherited from a global template and then patched, which is the arrangement that produces sites where forty pages quietly share one description. Structured data is written per page type rather than applied uniformly — an Organization and LocalBusiness graph site-wide, BreadcrumbList on every nested route, Article markup on the blog, Service on service pages and CreativeWork on the portfolio entries, including the one you are reading.
The parts that usually rot are automated instead. The sitemap is built from the filesystem so it cannot fall out of step with the pages that exist; last-modified dates come from git history rather than the build clock, so we are not telling Google that three hundred pages changed on every deploy; and redirects are maintained as single hops, with chains flattened whenever a destination itself moves. The check suite then enforces it — broken internal links, orphaned pages, metadata length and encoding corruption all fail loudly in a terminal rather than quietly in a ranking report.
The Challenge Of Project
- Migrating a live site off React and Contentful onto Next.js and Strapi without losing content, URLs or accumulated search equity — remodelling every content type and rewriting every template in the process.
- Moving the content store onto our own infrastructure, so the shape of the content is decided by the project rather than by a plan tier.
- Keeping three hundred-plus pages genuinely distinct, since a site this size fails by repeating itself until no page is worth ranking.
- Writing every page by hand rather than generating location pages, and retiring duplicates that were competing with their own parents instead of adding reach.
- Deriving the sitemap from the filesystem and last-modified dates from commit history, so a page cannot ship unlisted and the sitemap cannot cry wolf.