Website package or custom web design: which is right for your business?

By Nikki Prokop, Co-founder and Creative Director, Noknok Studios

Many businesses assume a package means a generic site and a custom project means a better one. That is not the useful distinction.

The useful question is: how much of the project can be defined before it begins?

If your business, your content and your requirements are already clear, a fixed process can move quickly and still produce a website that is designed specifically for you. If the project contains real uncertainty — about content, audiences, integrations or technical risk — that uncertainty needs to be worked through properly before a price and a scope can be responsibly fixed.

This is also why one project might be quoted at a fixed AUD 4,930 incl. GST and another cannot be priced until it has been scoped. The gap is not one of quality. It comes down to how much of the work can be scoped up front, versus how much needs to be discovered and resolved as the project goes. Both describe genuine, different kinds of work, not different levels of care.

At Noknok, we run two fixed website packages, the Evergreen Website and the Evolving Website, and both follow a fixed, expert-led process. Work outside them is a custom project, a collaborative engagement built around discovery and technical scoping that is scoped in conversation rather than sold as a package. Neither route is inherently the “proper” one, and neither is a downgrade of the other. Each is the correct answer to a different starting condition, and the way to find out which applies to you is to look honestly at what your project requires, not at which option sounds more serious.

What a good website package standardises

A package exists to remove decisions that do not need to be made fresh for every client. It is not meant to remove your business from the outcome.

A well-designed package standardises:

• How information is collected (intake)
• How scope is confirmed before work starts
• How work moves from intake to a working website
• How feedback is given and actioned
• What ordinary business-site functionality is included
• How price and timing are communicated

None of that standardises the website itself. A good package should not standardise your:

• Positioning
• Copy
• Page hierarchy
• Visual identity
• Images
• Website design

If a package is doing its job properly, the process is repeatable and the output is not. The process exists so the studio doesn’t have to reinvent logistics for every client. The design still has to fit your business, your audience and your offer, not a template built for someone else. That distinction is what stops a package sounding like a shortcut. It is a shortcut through logistics, not through judgement.

When a fixed package is likely to be enough

An Evergreen Website or an Evolving Website is likely to be enough when most of the following are true:

• The business and its offer are already clear
• The site’s main job is to explain services and generate enquiries
• Ordinary pages and forms cover what visitors need to do
• There is one main decision-maker for the project
• Existing systems do not need complex integration
• The site does not need ecommerce, portals or custom software
• You want expert judgement applied quickly, without a long workshop process

The difference between Evergreen and Evolving is mostly about who touches the site after launch. If your team needs to edit ordinary content in WordPress yourselves, an Evolving Website is built for that. If you would rather someone else maintain it, an Evergreen Website is the simpler path. Choosing either does not mean accepting a lower design standard. Both still involve individual decisions about hierarchy, copy and visual direction, made inside a fixed, well-tested process.

When custom work becomes necessary

A custom project, scoped in conversation rather than sold as a package, is likely to be the right call when the project cannot be responsibly scoped from a standard intake conversation. That is usually true when:

• Requirements cannot be defined through the standard intake process
• The organisation needs research or stakeholder consultation before direction is clear
• Several groups need to agree on priorities, and do not yet agree
• Content has unusual relationships or structures that do not fit a standard hierarchy
• The site needs custom user journeys, not a variation on a template
• External systems need to exchange data with the website
• Ecommerce requirements extend past ordinary store functionality
• Technical choices carry material operational risk if made incorrectly

These conditions are not about design ambition. They are about whether the problem is understood well enough yet for anyone to fix a scope and a price against it responsibly.

What does not automatically require a custom engagement

It is worth being direct about what does not, on its own, push a project into custom territory. Wanting any of the following is entirely reasonable, and none of them requires a collaborative, individually scoped engagement by itself:

• High-quality design
• An established brand that needs to be reflected properly
• Several ordinary service pages
• Professionally written copy
• A site that does not look like a template
• A blog
• Direct WordPress editing
• More than five pages

A business can want every item on that list and still be a straightforward fit for a fixed package. Page count in particular is a poor signal on its own. A twelve-page services site with clear content can be simpler to scope than a five-page site with one complicated ecommerce rule buried inside it.

Custom design and custom development are not the same thing. A website can have an individual design, original copy and a structure created around your business without requiring custom software or an open-ended discovery process.

The table below is a faster way to check where your own project sits.

A decision table

Question	Fixed package	Custom project
Is the business offer already clear?	Usually suitable	May still suit
Does the site mainly explain and generate enquiries?	Suitable	Usually unnecessary
Does the team need WordPress editing?	Evolving Website	Only if other complexity exists
Does it need ecommerce?	No	Yes
Does it need custom integrations?	No	Yes
Are several stakeholder groups involved?	Possibly	Often better
Is research needed before scope can be defined?	No	Yes
Is the price known before work starts?	Yes	Confirmed after scoping
Is the design individual?	Yes	Yes

[FIGURE — Does your website need a fixed package or a custom project?] The decision tree asks, in order: does the project need ecommerce, a portal, a directory, a custom tool or complex integration (if yes, custom); if no, does it require research, workshops or several stakeholder groups (if yes, likely custom); if no, does your team need to edit ordinary content (if yes, Evolving; if no, Evergreen). Final suitability is always confirmed before a deposit is paid.

Choosing correctly matters in both directions. Getting it wrong one way leaves gaps that surface mid-project. Getting it wrong the other way adds cost and delay without adding anything the customer will notice.

The danger of buying too little

Choosing a fixed package for a project that actually needs scoping tends to surface problems mid-build rather than before it starts:

• Required functionality is discovered only after the build has begun
• Complex content gets forced into a structure that was never designed to hold it
• A platform is chosen before anyone has properly understood what it needs to do operationally
• Change requests accumulate that should have been identified and scoped at the start, and now cost more to fix in place

None of this is a design failure. It is a scoping failure. The project needed a conversation that a standard intake process was never built to have, and the gap shows up later, usually at a worse time and a higher cost than if it had been raised up front.

The danger of buying too much

The opposite mistake is treating every project as though it carries this level of uncertainty, when it plainly does not:

• Paying for workshops that will not change the eventual answer
• Involving more people in the decision than the decision actually requires
• Spending weeks reviewing discovery documents for a business that is already well understood
• Building custom functionality to solve a problem that ordinary website features already solve
• Extending the project timeline without improving the outcome for the customer at the end of it

A custom engagement earns its cost when it resolves real uncertainty that would otherwise show up as expensive mistakes later. It does not earn its cost when it is applied by default to a business that already knows exactly what it needs.

How Noknok decides

We do not expect you to diagnose this on your own, and we do not start from an assumption about which route is right for you.

Before we quote, we review:

• What the website must achieve
• Who needs to edit it, and how often
• The complexity of your content and audiences
• What functions the site actually requires
• Whether integrations with other systems are involved
• How many people need to review and approve the work
• Your timing
• Any known technical or operational risks

From there, we confirm whether your project fits the Evergreen Website, the Evolving Website or a custom project, and quote accordingly. Final suitability, like final scope, is confirmed before any deposit is paid. That short qualifying step is what stops us defaulting to the more expensive path when a fixed package would genuinely serve you better, and what stops us fitting a genuinely complex project into a process that was never designed to carry it.

A fixed package does not have to produce a generic website, and a custom engagement does not automatically produce a better one. The right process is the one that matches the project’s actual uncertainty and complexity.

---

Compare the two website packages →

Tell us what your website needs →

Related insights

• Who owns your website when an agency builds it?
• How can a website be built quickly without cutting corners?