Good technology decisions start with a clear problem and a realistic view of the work involved. This guide sets out the questions we would bring into a discovery conversation, the tradeoffs to examine and the evidence worth collecting before committing to a delivery plan. The aim is practical clarity for Australian product teams and business owners.
Understand what you are comparing
React is a library for building interfaces. Next.js is a framework built around React, adding conventions for rendering, routing and server functionality. The useful choice is therefore between application architectures, not opposing technologies. Start with your publishing model, deployment environment and team capability. A framework can remove decisions, but its conventions still need to fit your organisation.
For a small marketing site, the important questions might be publishing speed, search discovery and whether hosting can remain static. For a customer portal, the discussion shifts to authentication, permissions and server operations. Both products can use React. Calling one option “more scalable” without describing the workload does not help you choose. Ask the team to explain the architecture through a specific customer journey.
Match rendering to the content
A public marketing page benefits from useful HTML arriving before JavaScript runs. Static generation is a strong fit for information that changes through a publishing workflow. Server rendering can help when a response depends on fresh or personalised information. An authenticated dashboard has different discovery needs from a searchable service page. Map those requirements by route instead of assigning one rendering strategy to the entire product.
Create a route inventory before the build. Mark the pages that can be generated at publishing time, the ones that need fresh server data and the ones that are useful only after sign-in. Record cache and access requirements beside each group. This exercise often reveals that the site needs two or three rendering patterns. It also gives testers a concrete list of direct URLs to verify after deployment.
Think about the people publishing
Ask who edits content, how drafts are reviewed and whether previews are required. A headless CMS can support either architecture, but preview URLs, cache invalidation and scheduled publishing require deliberate integration. A technically elegant build that makes a content editor wait for an engineer is not a good business outcome. Include your marketing team in the workflow demonstration before signing off.
Include a realistic publishing exercise in the acceptance process. An editor should create a draft, preview it, correct a heading, publish it and confirm that the public page updates. Then test a withdrawn page and a changed URL. Those everyday tasks expose weak preview and redirect workflows quickly. They also reveal whether the organisation needs documentation or permissions that the original technical brief overlooked.
Account for hosting and operations
A static React site can be deployed to a CDN with very little application infrastructure. Dynamic server functionality introduces runtime operations, secret management and monitoring. Managed platforms can simplify that work, while creating their own pricing and deployment constraints. Compare the cost of ownership and operational expertise rather than measuring only the initial build effort.
Ask for a diagram that distinguishes browser code, server code and third-party services. It should show where secrets live, which requests need authentication and who responds when a component is unavailable. A static site and a dynamic application have different operational responsibilities. Putting those responsibilities on paper is more useful than comparing the lowest advertised hosting price of two providers.
Keep performance a delivery responsibility
No framework automatically creates a fast website. Large images, unnecessary scripts and poor caching can outweigh architecture choices. Set a page weight budget and measure important customer journeys on a typical mobile connection. Keep public content readable without client-side data fetching wherever practical. Validate metadata, internal links and canonical URLs in the actual production output.
An effective performance check uses a representative page with real copy, production fonts, actual images and the intended analytics configuration. A blank starter page proves very little. Measure before adding the final decorative effects, then measure again afterwards. If a feature makes the page slower, decide whether its value justifies the cost. Keep the decision visible so another release does not accidentally reverse it.
Make the decision explicit
Document your preferred architecture, the reasons it fits and the conditions that would make you revisit it. Official React guidance recommends considering a framework for new applications, while acknowledging that custom setups have valid uses. Read the current documentation with your engineers and choose a system they can support, rather than a technology selected for its popularity.
Write down the tradeoff in plain language: “We chose static output because our public content changes through publishing, and the team does not need a server for personalised pages.” Add the condition that would change the choice. A short architecture record helps future developers distinguish a deliberate boundary from an arbitrary limitation. It makes the eventual decision to extend or replace that boundary much easier to discuss.
Bring the right questions to the table
Before choosing a supplier or solution, write a short decision brief. Describe the outcome you need, the constraints you cannot change and the assumptions you can test. Ask your team to review it from the perspective of customers, operations and ongoing ownership. Differences in those perspectives are useful: they often reveal an overlooked requirement before it becomes expensive to change.
You do not need a perfect specification to begin a conversation. You do need a shared understanding of the next decision. BonsaiCo can help frame a discovery engagement, work through options and prepare a practical delivery plan. Start small, make the work visible and let evidence guide the next stage of growth.