Why is Hauler Software So Old & Expensive
In a world where some software is free, and some very useful and feature rich software is less than $100/mo, why is software in the hauler space so expensive? Not only is hauler specific software expensive, but much of it still available on the market today is old, sometimes decades old. Why is this?
This article seeks to provide answers to these questions. Hopefully the reader will gain an understanding of the costs of software development, and come to realize that when hauler specific software functionality is desired, it will not come cheaply. A look into the economics of a software business will hopefully shed some light on why the legacy software companies aren’t changing their products in big ways, even when new up and coming software companies are attempting to provide even better, more modern products.
The Costs of Developing Software
Why is it so expensive?
There’s a saying in software development: “There’s cheap, fast, or good. Pick 2.”
You can have cheap software fast, but it likely won’t be any good. You can have good software cheap, but it likely won’t be a fast build (too few developers, or under skilled developers vs. a “good” scope). To build software “good and fast”, you need excellent developer talent, and this costs money (it won’t be cheap).
Either way, good software is expensive (or slowly made over many years). Bringing software to market in a timely fashion (“fast”) is expensive. Very expensive. While this article is not intended as a full on course in software development, it will outline in a broad way the costs associated with developing a commercially viable niche application designed for business use in a specific market. Before we dig deeper into the costs of building an enterprise or commercially viable software, let’s take the time to distinguish between a simple application to be used as a one-off (a partial solution for a single company), and an application designed for commercial use.
We’ve all got that buddy or relative who can write software. That developer might be truly talented. He or she might be able to write the functionality required to (partially) meet the needs of a single organization for a fairly low cost (less than $100k, let’s say). OK. But, there’s a huge difference between a commercial application, and a one off that’s not designed to be sold, supported, or expanded in the future. Plus, what happens when your nephew wants to get married and raise a family? Will he have the time to meet the needs of the organization?
An application designed for commercial use must meet a myriad of needs. The application must:
- Allow for multiple companies to use the product, sometimes referred to as “multi-tenant”, whereby each client/company has their own separate instance of the application.
- The client/companies using the software will have employees and customers who may be using the software in different ways, sometimes referred to as “roles and permissions.”
- Be viable across a broad range of operating systems, browsers, and mobile devices.
- Meet commercially acceptable security and compliance standards, or be subjected to data breaches and lawsuits.
- Be supported for existing users in a manner and time frame acceptable in the industry (the business operates when nephew goes on his honeymoon!).
- Meet the needs of the present and future.
- More
The result is an application that’s orders of magnitude more complex than a one-off. For a comparison, a small travel trailer has a kitchen, a bed, and a bathroom, but is it a long-term viable housing option? Is it readily expandable, durable for the long-term, or usable by many people at the same time? No. A large enough house with a foundation, sturdy construction, and long-lasting materials is needed vs a flimsy, built-for-lightness travel trailer. Sorry nephew, your light-duty application just won’t cut it for the long-term, or for commercial use.
In fact, software development is a lot like building a house; it takes a lot of planning, and requires many trades and talents. To begin a homebuilding project, the project specifications must be discussed. Those specifications may be vast and complex. Discovery is often required to determine if there are any roadblocks to the project’s viability. Roadblocks can be technical/structural, legal, cost-related, a big rock discovered during excavation, and more. Many studies are often required to ensure compliance with applicable laws, and permits are required before construction may begin. The scoping work in advance of actual construction should, pending surprises, determine the full scope and cost of the project.
Scoping a software application is very similar. Asking the right questions takes time and deep insight into software development itself, but also the application’s intended marketplace. Like the home’s architect, scoping a large software application can range from 5% – 20% of the total application’s cost. It’s very important to “measure twice and cut once” in software development, just like in construction. The costs of getting it wrong at the initial phases of the build could literally sink a software company, for it’s not only getting the initial application built correctly, but also accounting for feature expansion in the future, and the total life cycle costs of the build.
These are just some of the questions that are asked during this scoping phase:
- Is this a single user system, or will the application be developed for multiple companies with multiple users?
- What kind of users will use the application? Will they be highly experienced users, or consumer-level users, or both?
- What reporting will be required?
- What are the departmental needs of the application’s users: marketing, sales, accounting, I.T., legal?
- Will the application need advanced roles and permissions based on login credentials?
- What are the business requirements of those using the application?
- What are the business rules (workflows, formulas, security measures, etc)?
- Will the application need to talk to other applications (via an API)?
- Will the application need to communicate via text, email, and/or a phone application to its users?
- Will there be peak periods of data movement (like a billing run for millions of customers)?
- What are the security and industry compliance requirements?
- What are the internal documentation requirements so the software can be maintained by potentially rotating developer staff over the years?
- What is the total life cycle cost, from development to maintenance?
- Does this application warrant patenting, or will it infringe upon other patents?
- On and on and on.
After determining what the software must do, a database architect will be required to make sure the software’s database can do what the application is supposed to do, now and in the future. You can think of a database as like the foundation of a home. That foundation must accommodate the building on top of it. How big (robust) must that foundation be? How much data will the database hold? What speed or performance is required? Just like in homebuilding, special considerations for things like the weight of cars in the garage, or a hot tub on an exterior deck, must be taken into account. Get the foundation wrong, and the house may crumble or fail. The same thing holds true for software databases. Get it wrong, and things won’t work. Therefore, getting the database right at the application’s inception is critical. For this reason, a good database architect is easily a 6 figure resource.
To build the actual house requires multiple trades and talents, such as excavators, masonry, framers, electricians (low and high voltage), plumbers, sheetrockers, finish carpenters, on and on. Software is the same way. After the database structure has been determined, the actual application can be built on top of the database. An analysis of the technology required for the application to work effectively also takes place. Software applications often require multiple pieces of different softwares to work in conjunction with one another. These multiple pieces are often referred to as a “tech stack”.
No “one person” can know all there is to know when building an enterprise-scale application. A team must be assembled who know all the elements of the tech stack, in addition to the needs of the business(es) using the application. This will be a team of junior, mid-level, and senior developers covering the skill sets the tech stack requires. Most of these team members are 6 figure earners. If they are not 6 figure earners, rest assured, they’re honing their skills and resume to become 6 figure earners (in other words, the junior developer seeks to become mid-level and senior, with commensurate pay raises along the way).
In the case of a hauler market application, a small to medium size team would be required to scope, build, test, implement, and support a modest sized application. That means a team of roughly 8-12 developers. This team can easily cost $1 – $1.5 m a year in payroll, depending on their skill sets. That’s a monthly payroll of $85k-$175k, depending on the skills needed and seniority of your team. Keep that figure in mind.
Why Not Just Outsource?
While some software companies choose to outsource their actual code development, many do not. There are pluses and minuses to each model. Successful outsourcing is a very complex task, requiring high levels of planning, scoping, testing, Q/A, and much more. Will the outsourced individual or team have all the skills necessary to build the entire application, or just pieces and parts of the whole? How do you know? If the outsourced resource becomes unavailable, is their code readable and editable by the next developer? Will an outsourced resource steal the tech or patents, or honor a noncompete? Will a short-term gain result in long-term pain?
A domestic, or payrolled development group is much more expensive. But, there are many benefits, such as immediate face-to-face group collaboration sessions, no language barriers, no time zone issues, better accountability standards, intellectual property control, long-term relationships that keep the domain knowledge in the company, and more. Most “serious” software companies in the U.S. have their core developers in-house.
In short, there are many considerations and strategies a company must analyze before outsourcing, so outsourcing itself is not a forgone conclusion. Software companies often have a mixture of internal and external developers, shaving costs where practical and low risk.
Niche Software vs Generic Software
Economy of Scale
Before we can examine the economics of a niche software company, it’s useful to understand the nature of a niche software marketplace, vs a larger, general market. There are many wonderful softwares out there for $89/mo. You buy it, you set it up, you implement it, and viola! You’ve got software. But, is it specific to a waste hauler? Does it do the things a waste hauler needs? Or is the $89/mo software designed and built to be used by all sorts of businesses that don’t have the specific requirements of a waste hauler? The hauling space, with all its particularities, is its own niche, requiring software that’s tailor made for the industry.
To illustrate this point, accounting software provides an easy example. There are any number of popular accounting software products on the market, and they’re offered at a reasonable price. But, do they have the billing functionality a hauler needs? Does the billing tie into the routing software (to add or remove stops from the route if a new customer is added, or an existing customer becomes delinquent). Do they account for local taxes, environmental fees, etc? Do they prorate the bills based on the service start date and billing cycle? Hauler billing is complex, especially in subscription residential markets. Generic accounting software wasn’t built for the hauler space, and therefore lacks many of the specific features a hauler will need. Haulers need billing software built for haulers.
Additionally, the economics of generic software are completely different than those of niche software. Generic software might sell in a market with 1 million, 10 million, or even 100 million potential users worldwide. Conversely, hauler software is designed for a niche with maybe 10,000 companies at best (from simple 1 truck junk haulers to big private regionals to publicly traded nationals). There are another 35,000 or so municipalities, but only some of them haul their own trash, so the market is really defined as, maybe, 20,000 potential users, total. Each of those users have different service types (roll off vs subscription residential vs front load commercial, for instance), and therefore have different software requirements. If the software application is designed to service a commercial front load business, it may not be suitable for the subscription residential hauler, and vice versa. Because of the differences in hauling companies, those 20,000 total users in the hauling space are divided into service type segments, meaning the application might only have a total marketplace of a few thousand users.
When designing the software, the total marketplace potential is obviously part of the initial questions. Who are we selling it to? What must it do? How many potential customers will there be? If the software application has a total market of, say, 2,000 haulers, how does it recover the $5m+ invested, and build a company worth upwards of $15-25m in less than 5-7 years to meet investor requirements?
Answer: Not at $89/mo/user, but more like $890/mo/user, or even $8900/mo/user.
The Economics of a Software Business
How much is software? 5m+? Really? (yes, really, and more).
The first thing to realize about the software business is that revenue follows a large, upfront investment. Building a useful software application takes months, even years, depending on the size of the development team vs. the scope of the project. A modest scope might require that 8 person team. A larger enterprise scope with multiple applications working as a suite (think in cab computing, truck cameras, a phone app for customers, etc.) might double or triple the development team’s size.
To illustrate this, let’s imagine a case study, Hypothetical Software Company (“HSC”), a small software company that’s building an entry-level application for the hauler space (no phone app, no truck cameras, no in-cab computing, etc.). Of course, this will prevent the largest haulers (the ones who spend the most money on software) from buying HSC’s product (initially).
During its scoping and architecting phase, HSC concluded that an 8 person team is needed for 18 months to build a Minimum Viable Product (“MVP”) for the hauler market they’re targeting. An 8 person payroll equates to a monthly expense of approximately $100k/mo (remember, most devs are 6 figure earners). That means a development cost of approximately $1.8m before the software brings in even one dime of revenue.
That’s just development. What about other business expenses, like marketing, sales, accounting, legal, H.R., etc? What about leased office space? Those costs may add another $40k/mo for another two years, or nearly another $1m. Again, this is before any revenue is earned.
Even when the company begins selling its product, expenses will outpace revenue for several years. If it takes 2-3 years after the product launch for revenue to cover expenses, that’s another several million dollars needed to fund those losses. This chart summarizes the cash burn until HSC’s revenue catches up with expenses.
From this chart, we can see a few things:
- $4m in expenses in the first 2 years, no revenue.
- Revenue of $1m begins in the 3rd year, but expenses are still over $2m, burning another $1m or more in cash in the 3rd year.
- In year 4, $2m in revenue largely offset $2.2m in expenses. Still, $200k more cash is required to cover expenses
- Total cash burn until HSC covers its own expenses is roughly $5.2m.
Where does the first $5.2m come from? Usually private investors. The investors are going to want to know “how fast do I get my money back?” and “what multiple can I make on my risk money?” Software isn’t asset based. There’s generally no real estate or tangible assets underlying the initial investment (vs, say, building an apartment complex or some other real estate-based investment). So, given the relatively high risk, the initial investor will want a fairly typical 3-5x return on their initial investment of $5+ m. That means the software company needs revenue to support, say, a $15 – $25 m valuation in 5-7 years.
How does this happen at $89/mo per user in a small niche market of a few thousand potential users? Answer: It doesn’t.
A Deeper Dive Into HSC’s Revenue and Expenses Model
The largest players in the hauler software space have between 300 and 1000 clients. It took them, in some cases, decades to amass that many users (or they do it by acquisition of other software companies). When launching HSC, it’s worth remembering that the biggest haulers with the most users don’t easily move to the new player in the space. They’re reluctant to give up their working, mature, feature rich software, or to accept the risk of taking on the new product as a guinea pig. So, our HSC example might only get smaller haulers initially. If HSC is lucky, they’ll amass 100 clients in 3 years, and that would be considered remarkably successful in this space. But these clients will be smaller, and with smaller contracts generating less revenue when compared to the mature software companies servicing the big haulers who spend way more on their software than the little haulers.
If each small client HSC has generated, say, $30,000/yr in revenue, then 100 clients in the 3rd year of sales (5th year of operation) would result in about $3m annual gross revenue. Again, this would represent an amazingly successful launch! However, we have to remember that the first 2 years were used to build, market, and then sell the product. Revenue started in the 3rd year of operations, but remember the company has about $2m a year in expenses (those damn developers!). So, by the 5th year, over $10 m has been spent, and only $6 m has been earned.
This chart is a summary of the launch and growth, expenses and revenue for HSC:
This chart shows:
- Annual expenses to be flat at $2m for the first 2 years, and then rising by a modest 5% a year for years 3-7 (like, adding support staff).
- Annual Revenue beginning in year 3, $1m the first year, and an additional $1m a year for 7 years.
- Cumulative expenses of $15,603,826 at the end of the 7th year.
- Cumulative revenue of $15m at the end of the 7th year.
- A $2.5m gross margin in year 7.
So, with HSC, cumulative expenses don’t even reach cumulative expenditures in the 7th year. However, since there’s roughly $2.5m in gross margin in the 7th year, the company might be worth selling, and HSC might reach the valuation the initial investors required.
HSC Valuation in years 5-7
A quick Google search reveals that a typical small software company sells at somewhere around 3.3x Total Revenue (there’s a vast range here, but let’s use an average for a small company like HSC). Using very crude math, and that middle-of-the-road 3.3x revenue multiplier, HSC would have a valuation of approximately $9.9m in year 5, $13.2m in year 6, and $16.5m in year 7 (multipliers in the hauler space are pretty strong, but let’s stick with the average).
If we combine the valuations chart with the previous revenue and expenses chart, we get the following:
Perhaps it’s in the 7th year, where revenue is $5m, where the investors sell. With a successful launch, HSC is worth $16.5m in the 7th year. If sold, HSC would deliver a modest 3.2x return on the investors initial $5.2m in the 7th year (again, this is a very basic example. There are many factors that go into calculating investor return on money, which we won’t get into here). And HSC actually represents an excellent, successful launch.
In reality, most software companies in the hauling space do not grow as quickly as HSC. In fact, watchers of the hauling software space can attest that many new software companies go out of business. They last a few years, and then they’re gone. The most likely cause of this is that they run out of cash before revenue even catches expenses. In HSC’s case, it’s incredibly optimistic to assume $5m in revenue in the 7th year is even possible, as $5m/year exceeds the revenue of many of the established players in the hauler space who’ve been operating for decades. $15m in annual revenue represents the top players in the space, most of which have been operating for decades.
Why is Software in the Hauling Space So Old?
As we’ve seen, software is expensive to develop. Revenue is slow to start, and slow to increase over time. Investor returns aren’t always attractive compared to other possible investments (HSC’s 3.2x after 7 years is barely mediocre). And this is a major reason as to why hauler software hasn’t changed since it was built in the 1980’s, 90’s or maybe 2000’s. The legacy softwares in the hauling space have, for the most part, been around for decades. They’re mature products, with many features, and all the bugs have, by and large, been fixed. Given the economics, how can they justify re-writing their products?
With regard to the legacy players, the economics are at least as precarious as the startup. First of all, there’s that $2-4m mentioned earlier for a new application. Yeah, that’s for something light duty, a new “up and comer” into the hauling space. If we’re talking about the established players, the softwares used by the largest haulers in the country, with fleets of 100’s or 1000’s of
trucks using in-cab computing, integrated truck camera systems, weight/scale software, a phone app for customers, a customer service front end, etc., that $2-4m is more like $20-25m.
The legacy products have benefitted from years and decades of investment. They’ve been steadily trickling millions of dollars into their products over long periods of time. They’re not $2-4m dollar entry-level applications anymore. The legacy players might have invested $20m or more into their platforms since the application’s inception. As a result, they’re feature rich and robust. And, their customers/users would expect functionality on par or better than the existing legacy product. So, the bar is much higher for them to duplicate their products vs. the new kid on the block selling to haulers with 10 trucks or less.
To rewrite their products, the legacy software companies would have to hire a completely different developer skill set to build new applications using a new tech stack. The old software has a completely different tech stack, with developers versed on the “old stuff”. Almost none of the developers they have on staff would be familiar enough with new technology to architect, develop, implement, and support a new tech stack. Thus, they’d have to pay the old dev team at the same time they hire and pay a new dev team to write the new stuff. If they do it just right, they are right back where they started, within 2-4 years and after $20m is spent. Yikes!
Also, and this is a bit techy, while there are many benefits to a newer tech stack, it’s not all honey and roses with the new stuff either. Browser-based applications have limitations that older, “strongly typed programming language” applications (like the legacy stuff) don’t have. Duplicating a back office legacy product with a browser-based modern application is very complex.
With software, complexity equals dollars. While the old stuff is like a hammer, the new stuff is more like a nail gun. Sure, a nail gun can allow for more productivity than a hammer, but it’s also much harder to engineer, and more prone to failures of all types. Why? Because compared to a hammer, a nail gun is a complex machine with many moving parts, often controlled by computer chips, all requiring a source of electricity, etc. On the other hand, hammers rarely break. They just don’t allow for the same productivity as a nail gun (when it’s working).
The legacy software companies are aware of this. While their products are old, they work, most of them very well, especially when compared to the newer browser-based stuff coming into the market. One very large player in the space (who shall remain nameless), has been attempting to bring a full-featured browser-based application to market for many years, spending millions and millions, and failing along the way (did I mention software development is hard?!).
Additionally, how is a legacy software company going to finance a $20m rewrite? To finance the new application, the legacy players would have to cut into their profits, or run at loss (borrow? investors?). If the legacy company is privately held, that investment would eat directly into the profits (or owner discretionary income). What do they gain?
While there are competing philosophies in running a business, such as “long term play” vs “short term gain”, it suffices to say that outward pressure (competition!) is what’s required to push the legacy players to invest into re-writing their products. We’re starting to see this competition arise in the market, but the economics of the software industry within a niche market will see many of them fail. To ward off competition, the legacy players can always just lower their price, and still be profitable, while the new players need to charge more and more to ensure financial solvency and/or meet the needs of their investors.
It’s a catch 22. While many haulers want their softwares to be modern, with the capabilities modern software affords, many of these same haulers don’t seem as willing to pay for newer software as they are for, say, a new high-feature $500,000 garbage truck. So, as long as the market isn’t willing to pay for new software, they won’t get it. And they’ll be stuck with expensive and outdated software for many more years to come (ok, rant over…).
Why don’t the legacy softwares simply add features and functionality, turning their hammer into a nail gun?
Short Answer: They can’t. Literally, how do you turn a hammer into a nail gun? That’s the level of impracticality we’re talking about here. It’s just easier to build (or buy) the nail gun.
Harkening back to our homebuilding analogy, just like a home, software has limitations based on its original design. If a home was built as a rambler/ranch style, with no basement, and a 1500 sf footprint, it becomes difficult to make changes to that basic design. Sure, one can add a deck off the back, perhaps remodel the interior walls a bit, or maybe even add a separate garage not attached (analogous, here, to a separate software application). But, if you want that house to be a 2 story home with a basement? No bueno. It would cost more to make the old house into the 2 story with a full basement, than it would be to tear it down and start over.
And so it is with software. If an application is built cheaply and quickly to get it to market sooner (remember, cheap vs good vs fast, pick 2!), it may be the modest 1500 sf rambler from its inception, with little room for future expansion. This is, quite often, the avenue software development companies take. Why? Because they need revenue to offset the investment as soon as possible. The demands of their investors often require it.
Money Guys vs Great Software
Remember how expensive those developers are? Well, often, the money guys see the situation like money guys tend to see things: Get revenue! Push out the “Minimum Viable Product” (MVP) to market asap, and stop the money bleeding! So, it’s the bean counters, investors, and/or the private equity guys with beads of sweat on their forehead (as they see hundred thousand dollar bills fly out the door with no revenue), that push for cheap and fast (vs good). The result is what’s known as “technical debt.”
According to productplan.com, technical debt is “that which results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code.” In this case, “perfect code” refers to the code and database’s ability to be flexible and change, or to have been built with the future in mind.
Compared to that 1500 sf slab on grade rambler, it’s more expensive to build a basement during the initial build if it’s not needed. But, what if it’s needed someday? Should we buy a walkout lot so we can have a basement? That’s more money now vs a smaller, flat lot. Maybe we should rough-in some plumbing in that basement in case we want a bathroom down there someday. Perhaps some egress windows for future bedrooms. Should we add the necessary framing to support a second and third story? Oh! We may need an elevator someday, should we account for that in our design?
Basically, rather than do it right initially, “we’ll circle back later someday” becomes the strategy (it’s not a strategy unless it’s planned) to get the company to revenue sooner.. The thing is, it’s sometimes orders of magnitude more expensive to make meaningful changes in the future, like turning that rambler into a 2 story with a walkout basement.
Yet, because of the pressures and demands of the money guys, “we’ll fix it later” becomes the playbook. “Right now, we need customers and revenue!” In some cases, this might actually work. In most cases, however, the technical debt associated with a short-sighted initial design can quickly halt development. It’s like a tractor pull event. As the tractor pulls the trailer down the lane, the weight becomes harder and harder to tow, until the whole thing stops dead in its tracks.
The thing is, the initial money guys might not care. If they’re looking for that 5 to 7 year play, they’ll sell the company before the technical debt becomes too great to bear. Or, the technical debt might have already halted feature expansion, but the revenue from the initial application is enough to get the company sold. And, the next money guys who buy the software company, well, most of the time, they just want to see the revenue and EBITDA figures. Rarely is there a deep look under the hood at the status of the codebase. So, revenue and EBITDA are driving software companies, not excellent code, particularly in a small niche like waste hauling.
The legacy softwares have money guys, old “hammer” code that can’t be easily changed into a nail gun (can’t change old code into new stuff), and decades of technical debt that slows or stops their ability to make their existing codebase have more functionality. They’re stuck. As such, their products aren’t going to change in big ways unless they’re completely rewritten. Place your bets as to whether or not that will ever happen.
Conclusion
And so it goes. The money guys win. Because the hauler market is relatively small, there just aren’t that many potential users to amortize millions, even tens of millions of dollars of investment. As a result, the niche software in the hauling space languishes because it’s too hard and expensive to update or rewrite relative to the revenue it would generate. Furthermore, the new up and comers face enormous costs to achieve feature parity with the legacy stuff, and the legacy players can always undercut the new players given their lower cost structure, so the newbie’s relatively expensive and comparatively immature products are often rejected by the market. In order to compete, the newbies sell their new stuff at an unsustainable discount to buy market share, which ultimately starves the company of their development budget, and the downward spiral from there is inevitable.
When the rare feature-rich new product does come to market, it will have cost $20 m or more to develop. Recovering that investment and profiting from its initial cost makes the new product so expensive (relative to the legacy stuff), that the market often rejects it too.
So, unless haulers become willing to pay much more for their billing, routing, in-cab computing, online signup, customer notifications, lead follow up, and customer service software systems, they’ll be stuck using legacy software from the 1980’s. Is it worth seeking out the new stuff and paying a premium? Stay tuned for the next article in this series.
