Custom software and a custom website share a word. They rarely share a budget.

A logistics operator once asked three suppliers to quote "custom software to manage our fleet bookings." One supplier, used to pricing marketing websites, came back with a number close to what a custom website costs, reasonable-sounding, fast to deliver, and built around the assumption that this was mostly a matter of designing screens. The other two, both software specialists, quoted several times that figure and wanted a two-week discovery phase before committing to anything at all.

The gap was not padding or inflated day rates. The first quote had genuinely misunderstood the job. A custom website presents information and captures simple enquiries, a real and valuable piece of work, but a fundamentally different shape of problem from software that has to track vehicle availability in real time, prevent double-bookings, integrate with a driver-facing mobile app and reconcile against an existing accounting system. One of those jobs is design and content. The other is a data model, a set of business rules, and years of ongoing operational responsibility.

This confusion (treating "custom" as a single price bracket regardless of what is actually being built) is the single most common reason software budgets blow past expectations before development has even properly started. This guide draws that line explicitly, with real Nexus entry pricing on both sides of it.

A website's complexity mostly lives on the surface: how many unique page layouts, how much content, how many integrations pulling data in or out. Software's complexity mostly lives underneath what anyone sees: how data relates to other data, what happens when two people try to update the same record at once, what business rules govern an edge case nobody thought to mention until testing began.

That underlying complexity is exactly what a website-style estimate misses. A booking system is not "a form with a calendar", it is a set of rules about availability, conflicts, cancellations, notifications and what happens when something goes wrong at 11pm with no developer awake to fix it. Pricing that rule set the way you would price a contact form is how software projects end up quietly renegotiated mid-build.

Software also carries a different risk profile once it is live. A marketing website going down for an hour is an inconvenience. Software that manages inventory, payments or scheduling going down for an hour can mean lost revenue, duplicated bookings or a customer-facing failure, which is exactly why serious software quotes include real testing, error handling and a maintenance plan as core scope, not a nice-to-have upsell.

Every tier starts with a process audit before a number is finalised. That step exists because the honest scope of a software project is almost never fully visible from a first conversation, it emerges once someone actually maps how the workflow really runs today, including its exceptions.

Integration depth is usually the single biggest lever. A tool that stands alone is dramatically simpler than one that has to talk reliably to an accounting system, a CRM, a payment gateway and a third-party logistics API, each integration point is a place where two systems can disagree about the truth, and reconciling that disagreement is real engineering work.

Data model complexity matters just as much, even though it is invisible to anyone outside the build. A system tracking one type of record with simple relationships is straightforward. A system tracking multiple interrelated entities (customers, orders, inventory, staff, locations) with rules governing how they affect each other is a meaningfully bigger job, even if the number of screens looks similar on a wireframe.

User roles and permissions add a layer many first-time software buyers underestimate. The moment more than one type of user needs different access (an admin, a manager, a customer, a driver) the system needs a genuine permissions model, not just a login screen, and that model has to be designed, built and tested carefully or it becomes a security and trust liability later.

• Map the actual workflow today, including every manual workaround currently propping it up
• List every system this software needs to talk to, and what data flows each direction
• Name every type of user and what each one should and should not be able to do or see
• Decide what happens in the worst-case scenario, a failed payment, a lost connection, conflicting updates
• Identify who owns this system’s maintenance once it is live, before a line of code is written

Software is never actually finished the way a website launch feels finished. Dependencies need updating, security patches need applying, and the business itself keeps changing in ways the software has to adapt to. A build quote that says nothing about what happens in month seven is an incomplete quote, no matter how detailed the initial feature list looks.

Budget for an ongoing maintenance relationship from the very first conversation, not as an afterthought once something breaks. This does not need to be an expensive retainer for a genuinely simple internal tool, but it does need to be a named responsibility with a named owner (internal or contracted) rather than a system nobody is watching until a customer complains.

Our companion article on custom software versus SaaS covers the build-versus-buy decision in more depth if you have not settled that question yet. Plenty of workflows that feel unique from the inside are, on close inspection, common enough that a well-configured off-the-shelf tool solves the problem for a fraction of a custom build’s cost.

1. Confirm the workflow is genuinely customRule out an existing SaaS tool solving the same problem before committing to a build, see our SaaS vs custom guide.
2. Run a structured discovery phaseMap the real workflow, integrations, user roles and edge cases before pricing anything definitively.
3. Scope an MVP, not the full visionDefine the smallest version that tests the genuine advantage, deferring lower-priority features to a second phase.
4. Price the first 24 monthsInclude build, hosting, maintenance and a named product owner, not just the launch invoice.
5. Name the maintenance owner before launchDecide who keeps the system running, patched and adapted to a changing business, in writing.

A software quote produced without discovery is a guess wearing a number. A quote produced after real discovery is grounded in what the workflow actually requires.

Kgothatso Mphahlele, Founder, Nexus Media Agency

• A fixed price with no discovery phase, on a project that has never been mapped in detail
• No mention of who owns testing for edge cases, failed payments, conflicting updates, offline scenarios
• Silence on what happens after launch: patching, hosting, monitoring, and who is accountable
• A quote priced per screen or per feature, as if a data model and integration depth do not exist
• No named product owner on either side once the build begins

A logistics operator needing to prevent double-booked delivery slots might assume this is a simple calendar problem, priced somewhere near a website quote. Once discovery actually maps the workflow, the real requirements usually include a rules engine for slot capacity by vehicle type, a conflict-resolution process when two dispatchers try to book the same slot simultaneously, a driver-facing mobile view, and a reconciliation step against an existing accounting system — none of which a template calendar plugin handles reliably at real operational volume.

Scoped honestly, that project usually lands in Platform-tier territory rather than Automate, once multi-user roles (dispatcher, driver, admin) and a proper data model for vehicles, routes and time slots are accounted for. The discovery phase is what separates this accurate scope from the underpriced "form with a calendar" quote that looks attractive for exactly as long as it takes for the first double-booking to happen in production.

This is the pattern worth recognising in your own scoping conversations: if a workflow involves more than one type of user, real-time conflict handling, or a connection to an existing system of record, treat the low, fast quote with real scepticism rather than relief.

If you are comparing a "custom website" quote against a "custom software" quote for what feels like the same project, pause and check which category the work actually belongs to. Confusing the two is the fastest way to either overpay for a website that could have handled the job, or underpay for software that needed real engineering discipline.

Map your actual workflow this week, including the manual workarounds nobody has bothered writing down because everyone just knows them. That map is worth more to an accurate quote than any amount of guessing at a headline number.

Bring that workflow map to a discovery conversation with Nexus. We will tell you plainly whether this is an Automate-tier tool, a Platform-tier system, an enterprise scope, or (sometimes) a well-configured existing tool that solves the problem without a custom build at all.