Blueprint Software
Introduction
I think businesses would make better software decisions if they approached them a little more like buying equipment.
An owner looking at a machine would normally want to know how much work it can handle, how long it should last, and who can fix it. They would think about training, replacement parts, and what happens to production while it’s down. The purchase price matters, obviously, but a cheap machine that nobody can service is not much of a bargain.
With software, it is easy to spend the whole conversation comparing a development quote with a monthly subscription. I understand why. Those are actual numbers someone has put in front of you. The cost of an employee sorting out a broken schedule six months from now is much harder to put on a proposal.
But once people use an application to assign crews or invoice customers, the business depends on it. Choosing that application changes work for people who may never have been involved in the decision.
What Work Will It Actually Improve?
Suppose a contractor wants a better scheduling system. The current spreadsheet is annoying, and the new product lets a dispatcher drag a job onto a calendar and notify the crew. I can understand wanting that, especially if someone currently spends part of every afternoon calling people about tomorrow’s assignments.
If jobs are starting late because material hasn’t arrived, though, assigning the crew faster doesn’t help very much. Someone still has to check that the material is ready. If the new system removes the phone call where that used to happen, it could actually make things worse. Everyone gets a notification promptly and then drives out to discover they can’t do the job.
Before removing that call, I would want to understand what people were checking during it. The new system may need to show whether material is ready, or leave the job unconfirmed until someone checks. The dispatcher should be able to spend less time on the phone without the crew losing information they need.
Hershey described several problems happening together in its account of a difficult software rollout in 1999. The company said a lack of loading-dock space during peak shipping made the software problems worse. In explaining its recovery, it discussed software fixes, improved distribution facilities, and employees becoming more comfortable with the system. The company had to improve how it handled the orders in the warehouse as well as in the application.
A contractor planning a second location also needs to know whether the system can handle separate crews and schedules. I wouldn’t spend a bunch of money preparing for an expansion nobody has agreed to. But if the business already plans to open that location next year, finding out afterward that the software can’t support it would be an expensive oversight.
As I’ve written before, you probably don’t need custom software. Understanding the work might lead to an existing product or a small change to the spreadsheet.
Keeping It Running Is Part of Owning It
Software doesn’t physically wear out, so I understand why a maintenance bill can be frustrating when the business hasn’t asked for anything new. The application worked last month, and everyone is still trying to do the same things with it.
But the accounting product it connects to can change. A tool it depends on can stop receiving security fixes. The business can take on work the original application wasn’t built to handle. Someone has to keep up with those changes even if the scheduling screen looks exactly like it did last year.
I would want to know who has agreed to do that work and what their agreement covers. Being able to email the original developer is useful, but it doesn’t tell me whether anyone will notice a failure before an employee does, or whether help will be available when the business needs it.
The answer should depend on what failure would interrupt. An old report can probably wait until Monday. Tomorrow’s crew assignments may not be able to wait until morning. A backup is useful only if someone can restore it, and dispatch still needs a way to get instructions to crews while that is happening.
After a cyberattack in 2019, aluminum producer Hydro reported that much of its business was still running with more manual work than usual. Some plants temporarily stopped because they couldn’t connect to production systems. Its update described both the work to restore those systems and how each part of the business was managing in the meantime.
The closest software equivalent to replacement parts might be the tools and services an application depends on. If the service sending crew notifications shuts down, another developer should be able to understand how it was connected and replace it. Using common tools and writing down how the application works makes that easier, especially if the original developer has moved on.
Someone Has to Operate It
Buying software also means asking people to change how they work. They may be slower while learning the new system.
I would want training to include corrections and exceptions. People need to know how to move a canceled job, fix a quantity, and undo an assignment to the wrong crew. Showing someone how to enter a perfect order is a fairly small part of teaching them to do their job in a new application.
If a dispatcher keeps printing the schedule and writing on it, I would be curious about why. Maybe making a change sends a notification before they’ve finished rearranging the day. Paper lets them think for a minute without telling six people to go somewhere else. That seems like a reasonable thing to want from scheduling software.
Some mistakes carry more weight than an inconvenient notification. If equipment is awaiting repairs, the schedule should make that clear, and changing it back to ready should require the right person. It should also be possible to find out who changed it and when. Those details matter because someone may trust that status when deciding which machine to send out.
This is part of what I was getting at in my article about vibe coding. The software needs to handle what people will actually do with it, including the mistakes everyone would prefer they didn’t make.
The Purchase Price Is Only One Number
Moving records, connecting existing systems, and training employees all belong in the cost of the project. So does the time people spend running both systems while checking that the new one works. The business pays for those hours even when the software company doesn’t bill for them.
Then there is the ongoing cost of keeping it online, paying subscriptions, getting support, and making changes. I would compare that with the time saved and mistakes avoided over the years the business plans to use it. Some of that will be difficult to estimate. Even a rough allowance for support is more useful than assuming nobody will need any.
Spreading payments out may help, just as financing equipment can. It still matters how much the business has agreed to pay and when. If the bills start months before the software is expected to save any time, the business needs to be able to carry that cost while employees learn to use it.
A cheaper product may be perfectly adequate. I don’t think a business should pay for elaborate support it doesn’t need. I do think it should understand which responsibilities are included in the price and which ones somebody inside the company will be taking on.
Eventually, You Will Replace It
A machine may have resale value when the business is finished with it. Custom software built around one company’s way of working probably won’t have the same market. I would judge its cost based on the work it can do for the business while it’s being used, without assuming someone else will buy it later.
I would be more interested in whether the business can move its records into another system. That includes the attached documents and history people still need, along with someone checking that the move worked. For custom software, the business should control the code and accounts another team would need to take over.
The move also needs time for people to check old job records, learn the new application, and deal with anything that didn’t transfer correctly. They will be doing that alongside their usual work. I would want to allow for that when planning a replacement, even if everyone is understandably tired of the old system.
Before committing, I would want to understand what work will improve, how long we expect to use the system, and who will look after it. The ongoing cost and eventual replacement belong in that decision too.
I think most owners would expect those answers before buying a machine their employees depend on every day. I’d expect them from a software company too, including mine.