The business case for building vs. buying removals software

The work hiding between an idea and a development ticket

Recently, I spoke with a company that moved to Movepro after abandoning its own software project. They told me they had spent around $150,000 with developers before deciding to bin the whole thing.

That is one company’s account, not an industry failure statistic. But it illustrates something I believe is routinely underestimated:

Knowing how your business works is not the same as being able to specify how software must work.

Much of an experienced operator’s knowledge is tacit. It comes from recognising exceptions, making judgement calls and understanding what customers or staff actually mean.

Turning that knowledge into software requires someone to extract it, document it, resolve ambiguities, communicate it to developers and validate that the finished system behaves correctly.

Take a seemingly simple instruction: “Let staff reschedule a job.”

Does the packing service move too? What happens to the crew allocation? Does the price change? Should the customer receive a notification immediately, or only after approval? What happens if another staff member is editing the same booking? What if the crew has already downloaded the original instructions?

The developer cannot reliably infer all of that from a sentence.

The removals industry is full of these edge cases. You can “vibe code” something that appears to do 80% of what you need. But that apparent remaining 20% is not necessarily 20% of the work. It includes the exceptions, corrections and interactions that determine whether the system can be trusted.

An edge case in a demonstration can be a very ordinary problem on a busy Monday morning.

What rebuilding Muval taught me

I experienced this firsthand between 2021 and 2023, when we rebuilt the system that ran Muval.

I had built the first version myself over time, gradually adding bits and pieces as we needed them. Now, I am an average software engineer at best. By mid-2021, the whole thing was held together with proverbial sticky tape and needed a thorough rebuild.

I knew it was not a small task. But we already had a working version of what we needed. We were not inventing the business from scratch. We just needed the software rebuilt in a more robust way.

The next two years were hell.

The biggest problem was all the small assumptions embedded in my code that had never been made explicit to the new development team. Decisions I had made while building the original system reflected how the business worked, but that knowledge had not been translated into a clear specification.

We were still 18 months into the rebuild when fundamental requirements were being raised that the development team had not known about.

It was incredibly stressful and costly to the business.

And all of that happened with an existing system that already did what we needed. We had working software to inspect and real processes to follow.

Imagine the difficulty of starting with nothing more than the picture in your head.

My lesson was not that developers are incapable, or that rebuilding was necessarily the wrong decision. It was that working software is not automatically a complete specification for its replacement . Somebody still has to discover and explain the business logic.

What would it cost to build a moving company’s operating system?

To make the comparison concrete, consider a hypothetical moving company generating $25 million in annual revenue, operating across multiple depots, with more than 80 trucks and 750 containers. I use these numbers because its probably about the size of the business where the question of "build" starts to come up after scaling beyond a simple operation. People are usually tempted to vibe code something in the early days of starting, then need a reliable system to scale, and then once they scale start to get tempted to build something purpose-built for themselves as they now have the resources to do it "properly".

The brief is not a booking calendar or a basic customer database. It is an integrated platform covering enquiries, quoting, scheduling, crews, subcontractors, interstate movements, container tracking, storage billing, payments, accounting integrations and reporting.

It also includes Android and iOS crew apps, with job information, time recording, photos, condition reports, signatures and offline working.

Both build scenarios assume a shared mobile codebase released on both platforms, rather than two entirely separate app teams. They also assume integration with existing accounting, payroll and payment providers, rather than rebuilding those services.

Most importantly, both include a full-time business analyst or product lead, supported by operational specialists. That person owns process definition, requirements, developer briefings and business acceptance. Their time is not treated as free.

The Movepro example uses an assumed price of $3,500 per month including GST, covering the required deployment. It is not a universal advertised plan. Required users, trucks, containers, apps and services must be confirmed in a written quote. See Movepro’s pricing information for current plan and capacity arrangements. The $50,000 allowance is for implementation, data preparation, training and internal change management; it is not a quoted Movepro onboarding fee.

Five-year totals include build costs followed by three years of ongoing costs for onshore, and three and a half years for offshore. Movepro includes five full years of subscriptions plus implementation. Build-period staffing is not counted again as maintenance. Prices are held constant. Financing, inflation, unmodelled transition disruption, ordinary business administration, shared third-party services and usage-based fees are excluded.

The different build durations are assumptions, not a claim that offshore developers are inherently faster. I would expect both teams to use AI tools. And these are business-wide rollout targets, not promises: pilots should start earlier, while delays require additional funding.

Scenario one: build with an onshore team

The strongest case for an Australian team is proximity to the operation. Developers and product staff can visit depots, observe warehouse processes and work directly with the people making operational decisions.

For a complicated business, that access can be valuable. It gives the team an opportunity to discover what is missing from a brief, rather than simply build what the brief says.

The advantages: direct collaboration, local accountability and control over priorities. The platform can be designed around the company’s chosen operating model rather than a broader market.

The disadvantages: the largest budget, a substantial management commitment and ongoing responsibility for everything the team creates. Local developers still need clear requirements, testing and operational decisions. Geography does not eliminate misunderstanding.

I would consider this approach when the business has a genuinely distinctive operating model, can fund a permanent technical team, and has identified a specific onshore team whose capabilities justify the premium.

“We need our own software” and “every developer needs to be onshore” are two separate investment decisions.

Scenario two: build with AI and offshore developers

This is the strongest financial version of the full-build argument: retain business ownership and technical leadership close to the operation, while using offshore engineers to lower the cost of delivery.

In this model, the team includes web and backend developers, dedicated mobile capacity, testing, Australian technical oversight and a full-time business analyst or product lead. The latter has a planning allowance of approximately $15,000–$20,000 per month, with additional time from finance, dispatch, warehouse and depot staff.

That is materially different from hiring a few developers and asking the owner to brief them whenever there is a spare hour.

The advantages: lower engineering expenditure than the onshore scenario, control of the software and the ability to focus development on one business. There is no requirement to build every feature needed by every removalist.

The disadvantages: the business still owns requirements, quality, releases, support and continuity. Lower developer rates do not remove the cost of deciding what to build or checking whether it works.

The central estimate is $1.4 million over 18 months, within a planning range of roughly $1.3–$1.5 million. Extending delivery to 24 months while retaining broadly the same team takes the allowance towards $1.7–$2 million.

Where AI helps and where I would not rely on it

I would use AI for initial code, test drafts, migration scripts, documentation and investigating defects. But I would not remove the product lead or testing budget on the assumption that AI can fill in missing business knowledge.

The key questions remain: what should happen, what must never happen, who can authorise a change, and how will we know the result is correct?

Mobile apps make those questions particularly important. Flutter’s offline-first guidance illustrates the need to decide how local changes are stored and synchronised with the central system. For a moving company, that means resolving situations such as dispatch changing a job while the crew is working without reception.

A faster way to write code is valuable. It is not a substitute for knowing which code the business actually needs.

Scenario three: use Movepro

Buying changes which responsibilities the moving business retains. Instead of commissioning the entire platform, it selects and configures an existing product, migrates its data, trains its staff and validates the workflows.

Movepro brings together sales, scheduling, customer communications, storage and financial workflows. Its field and fleet tools connect crews with job information, time recording and inventory and condition reporting.

The advantages: a much lower initial investment in this scenario, an earlier route to operational use, and access to a product whose ongoing development is shared across customers rather than funded by one moving company.

The disadvantages: you do not control every product decision. Some workflows may require configuration, an integration, a process change or functionality that is not yet available. Supplier reliability, support, pricing and data portability all deserve scrutiny.

Buying is not effortless. Someone still needs to make process decisions and lead implementation. The difference is that they are implementing a platform rather than specifying and validating every underlying feature from scratch.

The purchase should depend on testing the difficult workflows: partial deliveries, inter-depot container movements, changing storage charges, accounting corrections and offline crew activity.

A platform that covers most of a feature list can still be the wrong choice if it cannot support one business-critical process. That is as true of Movepro as it is of any other supplier.

The strongest argument for building should be profit, not avoiding a subscription

For a $40 million business, a modest improvement in operating performance can be worth serious money. A proprietary approach to pricing, fleet utilisation or container planning could justify a substantial technology investment.

But the comparison must be against a well-implemented purchased platform, not against the spreadsheets or legacy systems currently causing frustration.

Suppose replacing the current systems would generate $900,000 a year in improvements. If a purchased platform delivers $650,000 of that, the custom system’s additional benefit is $250,000, not $900,000.

Under the five-year model above, the offshore build needs roughly $651,000 a year in additional operating benefit beyond Movepro during the three and a half years after rollout to recover its cost premium. The onshore case needs approximately $1.89 million annually over the three years after its rollout.

Those are calculated break-even hurdles, not predicted savings. They are measured before the software costs already included in the model and assume benefits begin at full rollout. Financing and an allowance for investment risk would raise the hurdle.

An offshore build producing $1 million of genuine additional annual benefit would finish approximately $1.22 million ahead over those five years. That is a credible reason to investigate building.

But the claimed benefit needs evidence. An advanced optimisation capability also needs its own scope and budget; it should not be used to justify a project that only funds a conventional operations platform.

Build because you have a better way to operate that requires proprietary software not simply because you can imagine software built around your preferences.

Owning the code is not the same as eliminating dependency

One understandable objection to buying is: “I do not want to be dependent on a software company.”

But a custom build creates different questions. Who understands the system if the lead developer leaves? Can another team take it over? Who restores service before the trucks leave if an overnight release causes a problem?

Those are responsibilities I would explicitly budget for, alongside hosting, testing, security work, integrations and app releases. That is why the model retains an ongoing team rather than treating launch as the end of the expenditure.

Buying has dependency risks too. Ask the supplier about support, recovery arrangements, usable data exports and the practicalities of leaving. Neither option deserves a free pass.

The decision is not between dependency and independence. It is between different dependencies and different responsibilities for managing them.

A better middle ground: buy the foundation, build the difference

The choice does not have to be between accepting inflexible software and rebuilding an entire operating system.

At Movepro, we are developing an open API and broader platform layer intended to give businesses more flexibility to connect systems and customise workflows.

The direction is to let a moving company use its own developers where they can create a genuine advantage, while Movepro supplies the operational foundation.

That might involve a specialised reporting interface, a customer-specific workflow or a proprietary planning tool. Those are examples to assess against the available integration capabilities not promises that every proposed customisation is already supported.

We should be explicit about what is available today, what needs an integration and what depends on future development. An important operational decision should not rest on a vague roadmap promise.

This middle ground also has limits. If the competitive advantage requires fundamental changes to how the core platform records and processes work, an add-on may not be enough. A fragile collection of workarounds is not a good substitute for a genuinely necessary custom system.

But where the separation works, the question becomes much more useful: why fund the recreation of every standard feature when your developers could concentrate on the few capabilities that make your business different?

Consider the growth opportunity, not just the operating cost

There is another part of our direction worth including in the discussion.

Muval is planning a move towards a lead-aggregation model, with the intention of giving preference to Movepro customers. Our ambition is to help moving companies win work as well as manage it.

That is a future strategic direction, not a guarantee of lead volume, exclusive access or revenue. The value to any operator will depend on how the model develops, relevant demand and their ability to convert opportunities.

I would not put guaranteed income against it in a build-versus-buy spreadsheet today. But it is a potential commercial benefit of the relationship that is separate from the software functionality. Building your own system does not, by itself, create that source of customer demand.

My recommendation: prove the need to build before funding the whole system

I would start with the three or four workflows driving the desire to build. Test them properly against the purchased alternative. Identify what already works, what needs configuration and what represents a genuine gap.

Then compare a fully scoped implementation and any targeted custom development with the full-build proposal. Include the product lead, operational staff time, mobile apps, migration, ongoing ownership and the cost of a longer delivery period.

If the evidence still supports a full build, fund it in stages. Prove the distinctive capability with real operational data before committing to replacing every system across every depot.

For the hypothetical business in this article, my starting recommendation would be to buy the core platform if it passes the operational tests, implement it thoroughly and reserve development spending for the capabilities that create a measurable advantage.

I have built software myself. I know why it is tempting. I also know how much of the work sits between an apparently obvious requirement and a system people can trust.

The aim should not be to own the most code. It should be to run a better moving company.