Custom software used to be prohibitively expensive or difficult to build. Accounting packages like Accpac and Simply Accounting weren’t designed to be modified. If you were lucky, there were some user-defined fields you could use or an unused field that you could re-purpose for your needs, but there was no way to tweak the system.
In addition, there were all the horror stories of large systems that cost hundreds of thousands of dollars failing. If you couldn’t afford to take that kind of risk, what do you do? You created a spreadsheet or database on the side and hoped it was kept up to date.
Back then, making changes to software was so time-consuming and expensive that when you had to do it, there was a complex planning process you had to go through to create a set of specifications for the developer to follow. You didn’t actually have to sign off on the specifications in blood, but it often felt that way! And when the developer came back, the program was often wrong, resulting in arguments about whether it was your specifications that were incorrect, or whether the developer had misinterpreted them.
Fast forward to today. What has changed?
First of all, computer applications (apps) now play better with each other than they used to. Let’s say you’re using a popular small business accounting package like QuickBooks. You still can’t change it, but it’s much easier to find someone who will build you a little app for that information you used to manually track in a spreadsheet. Intuit, the maker of QuickBooks, publicly publishes a set of programming instructions that show developers how to use the accounting data and/or update it with new transactions.
But it’s still time-consuming to develop an add-on that will post accounting entries. (Think of having to deal with every possible combination of sales taxes.) What you want is an add-on that already does all the heavy lifting of posting to QuickBooks, so you’re free to make just the changes you need.
And what about the specifications signed in blood?
Those have changed too. Apps like Method:CRM use menus instead of a programming language. You don’t have to know how to code. You can just make the change and immediately test it. This means that you don’t have to create specifications for a whole system at once. You can make small changes that solve an immediate problem and build the whole system over time.
In fact, by making system changes less technical, people who may not be developers but have business experience can learn how to build their own systems. I watched a presentation by Matt Raiser, whose family owns an asphalt company. He was so proud of what they had been able to do by customizing Method:CRM.
Doing quotes for customers used to be complex and it used to be that his father was the only one who could do it. Now, they can send a non-technical salesperson out to visit the customer. He pulls up the satellite image of the parking lot on Google Maps, then marks the corners on the image. The system calculates the area to be paved and determines the amounts of raw materials and labor needed. This allows it to spit out a quotation for the customer and even post it through as an invoice when the customer accepts it. The system will also schedule the work and assign the staff.
When I asked Matt how they had built such a complex piece of custom software, he was quick to point out that it wasn’t done all at once. It evolved over time as people used the early versions of the Method:CRM system and suggested improvements.
It’s like that old saying: how do you eat a whale? One bite at a time.
And that’s how small businesses can afford custom software:
- Use up-to-date, flexible software that does the hard stuff for you.
- Develop on a parameter-driven platform that doesn’t require programming.
- Take small steps, focusing on what you need most first.