HUB · 3 GUIDES
Custom web applications
Custom web applications built around Xero, Shopify and HubSpot. See when custom development beats off-the-shelf software, and what it costs.
Quick answer: Custom web application development builds software around a business's existing systems and workflows, chosen when off-the-shelf tools force a manual workaround.
Last updated
Quick answer
What is custom web application development and when is it worth it?
Custom web application development builds software around a business's specific workflows and integrations, and it's worth it once a packaged platform's data model starts forcing manual workarounds.
Additional Context
This threshold shows up once a business's operating model has outgrown what a packaged platform like Shopify, Xero or HubSpot can flex to support, regardless of transaction volume.
Sources
- Privacy Act 1988 overview
Sets out the small business turnover threshold and the obligations that apply once an organisation handles personal information.
- Notifiable Data Breaches Report
OAIC's published series tracking the causes and frequency of data breaches reported by Australian organisations.
Custom Software Development
What Counts as a Custom Web Application
A custom web application is software built to match a specific business process, data model and set of integrations, rather than software the business reshapes its process around. For a logistics operator this might mean a dispatch board that talks directly to a freight carrier's API and to Xero for invoicing. For a healthcare provider it might mean a patient intake portal that enforces consent capture the way the Privacy Act actually requires, not a generic form builder's assumption of what consent looks like. Custom software development in Australia typically sits alongside platforms like Shopify, HubSpot or Xero: most engagements connect a purpose-built application to two or three systems the business already depends on, using compliance-ready software architecture so the new layer meets Australian privacy obligations from the first release.
Build vs Buy: Where the Line Actually Sits
The deciding factor is whether a core piece of the operating model has to bend to fit a packaged product's assumptions. Teams that push a multi-entity billing structure or a non-standard inventory rule into a platform like Shopify or MYOB usually hit the ceiling within a year, because the platform's data model was never built for that particular business logic, regardless of transaction volume. At that point, custom enterprise software development stops being a preference and becomes the only way to remove a manual workaround someone is quietly running in a spreadsheet. Where the process genuinely matches what an off-the-shelf tool already does well, buying remains the right call: rebuilding a CRM that HubSpot already handles competently adds cost without adding capability. Getting security by design right from the first integration matters more than the framework choice, because custom applications inherit responsibility for authentication, authorisation and data handling that a vendor platform would otherwise carry.
Build vs Buy
When Off-the-Shelf Software Starts Costing More Than It Saves
Problem
Operations teams often run a spreadsheet or a manual step alongside Xero, Shopify or a CRM because the packaged tool can't quite handle a specific pricing rule, approval chain or data hand-off unique to the business.
Common Pain Points:
- Manual reconciliation between systems Someone re-keys data between Xero, a CRM and a spreadsheet every week because no system owns the full picture.
- A process the platform was never built for Multi-entity billing, custom approval chains or non-standard inventory rules get forced into a tool that assumes a simpler model.
- Growth capped by a tool's ceiling Adding another workaround stops being viable once transaction volume or complexity passes a certain point.
Business Impact:
Time Wasted: Staff hours lost each week to manual reconciliation between systems that don't talk to each other
Cost Implication: A workaround that never appears as a line item but consumes admin and finance capacity every month
Opportunity Cost: Time that could go into growth work instead goes into keeping mismatched systems in sync
Solution
A custom web application sits between existing platforms, automating the specific workflow or data hand-off that off-the-shelf tools can't handle, without replacing systems that already work well.
Our Approach:
- Map the actual workflow(1-2 weeks)
Document where staff currently work around the software, including workflows the software was never actually built for
- Design the integration points(2-4 weeks)
Define how the new application will read from and write to Xero, Shopify, HubSpot or internal databases without duplicating data entry
- Build and stage the release(Varies by scope)
Deliver the application in stages that keep current operations running, testing each integration against real data before cutover
Expected Outcome: A single accurate data source replacing parallel spreadsheets, fewer manual handoffs, and admin time redirected to higher-value work.
Key Takeaways
Custom Development Earns Its Cost When Workarounds Compound
- Custom software pays for itself where a workaround already existsImportant
If staff already run a spreadsheet or manual step to cover a gap in Xero, Shopify or a CRM, that gap is the business case for building around it.
- Integration design matters more than the framework choiceImportant
How a new application reads from and writes to existing platforms determines whether it removes double handling or just adds another system to check.
- Staged delivery keeps the business trading during the buildImportant
Replacing a workaround in phases lets operations keep running the current process while each new piece gets proven with real data before the next stage begins.
- Security obligations attach to the new application, not just the platforms around itCritical
Once a custom application stores or processes personal information, it inherits Privacy Act obligations the vendor platforms may have already handled.
Custom web applications make sense once a manual workaround has become permanent. Weigh the cost of building against the recurring cost of that workaround, not the price of an off-the-shelf licence.
What the Regulatory and Risk Data Shows
Custom applications that touch personal information inherit specific Australian regulatory obligations, and the risk profile of ageing systems is well documented by the regulator that oversees data breaches.
$3 million annual turnover
Privacy Act small business threshold
Significance: highBusinesses below this turnover are generally exempt from the Privacy Act, but health service providers and businesses trading personal information are covered regardless of size, which shapes how a custom application must handle data.
Source: Office of the Australian Information Commissioner
Published twice yearly
Notifiable Data Breach reporting
Significance: mediumOAIC's Notifiable Data Breaches report tracks incidents including human error and system vulnerabilities, a recurring category for applications running on unpatched or unmaintained frameworks.
Source: OAIC Notifiable Data Breaches Report series (oaic.gov.au)
Publicly published criteria
Digital Service Standard criteria
Significance: mediumThe DTA's Digital Service Standard sets criteria for accessibility, security and usability that private-sector reviews increasingly reference as a practical benchmark for customer-facing applications.
Source: Digital Transformation Agency - Digital Service Standard (dta.gov.au)
Methodology
Figures drawn from published Australian Government sources, the OAIC's Privacy Act guidance and Notifiable Data Breaches reporting, and the Digital Transformation Agency's published standards, current as of the last review date shown.
Delivery Approach
Where the Risk Usually Hides in Legacy Systems
A recurring pattern in system reviews: an authorisation check that has quietly returned true for every request for years, because the failure path was never exercised in testing. Nobody notices until a permissions audit or a security review surfaces it, by which point the legacy app nobody is maintaining has been holding customer data behind a check that never actually checked anything. This is the practical argument for treating custom applications as long-lived assets rather than one-off projects: the framework version at launch is rarely the framework version five years later, and dependency updates need an owner the same way a physical asset needs a maintenance schedule.
What a Typical Engagement Looks Like
Most engagements start by mapping the integration points: what the new application needs to read from Xero or a CRM, what it needs to write back, and what happens if that write fails halfway through. From there, delivery happens in stages that keep the current process running until each new piece is proven against real data, the same discipline that shaped a recent custom web application replatform, where authentication, payments and the customer portal were each staged and tested separately before the combined cutover. The result is fewer surprises at go-live, because each integration has already been tested in isolation before it carries live traffic.
What a custom web application costs
A line-of-business application replacing a spreadsheet, an access database or an off-the-shelf tool the business has outgrown. Priced for a first production release that real work runs through.
| Planning and architecture | |
|---|---|
| The process as it actually runs, the data model behind it, and the release plan that gets it live in stages rather than one long build. | |
| Process and requirements discoveryThe documented process is rarely the real one, so this is time spent with the people doing the work rather than reading the manual. | $2,000 - $5,000 |
| Architecture and delivery planThe staging of the build, so the business gets something usable early instead of waiting for everything. | $3,000 - $7,000 |
| Build and release | |
| Implementation through to a production release, with the data migration that decides whether anyone actually switches. | |
| Core applicationThe screens and rules the daily work runs through, built against the process mapped in planning. | $12,000 - $36,000 |
| Data migration and cutoverMoving the existing data in and running both systems in parallel long enough to trust the new one. Routinely underestimated and routinely what sinks a replacement project. | $3,000 - $12,000 |
| Total Investment RangeTypical project: $40,000 | $20,000 - $60,000 |
Payment Terms
Invoiced monthly in arrears against delivered scope. The Product Development Plan fee is credited against the first build invoice when the build proceeds.
Key Assumptions
- One production release; later phases are quoted as separate engagements.
- Existing data is available in an extractable form.
- Scope is fixed at the end of planning, and changes after that point are quoted separately rather than absorbed.
These are the ranges a project like this usually lands in. Answer seven questions and we will narrow it to yours.
Talk to National Digital About Your Application
Tell us about the systems you're already running and the workaround you're trying to remove. We'll assess whether custom development is the right call before recommending it.
Custom Web Application Questions, Answered
What is custom web application development?
Custom web application development means building software matched to a specific business workflow, data model and set of integrations. It typically connects to systems already in use, such as Xero, Shopify or HubSpot, covering a gap those platforms weren't designed for, such as a non-standard pricing rule, an approval chain, or a data hand-off between two systems that don't otherwise talk to each other.
How is custom software different from an off-the-shelf platform?
Packaged platforms like Shopify or HubSpot solve a common problem well and cheaply, but they assume a fairly standard process. Custom development matches the software to the actual workflow, which matters once a business's pricing structure, approval chain or reporting requirement no longer fits that standard assumption. The trade-off is that custom software carries ongoing maintenance responsibility a vendor platform would otherwise absorb.
How much does custom web application development cost in Australia?
Cost depends heavily on scope: the number of systems being integrated, the complexity of the workflow being replaced, and how much of the interface needs building versus reusing existing components. Most engagements are scoped and quoted individually after a discovery phase, with an indicative range confirmed once the integration points and data model are understood.
How long does a typical custom software project take?
Timelines vary with scope and the number of integrations involved, and are typically estimated during discovery. Staged delivery is common: an initial release covering the highest-value workflow goes live first, with further integrations following in later phases, so the business gets value early without waiting on one large launch.
Should a growing business build custom software or buy a packaged tool?
The deciding factor is whether a core part of the operating model has to bend to fit the packaged tool's assumptions. If the process is fairly standard, buying remains the sensible choice. If staff are already running a manual workaround around the software's limits, that workaround is usually the clearest signal that custom development will remove more cost than it adds.
Do you build custom software for businesses outside Sydney and Melbourne?
Yes. Engagements run for teams across Sydney, Melbourne, Brisbane, Perth, Adelaide and the Gold Coast, with delivery managed remotely and discovery workshops run either on site or online depending on the business's preference. Location affects logistics for workshops, not the standard of the integration work or the security review applied to the finished application.