Two invoices, one word: "website"
Two South African business owners can receive quotes on the same day (one for a few thousand rand, one for several times that) and both can walk away convinced the other guy got fleeced. Neither is necessarily right. The word "website" covers a focused single-offer page, a five-service marketing site, a full ecommerce catalogue and a custom client portal, and those are four different jobs wearing one label.
A sharper first question than "what does a website cost" is "what does this website need to make happen." Credibility, an enquiry, a booking, a sale, a published body of expertise, fewer support calls, or a sales team that stops repeating itself on calls, each answer points to a different set of pages, a different content load and a different set of integrations. The part clients see is the layout. The part that actually costs money is usually invisible: information architecture, the words on the page, mobile testing, CRM wiring, analytics events and the checks before launch.
Nexus keeps its entry pricing plain: Launch from R3,000, Business from R5,500, Pro from R8,000 for platform builds; custom development from R5,000; ecommerce from R7,500. Those numbers are starting lines for a defined scope, not a claim that every business needs the same site. A proper scoping conversation settles where you actually land.
Illustrative website investment bands for 2026
| Project shape | Typical scope | Commercial question to answer |
|---|---|---|
| Focused launch surface | One clear offer, conversion CTA, basic credibility and analytics | Can we test demand without building a corporate catalogue? |
| Business marketing site | Core service pages, reusable layouts, CMS content, contact paths and measurement | Can a prospect understand us and enquire without a sales call? |
| Ecommerce store | Catalogue, product data, payments, delivery logic, policies and transactional QA | Can customers buy without operations creating manual exceptions? |
| Custom web experience | Unique workflows, integrations, data logic or role-based behaviour | Is the website behaving more like a product than a brochure? |
What actually pushes a quote up or down
Page count is a rough guess at best, and often a misleading one. Five pages built from one reusable template can be simpler to deliver than three pages that each need their own journey, a comparison tool, gated content and a booking integration. The number that matters is how many genuinely unique templates and interaction states are being designed and tested, not how many links sit in the main menu.
Content readiness quietly decides half of every quote. Hand over approved copy, images, product data and brand assets, and a build moves at speed. Ask an agency to pull the offer out of stakeholder interviews, write the copy, source imagery, untangle duplicated spreadsheets and chase five rounds of sign-off, and you have created real, billable work, work that deserves its own line item rather than a silent assumption that it is "included."
Integrations are where a cheap quote and a working system part ways. A form that drops into an inbox is not the same product as one that creates a tagged CRM record, fires a useful confirmation, routes by service line, logs consent and shows up in analytics. Neither version is automatically wrong; the right one depends on how many leads you get and how your sales process actually runs.
- Unique design templates and responsive states
- Copywriting, content migration, image treatment and product-data cleanup
- CRM, booking, payments, email, WhatsApp and analytics integrations
- Multi-language, accessibility, permissions or compliance requirements
- Stakeholder availability for feedback and acceptance testing
Scope drivers that deserve line items
| Driver | Why it changes cost | Question for your quote |
|---|---|---|
| Content | Writing, editing and migration can exceed the time spent placing pages. | Who supplies approved copy, images and product information? |
| Conversion work | A lead path needs CTA strategy, forms, confirmation states and tracking. | Which events will be tested and measured at launch? |
| Ecommerce | Products, variants, fulfilment, payments and refunds create operational rules. | Which exceptions must the store handle on day one? |
| Custom logic | Bespoke behaviour requires engineering, tests and ongoing ownership. | What existing tool cannot handle this requirement? |
| Support | Someone must handle updates, security, incidents and continuous improvements. | What happens after the launch warranty or handover? |
Once-off or monthly, compare the total, never the instalment
A monthly plan can make a sound website investment easier to fit around cash flow, which matters for a business protecting its working capital while it grows. It does not automatically make the project cheaper, that is a separate question with a separate answer. Line up the once-off project fee, every recurring hosting or platform charge, any total finance figure, and exactly what the deal includes once the site is live.
Nexus publishes disclosed 12-month totals on eligible plans, because "from R___ a month" only helps with budgeting once you can also see the full number and tell it apart from hosting, domain fees, ad spend or an ongoing marketing retainer. Before you sign anything, ask when ownership actually transfers, what happens if you cancel early, and which deliverables remain in scope, a monthly plan should still name pages, timeline, revisions, platform and support window in writing. Financing changes how you pay; it should never blur what you are buying.
Price the next 24 months, not just launch week
The invoice you sign is the most visible number, but it is not the real cost of owning a working website. Total cost of ownership adds domains, hosting or platform fees, licences, maintenance, content updates, conversion testing, staff time and eventual migration, plus the quieter cost of a slow or confusing site turning paid clicks and search demand into conversations that never happen.
Do not use "total cost of ownership" as an excuse to buy the most complicated option available. A simple platform site can carry the best TCO of all when it lets your team publish quickly and actually does the job required. A cheap build can carry the worst TCO when every small edit needs an emergency developer call-out, or the whole thing needs rebuilding twelve months later.
Sketch a two-year view before you commit to a platform. List the changes you can already see coming (new services, monthly content, campaigns, catalogue updates, integrations, staff handovers) then ask which option lets those changes happen safely and on a predictable timeline.
A simple 24-month TCO model
| Cost category | Year-one view | Year-two question |
|---|---|---|
| Build and launch | Discovery, design, build, QA, migration and training | Will the architecture still support the next stage? |
| Platform and infrastructure | Domain, hosting, CMS, plugins, payment or email services | Which subscriptions renew and who monitors them? |
| Content and optimisation | New pages, photography, copy, landing tests and SEO improvements | What commercial content must ship to keep demand growing? |
| Support and ownership | Bug fixes, updates, backups, handover and change requests | Who owns response time when something breaks? |
| Lost conversion opportunity | Leads lost because visitors cannot understand, trust or contact you | Are we measuring the leak or merely debating aesthetics? |
The useful question is not “What is the cheapest website?” It is “What is the lowest-risk way to create and sustain the result we need?”
Nexus website planning principle
Platform, custom or ecommerce, matching the tool to the job
Most service businesses and campaign-led brands are well served by a platform build. It offers real design control, a structured CMS for editing and fast publishing, without the overhead of maintaining a bespoke application. The deciding factor is simple: how often does your team need to change content, and does the work stay inside what a proven platform is genuinely good at?
Custom development earns its cost when the commercial advantage lives in a unique workflow, a deep integration, an unusual data model or something that behaves like a product rather than a page. It is a poor fit chosen purely for the status of "custom." A custom build needs a named product owner, a real test process, someone owning the environments, and a maintenance plan, without those three things, the flexibility you paid for turns into operational debt within a year.
Ecommerce sits in its own category entirely. A serious ecommerce quote addresses catalogue structure, product variants, payment methods, delivery rules, policies, customer communications, inventory ownership and real test orders. A gorgeous product grid says nothing about whether the difficult operational questions have actually been answered.
A brief template that gets useful quotes
- Name the business outcomeWrite one sentence: “This site must generate qualified consultation requests from Gauteng manufacturers” is more useful than “we need a modern website”.
- List required journeysDefine what a visitor must be able to do: enquire, book, buy, download, apply or find a branch.
- Separate must-haves from later ideasMark launch-critical requirements separately so a nice-to-have does not quietly become a project blocker.
- Inventory inputs and ownersList copy, photography, logos, product data, legal text, access credentials and who approves each item.
- Ask for commercial clarityRequest inclusions, exclusions, timeline assumptions, payment total, support terms and acceptance criteria in writing.
Quote red flags to investigate before signing
- A single total with no sitemap, deliverables, platform or list of exclusions.
- A monthly price without a disclosed 12-month total or clear ownership terms.
- “Unlimited revisions” with no approval process, stage gates or launch definition.
- A promise of SEO rankings, leads or sales without explaining measurement and dependencies.
- No mention of mobile QA, redirects, analytics, backups, access handover or support.
- A custom build recommended before anyone has mapped the workflow it is meant to solve.
- A quote that assumes content is ready when no one has accepted responsibility for it.
Putting three proposals side by side, fairly
Build one comparison sheet and force every proposal into the same rows: outcome, page or template count, platform, design process, content responsibility, integrations, analytics, launch support, recurring costs, payment total and exclusions. A supplier who leaves a row blank has probably left that work out of the price, which is not automatically disqualifying, but it is a gap you should price deliberately rather than discover later.
Weigh delivery risk alongside the number itself: who does the actual work, how approvals happen, what "done" means, and who holds the keys to the domain, analytics and source files once the project ends. For an SME, a supplier who is plainly organised about ownership is often worth more than one with a glossier deck. Decide what has to be true on day one, a first release does not need every future idea baked in, but it does need to be credible, measurable, and ready for the demand you are about to send at it.
The move that actually protects you
If you are still early, run a cost calculator to frame the scope and write a short website brief so you know what you are actually asking for. If quotes are already sitting in your inbox, resist ranking them as "best" until every one has been normalised onto the same comparison sheet. A supplier asking pointed questions early is usually lowering delivery risk for you, not manufacturing complications.
Once the commercial job is clear, Nexus can point you toward Launch, Business, Pro, custom or ecommerce, the goal is a site you can launch, measure and improve, not the largest build the budget could technically stretch to. A final, practical test before anyone signs: ask what happens in the first 30 days after launch. A solid answer covers who owns the credentials, whether forms and analytics were actually verified, how enquiries get handled, and what the first round of evidence-based improvements looks like, not a shrug that treats launch day as the finish line.
Keep the signed scope document after work begins; it becomes your change-control baseline the moment a stakeholder asks for "just one more page" halfway through the build. That document is the difference between a new idea getting properly classified as in-scope, deferred, or re-quoted, and a timeline quietly sliding by six weeks with nobody agreeing to it.
Before you sign, ask for one plain-English walkthrough of the statement of work. Confirm the launch-date assumptions, content deadlines, payment milestones, acceptance criteria and access handover out loud. Ten minutes of that conversation now can save months of arguing later about what everyone assumed the other side meant.

 Store Build Pricing Guide.png)

 Which Store Platform Wins.png)