Bare Metal Hosting Provisioning: Buy WHMCS, Adopt Ironic, or Build the Product Layer
The threshold is roughly 150 physical servers with a fairly uniform hardware mix and provisioning volume one technician handles comfortably.
On this page
The threshold is roughly 150 physical servers with a fairly uniform hardware mix and provisioning volume one technician handles comfortably. Below it, buy WHMCS or HostBill with a provisioning module, or Ubersmith once billing complexity grows, and accept the manual residue as cheaper than an engineering programme. Most providers at that size should. Above it, the answer is almost never writing a boot and imaging engine from scratch. It is adopting Canonical MAAS, OpenStack Ironic or Tinkerbell as the machine lifecycle core and building the product layer on top, at $90,000 to $180,000 over 14 to 20 weeks.
When is off the shelf genuinely the right call here?
Buy, and here is which one. WHMCS and HostBill will run your ordering and billing, and their provisioning modules cover the common cases well enough that a provider under roughly 150 servers with a narrow hardware mix should stop there. Ubersmith is the stronger option once billing complexity grows, because it carries more infrastructure awareness than the others and understands that a service is attached to a physical thing.
Buy and stop there if provisioning volume is one technician's routine rather than a bottleneck, and if your idle unreclaimed inventory is small enough not to show on a power bill. At that shape the manual residue is genuinely cheaper than owning automation, and the automation would need maintaining forever against a hardware estate that keeps changing.
Keep your billing system whatever else you decide. WHMCS, HostBill or Ubersmith can stay as the commercial front end while you build the provisioning brain behind it with a clean interface between the two. That defers the entire billing integration line, keeps you inside the first band, and lets you prove the pipeline before you commit to replacing anything commercial.
There is a fourth case where buying is right for an uncomfortable reason. If your fleet is deliberately heterogeneous because you buy whatever is cheap at auction, automating it is expensive and the automation ages badly. Either accept manual provisioning as the cost of that purchasing strategy, or change the strategy first. Standardising the fleet before you automate saves more than any other decision available here, and it costs nothing at procurement time.
When does a custom build actually pay off?
Build when provisioning lead time has become a competitive problem. An order that arrives on Friday and produces credentials on Tuesday looks broken to a customer who has used a public cloud, and no amount of explanation about racking recovers that first impression. If you are losing deals on delivery time rather than price, the pipeline is the product.
Build when idle unreclaimed inventory is visible on your power bill. Reclaim has more steps than provisioning and none have a customer waiting: power down, sanitise drives, reset the storage controller, rotate management credentials, restore firmware baseline, remove network configuration, return addresses to the pool, validate. That ticket always loses to work with a deadline, so machines sit powered and earning nothing. In most providers we have looked at, that pool is larger than the operations team believes.
Build when customers are asking for an interface because they want to script their own capacity. That request is usually the commercial reason for the whole project rather than a bonus, and it cannot be answered on top of a workflow that still needs occasional manual repair.
Build when your existing automation is a pile of scripts maintained by one engineer. That is the most common trigger and the most urgent, because those scripts encode your operational knowledge and they are undocumented by definition.
How do they compare on the things that matter in this industry?
Machine identity. Automation starts with knowing what you have, and hand assembled data decays. A machine that boots a discovery image over the network and reports its own hardware inventory, combined with neighbour discovery telling you which switch port it landed on, removes the most common cause of provisioning failure: a correct configuration applied to the wrong port. MAAS does this genuinely well and is worth studying even if you do not adopt it.
Failure behaviour. A shell script runs steps in order and will eventually configure a virtual local area network and then fail at imaging, leaving a machine in a state nobody can describe. What survives a real data centre is a state machine with idempotent steps, explicit retries and a visible per machine timeline. Ironic and Tinkerbell both provide credible engines for this and are reasonable things to build on rather than reinvent. Ironic is powerful and proven but carries operational weight and expects an environment shaped around it. Tinkerbell is lighter and workflow oriented, which makes it a component rather than a product.
Tenancy. This is where the open source options stop, and the gap is not a feature list. MAAS assumes an internal fleet on a network model it controls, with no concept of a customer, an order, an entitlement, a contract or an invoice. Isolation between customers on shared physical infrastructure is a switching problem, and getting it wrong does not produce a small error, it produces one customer able to see another's traffic. That is your business model and no product will encode it for you.
Reclaim. Neither the billing platforms nor the open source engines own the reclaim loop end to end, which is exactly why it is where the money sits.
Read back verification. Writing a switch configuration and assuming it took is how a machine ends up on the wrong network and stays there until traffic reveals it. Treat verification as mandatory whichever route you choose.
What does total cost of ownership look like at your scale?
Your billing platform renewal is not the comparison, because you are keeping it. The comparison is two numbers you can gather this week without asking anyone for a budget.
Count the machines currently powered, unallocated and not in stock because nobody triggered a wipe, and multiply by your own power cost per server per month. Then add the machines you would have sold from that pool rather than purchasing new. Second, measure the median hours between order and credentials over the last quarter, and put a figure on the deals lost to that number. Those two together are the business case, and the reclaim loop alone frequently justifies the first band.
On the build side, a first release covering discovery based hardware inventory, the provisioning state machine with switch and image automation, address management and the reclaim loop runs $90,000 to $180,000 over 14 to 20 weeks in Digital Heroes delivery experience. Customer facing self service with a public interface, stock aware ordering, private networking and hardware validation takes the total into the $200,000 to $340,000 range. The full platform with border gateway protocol sessions, customer address space, out of band console access, an image catalogue and a second facility runs $340,000 to $500,000 across 6 to 12 months.
A provider with roughly 1,200 servers in one facility, three server vendors with mixed firmware generations and two switch vendors, lands at $180,000 over about nineteen weeks. The largest single line in that build is the out of band abstraction at $38,000, which surprises clients every time and is the line that decides whether the platform is reliable or merely demonstrable. Discovery is $16,000, switch automation across two vendors $26,000, imaging $24,000, address management $18,000, the state machine $30,000, reclaim $16,000, and load testing and handover $12,000.
Afterwards, budget 18 to 25 percent of build cost a year, higher than most categories for a specific reason: your hardware estate keeps changing. On that example it is roughly $32,000 to $45,000, covering each new server generation you buy, firmware pushes that change controller responses, switch and topology work, base image patching, control plane hosting at $6,000 to $20,000, and an annual security review of a system that can reimage any machine you own.
What does the hybrid look like, and when is it the honest answer?
Buy the platform, build the thin layer you actually need. Here the hybrid has two halves rather than one, and both matter.
The commercial half: keep WHMCS, HostBill or Ubersmith as the front end for ordering, invoicing and customer accounts, and build the provisioning brain behind a clean interface. This defers the entire billing integration line and lets you prove the pipeline against real orders before anything commercial is at risk.
The engineering half: adopt MAAS, Ironic or Tinkerbell for the machine lifecycle mechanics rather than writing your own. Enlistment, commissioning, power control, boot order and imaging are unglamorous to rebuild and already solved better than a bespoke effort will manage. The engine is maybe a third of the work. The product around it, meaning catalog, order lifecycle, tenancy isolation, reclaim policy and the customer interface, is the rest, and it is the part nobody sells you.
The trade is honest and worth naming. Adopting an open core means less control over edge cases in the provisioning path, which matters if your hardware estate is unusual. If two thirds of your machines are one vendor and one generation, automate those on top of an open core first and handle the remainder manually while they age out.
Sequencing keeps the number down as well. Defer the public interface until internal automation has run against real orders for a few weeks, because an interface exposes every failure mode directly to the customer and produces support tickets faster than revenue.
Which should you choose, by operator size and stage?
Under roughly 150 servers, uniform hardware. Buy WHMCS or HostBill with a provisioning module and a few scripts. Nothing about your shape justifies a platform and the manual residue is genuinely cheaper.
150 to 500 servers, growing, one or two hardware vendors. Stay bought and do the free work. Inventory your controller vendors and firmware generations, because that list is the actual scope of any future build. Then standardise your next two purchasing cycles on one vendor family, which is the cheapest software decision a hosting provider ever makes.
500 to 1,500 servers, multiple hardware generations, scripts held by one engineer. This is the crossover. Adopt an open core, build the first band covering inventory, the state machine, address management and reclaim. Take reclaim seriously rather than treating it as a phase two nicety, since it is where the fastest payback sits.
Above 1,500 servers, or any provider selling an interface as a product. Build the first band, run it internally for a few weeks, then extend to self service, private networking and validation. Insist on load testing at realistic concurrency inside the fixed scope, because a pipeline that works for one machine and falls apart when forty orders arrive on a Monday morning has not solved the problem you paid to solve.
Whichever band you land in, get your controller vendor and firmware inventory before requesting quotes, and price each additional controller family and switch vendor as a named line. That way you can decide what to automate and what to retire rather than discovering the cost in month three.
If you would rather someone argued with your brief than agreed with it, Digital Heroes has delivered more than 2,000 projects with a named team you can speak to before you sign, rather than a bench you meet in month two. Nothing about that commits you to the build.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- Technical debt is the number-one frustration at work for professional developers, cited by about 63% of respondents - roughly twice the rate of the next-most-common frustration (complexity of tech stack, ~33%). Source: Stack Overflow (2024) →
- The average developer spends more than 17 hours a week dealing with maintenance issues such as debugging and refactoring, and about four of those hours on 'bad code' - waste that equates to nearly $85 billion annually worldwide in opportunity cost. Source: Stripe (2018) →
- McKinsey found that currently demonstrated technologies can fully automate about 42% of finance activities and mostly automate a further 19%, indicating roughly 60% of finance work is technically automatable. Source: McKinsey & Company (2018) →
- Gallup reports global employee engagement fell to 20% in 2025 (its lowest since 2020, down from a 2022-2023 peak of 23%), and estimates low engagement costs the world economy an estimated $10 trillion in lost productivity, or 9% of global GDP. (Note: this figure appears in Gallup's evergreen State of the Global Workplace page, currently reflecting the 2026 edition reporting on 2025 data.). Source: Gallup (2025) →
Frequently asked questions
What does it cost to switch off WHMCS or HostBill?
In the recommended shape you do not switch. The provisioning platform sits behind your existing commercial front end with a clean interface between them, which defers the entire billing integration line and keeps you inside the first band.
If you eventually move, the cost is customer, service and invoice history rather than configuration. Confirm you can export those in a usable structure before you depend on any platform, since that is the part a billing vendor is least motivated to make easy.
What happens if our hardware vendors change firmware behaviour?
This is the recurring cost that makes this category unusual, and it is why annual maintenance sits at 18 to 25 percent of build cost rather than 12 to 18. A firmware push can renumber registers or change a controller response, and provisioning then breaks quietly and is discovered by a customer waiting for a machine.
Budget it as a standing line tied to your purchasing cycle, and insist that machines of every controller family are available to the team for regression testing rather than only at build time.
How long does a bare metal provisioning build take?
Fourteen to twenty weeks for a first release covering discovery based inventory, the provisioning state machine, address management and reclaim, then six to twelve months in total for the full platform with a customer interface, private networking and billing integration.
The schedule is usually paced by access to representative hardware rather than by engineering. Make sure machines of every controller family and both switch vendors are available to the team from week one.
Should we build on MAAS, Ironic or Tinkerbell instead of from scratch?
In most cases yes, and we recommend evaluating them seriously rather than as a formality. They handle machine lifecycle mechanics that are unglamorous to rebuild, which lets your budget go into the commercial and workflow layer that differentiates your hosting business.
MAAS has an excellent enlistment and commissioning model but assumes an internal fleet with no notion of customers or orders. Ironic is proven and carries operational weight. Tinkerbell is lighter and workflow oriented. None of them supplies catalog, tenancy, reclaim policy or billing.
Why does hardware diversity cost so much?
Because out of band management controllers from Dell, HPE and Supermicro implement Redfish differently, and generations inside one vendor differ too. Each family needs its own handling for power control, boot order and error behaviour.
In our worked example the out of band abstraction was the single largest line at $38,000 out of $180,000. Three controller families is roughly double the integration work of one, and older machines without usable Redfish need an IPMI fallback that has to be maintained permanently.
Can we build the reclaim loop on its own?
It is the strongest candidate for a narrow first move and it sits at roughly ten percent of a first band build, around $16,000 in the worked example, though it depends on the inventory and controller abstraction underneath it.
The payback is unusually direct. The machines are already bought, already racked and already consuming power, so converting idle inventory back into sellable stock without a technician touching it is revenue you do not have to purchase hardware to earn.
How should drive sanitisation work between customers?
Decide it explicitly rather than inheriting a default. NIST Special Publication 800-88 gives the accepted vocabulary of clear, purge and destroy, and which one you owe depends on your contract terms and your customer's compliance regime.
Encrypting at rest with per tenant keys makes cryptographic erase fast and defensible, which matters commercially because multi hour overwrite passes on large drives keep a machine out of revenue. Rotating management controller credentials is non negotiable in every case.
What is the cheapest credible version of this platform?
Around $90,000 for a provider with one server vendor family, one switch vendor, a clean recent hardware estate, and an open source provisioning core adopted rather than written. That buys discovery based inventory, the state machine, address management and reclaim.
Be sceptical of anything cheaper that answers a failure at step six of nine with the word retry. Ask what makes step three safe to run a second time. Idempotency is the whole design, and a developer who has not thought about it produces something that works in a demonstration and needs a technician every week in production.
We run everything on spreadsheets and Airtable. How do we know it's time for custom software?
The reliable signals are re-typing the same data into multiple tools, one employee acting as human middleware between systems, and errors appearing in handoffs between teams. Hard limits force the issue too: Airtable's Team plan caps at 50,000 records per base, and Business costs $45 per seat per month, so a 20-person team pays about $10,800 a year for a tool it has already outgrown. When workarounds consume more hours than the tools save, the spreadsheet era is over.
We run everything on Airtable and spreadsheets. When is it time to go custom?
The switch usually makes sense when you hit one of two walls: Airtable's record caps (125,000 records per base on the Business plan) or logic the tool cannot express, like multi-step approvals with conditional pricing. There is also a simple cost signal: 25 people on Business at roughly $45 per seat per month is about $13,500 a year, forever, for a tool you are already fighting. Custom is worth it when the workflow is core to how you make money; for peripheral processes, staying on Airtable is the right call.
If an agency builds my software, who actually owns the code?
You should own everything, assigned in writing: the contract transfers full IP to you on final payment, the code lives in your GitHub organization, and hosting runs in cloud accounts you control. The red flag is a proposal that mentions the agency's proprietary platform or framework, which usually means you are renting, not buying. Digital Heroes structures every build this way precisely so a client can fire us and lose nothing but the relationship.
Does it matter which tech stack the agency wants to use?
Yes, but not in the way most buyers expect: the goal is boring, popular technology such as React, Node.js or Python, and PostgreSQL, because any future team can maintain it and hiring a replacement developer takes days, not months. The red flag is an agency-proprietary framework or an unusual language, which welds you to that one vendor no matter what your contract says about code ownership. A useful test: could you find three freelancers fluent in this stack within a week? If not, push back.
What happens to my software if the agency shuts down or we stop working together?
Nothing dramatic, if the engagement was set up correctly: the code sits in your repository, hosting runs on your cloud account, and a handover document explains how to deploy and operate the system. Any competent replacement team can then take over in days rather than months. If the agency controls the repo, the servers, or the domain, fix that now, because renegotiating access during a dispute is the most expensive place to discover the problem.
How do I calculate whether custom software will pay for itself?
Divide the build cost by the monthly benefit, where benefit is hours saved times loaded hourly cost, plus subscription fees replaced, plus any revenue the software unlocks. Three staff saving 10 hours a week each at a $40 loaded rate is about $62,000 a year, which pays back a $60,000 build in roughly 12 months. Across Digital Heroes internal-tool projects, 12 to 24 months is the normal payback range, and anything projecting under 6 months usually means the spreadsheet is hiding costs.
Will an app built for 10 users survive growing to 500?
Yes, if it is built on standard cloud infrastructure with a sound data model, because moving from 10 to 500 users is a hosting configuration change, not a rebuild. The scaling decisions that actually hurt are made early and invisibly: how the database is structured, how accounts and permissions are modeled, and whether background work is queued properly. Ask your agency how the system would handle ten times the load; the right answer is boring and specific, and a promise to cross that bridge later means you will pay for the bridge twice.
Does the tech stack matter, and which one should I ask for?
It matters less than agencies imply, provided it is boring. A mainstream stack, something like React or Next.js on the front end, Node.js or Python behind it, and PostgreSQL for data, means thousands of developers can maintain your system if you ever change vendors. Apply one test: ask how hard it would be to hire a replacement developer for the proposed stack, and walk away from anything built on an agency's in-house framework.
How long does it take from first call to software my team can actually use?
Plan for four to six months: two to three weeks of discovery, two to four weeks of design, then a 10 to 16 week build with testing. In Digital Heroes delivery experience the schedule killer is not engineering speed but decision lag; a client who takes two weeks to approve wireframes adds two weeks to launch. Book a weekly 30-minute decision slot before kickoff and most of that risk disappears.
Who can build a custom software system?
Digital Heroes builds custom software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
Related guides
Published · Last updated .