Okay, But Actually… Five Million in Revenue Is Not a Software Requirement

A commenter said businesses above five million in revenue tend to choose an existing software product if one is available. They mentioned card-payment rules, security certifications, single sign-on (one login for several tools) and security testing as reasons.

I can believe that is what they have seen. For the next business, I would start with the work its software needs to do.

Show me what the business does

Imagine a wholesaler with a small number of large customers. It invoices them for bulk orders and has a particular way of reserving stock across several warehouses. It could have high sales while only a few people use its internal system. The unusual stock process might be exactly where a focused custom tool helps.

Now imagine a much smaller company running an online booking service for thousands of people. It has customers creating accounts, staff changing bookings and a payment flow to manage. Lower sales have not made those questions disappear.

I would not recommend a product for either business yet.

The five-million wholesaler might also have narrow margins because most of its revenue goes straight back out to suppliers. A smaller business with a different model might have more room to invest in software. Revenue is not a project budget, either.

Before recommending software, I would check how many people use it, what information it holds, what customer contracts require and who will maintain it.

Growing sales can bring real changes. If the wholesaler opens two more warehouses and gives customers their own logins to check stock, the app now has more users and more ways to expose information. That calls for another look at access, testing and support. If the business simply sells more to the same customers through the same small team, its software problem may barely change. Those are two very different projects.

What actually triggers the requirements

Take card payments. If the app handles card details itself, payment-card rules can apply to more of its systems. If customers pay through a provider, the business still has responsibilities, but using that provider can change which requirements apply directly to its own systems. The payment setup matters here.

Money does make a difference. A larger budget can pay for specialist advice, more testing and better support. Growth may also bring more staff and customers into the system. For personal information, we still need to look at what the app holds and what a leak or mistake could do. The European Data Protection Board's guide for small businesses recommends choosing security measures based on the information and the risks involved.

Some laws or contracts really do use financial cutoffs. If one applies here, it belongs in the discussion by name.

Each item in the comment needs its own answer. Which does this business need, and who is asking for it? A customer contract might require single sign-on. Staff might want it because they use several systems. The application might need an independent security test because of the information it handles. I cannot work any of that out from annual sales.

When buying makes sense

If an existing product handles the work and has the admin features and support the business needs, I would happily recommend it. The team can try it before committing, and the supplier handles updates to the product.

The tricky bit is the commenter's “if there is one they can use.” If staff still need three spreadsheets and have to copy every order into two other systems, I would hesitate to call that a good fit.

At that point I would compare the real options. Could the business change its process to use the standard product comfortably? Could it configure or connect existing products? Would a small custom piece solve the awkward part? How much would each route cost to run and support after launch?

A custom build has costs that belong in that comparison. Someone must test it, keep it updated, manage access and answer when something breaks. If the business is unwilling to own that work or pay someone to do it, a custom app is a poor recommendation, however annoying the current spreadsheet is.

But if a standard product cannot do the job without years of workarounds, “proven” is not the end of the discussion. Has it proved that it works for this business?

Before choosing the software

I would ask these questions at two million, five million or ten million in revenue:

• What work is the software supposed to handle, and where do the current tools fail?
• What information and payments will move through it?
• Which requirements are written into customer contracts or apply to this business's actual activities?
• How many people need access, and what should each be allowed to do?
• Is there an existing product that handles the work without expensive workarounds?
• Who will support whichever option the business chooses?

Only then would I choose. Maybe the existing product is a good fit. Maybe one small custom tool should sit beside other services. Sometimes the business needs to fix its process before buying any new software.

I am happy to hear that a developer's clients over five million usually prefer established software. That is useful experience. Their reasons for choosing it would be even more useful.

If the most important thing we know about an application is the owner's revenue, we are not ready to choose the application.