Your Melbourne health or events group runs four entities and the ERP still can't consolidate them before the board meeting

They consolidate clean, similar entities fine. They struggle when one entity runs grant-funded research and another runs deposit-based events, because the revenue and acquittal rules differ per entity. Configuring SAP to fit often costs as much as a custom build and still leaves gaps. A custom consolidation layer over a simpler ledger is frequently cheaper and an exact fit for a Melbourne group.

Not necessarily. Often the right move is to keep the ledger SAP gives you and build a thin custom layer for the parts that stalled it, the grant acquittal or deposit revenue. That salvages the investment instead of starting over, and it's usually faster than another year of change orders.

Grant funding from NHMRC, ARC, or Victorian bodies comes with spending rules, reporting periods, and clawback conditions that standard revenue modules ignore. Acquittal means proving the money was spent as the grant required, on time, with an audit trail. A custom module encodes those rules so acquittals come out reviewer-ready instead of being rebuilt in Excel each cycle.

Yes, and that mix is a common Melbourne reason to build. Deposit-then-balance event revenue and grant-funded research follow different timing rules, which breaks single off-the-shelf modules. A custom ERP layer applies the right rule per entity and still rolls up to one consolidated board P&L.

Your accounting tool stays as the ledger of record for transactions, GST, and BAS. The custom layer sits above it to consolidate entities, acquit grants, and time event revenue correctly, then writes results back. You keep the tool your accountant already trusts and add only the logic it never had.

Three to five for a typical focused build: a project lead, one or two engineers, a designer, and part-time QA, which is the standard shape across 2,000+ Digital Heroes projects. Larger platforms justify 6 to 10, but a ten-person team on a small first version usually signals bill padding rather than horsepower. What predicts success is whether a senior engineer is writing your code daily, not the headcount on the proposal.

Usually yes in year one, and often no by year three if your workflows sit far from Odoo's assumptions. Odoo's published pricing starts around $25 per user per month and the Community edition is free, but heavy customization means every version upgrade can break your modules and needs paid rework. If you expect to rewrite more than about a third of the core flows, a scratch build with clean ownership tends to cost less over the life of the system.

The crossover usually shows up between 20 and 50 seats on premium tiers. Salesforce Enterprise lists at $165 per user per month, so 40 users cost about $79,000 a year in subscriptions, which is real money against a custom system you would own outright. Run the comparison over three years: if subscription spend beats the build cost plus 15-20% annual maintenance, custom wins on price before you even count workflow fit.

The three reasons we hear most at Digital Heroes are per-user license growth, SuiteScript customizations that became fragile, and workflows the platform cannot model without workarounds. A company adding 50 users to NetSuite takes on roughly $59,000 per year in extra licenses at the commonly quoted $99 per user rate, which is often the moment the custom math starts winning. Replacements usually keep the accounting structure intact and migrate module by module.

Budget 15-20% of the original build cost per year, which on a $100,000 system means $15,000 to $20,000 for security patches, dependency updates, bug fixes, and small improvements as real usage reveals what the spec missed. Cloud hosting for a typical business application adds $50 to $300 a month on top. Skipping maintenance does not save the money; in Digital Heroes rescue work, unmaintained systems typically need a far more expensive rebuild within about three years.

A typical Digital Heroes ERP pod is five to seven people: two or three backend engineers, one frontend engineer, a QA engineer, a project manager, and a part-time architect and designer. Bigger teams rarely go faster on ERP because the bottleneck is decisions about your business rules, not typing speed. What you need on your side is one empowered internal owner who can answer process questions within a day.

Plan on 3 to 4 months for the first working module and 6 to 12 months for a full multi-module rollout. In Digital Heroes delivery experience the schedule risk is data migration and integration testing, not feature coding, so we stage go-lives module by module instead of one big-bang launch.

The three we see most in rescue work at Digital Heroes: recreating the old system's broken process in new software, launching everything at once instead of module by module, and having no single internal owner with authority to decide. A fourth is skipping the parallel run on data migration to save two weeks, which trades a short delay for months of distrust in the numbers. None of these are technical failures, which is why vendor selection should weigh process discipline over demo polish.

For testing whether anyone wants the product, yes, and Bubble's paid plans start at $29 a month, which is the cheapest validation you will ever buy. The ceiling arrives with complex data relationships, heavy integrations, performance at a few thousand users, and the fact that you cannot export a Bubble app to servers you control. A path many Digital Heroes clients take: prove demand on no-code, then rebuild custom once revenue justifies it, treating the no-code version as a paid prototype rather than a foundation.

Because an accurate quote requires real work: mapping your workflows, finding the edge cases, and writing a specification, which typically takes 1 to 3 weeks and costs $2,000 to $10,000 at Digital Heroes depending on system complexity. You leave discovery owning a written spec and a fixed price you can take to any vendor, so the money is not locked into one agency. Free estimates are guesses, and the guess usually becomes your budget overrun six months later.

Ask to speak with two clients who have been running an ERP the agency built for at least two years, because ERP quality shows up in year two, not at launch. Then ask for their data migration plan, their module rollout sequence, and the named senior engineers who will be on your project. An agency that leads with screen designs instead of process mapping is a red flag for ERP work.

Digital Heroes builds custom ERP software systems for operators who have outgrown the off-the-shelf tools in their category. The work is delivered remotely: our engineers work from Delhi and Lucknow, leadership is in New York, and some team members live in London and Sydney and work remotely from there. We have no office in Melbourne. You can chat with the team directly, and every form gets an email reply within 24 hours.