If you need a software system to handle an activity or process in your business, congratulations.
This means two things; first, you have identified a valuable business process and decided to ‘elevate’ it. Second, you have come to the realization that spreadsheet models or a legacy application are not adequate to handle the task. Third, you are closer to solving this challenge than you might realize—but you need to decide whether you buy this software, or have it custom-developed.
Whether you build a system, or buy it off the shelf (or subscribe to it as SaaS) is a well-known topic and much has been written about it. You are on a much-traveled road. We’d like to offer you some decision criteria that have served very effectively for many of our customers. The goal of this article is to help you get a solution with the best possible combination of cost, functionality, and quality—with minimal risk and within your timeframe, of course. So, read on.
Question: The business process you need to automate—does it set you apart, and give you an advantage over competitors, or is it a commodity process that varies little from one company to another?
When You Positively Cannot Buy It
If your business process is a competitive differentiator, your secret sauce, your better mousetrap, then your buy-versus-build decision is already made for you. Unique business processes, or uniquely integrated groups of processes usually don’t have a packaged application ready to go. Or there might be an enterprise-weight package that comes with an ERP suite, ERP-type implementation and a price tag 10x what you can spend. In either of these cases, you cannot buy –so it’s settled: you will build, and the question is how you build.
You’re at Neither Extreme
Let’s say you find that you are in a hazy middle ground, which is very common; your business process that needs automation is a variation from what is typical, and your spreadsheet model has evolved around this process to match the partially unique workflow or data structures of your company. Another scenario is that you merged with another organization and some non-standard integration is required. Either way, you might be able to twist and bend a packaged application to work ‘ok’ but not fit perfectly. Your situation is unique in some respects, but you might get by with a COTS package.
Software is available on a continuum from completely custom-built, to packaged but very configurable, to simply packaged COTS that has limited adaptability. To help choose, look at the value of your business process. Is it indispensable, critical, necessary for revenue, financial stability or pummeling your competitors in the marketplace?
If your business process or task—and your way of handling it—it is so valuable that you just can’t compromise its effectiveness with ‘almost exact fit’ functionality and workflow from an application, then you should build.
If you’re in a rush—let’s say that your spreadsheet or legacy database isn’t working and it’s affecting business continuity—then you are pushed either to buy a package, or (as we beat our own drum for a moment) custom-build with our firm because we prototype and deliver very rapidly.
Cost is Lifetime, Not Just Up Front
Cost is always a factor. To custom-build an application has a bigger upfront, one-time cost than buying a package, but keep in mind that once it is built, you own it. You won’t face annual maintenance fees, nor monthly subscription fees–which go up as you add users—as you would with a cloud-hosted application. Scaling up your custom application is essentially free. If you need new reports, and can’t create them on your own, then you presumably pay the developer for those minor upgrades.
Let’s say you have evaluated the unique-ness of the business activity which you need to capture in software. Your decision is to build it. How do you go about building software? There are various options, and you should keep one word in mind: team.
Go Team or Go Bust
This advice could help you save $5,000 or as much as $50,000 and some intense migraines—certainly many organizations have spent much more to this:
For custom development, always use a team, and only use a team
Whatever you might save by using an individual freelancer, or one individual in-house to custom-develop a new software application, you are likely to give back later for professional support when you need to debug or add reports. That’s the bright scenario. The less desirable scenario is that when you outgrow the application or it fails, you won’t find a reputable support resource willing to accept the liability of diagnosing, untangling and updating the application.
Capable employees often embark on building an application in-house because they lack IT resources or assume they can build a good, durable, scalable and updatable application simply because they are smart. That is usually a very flawed assumption. Your company doesn’t need heroic amateur programmers; it needs well-designed software that can be supported if a programmer retires early and goes ‘off the grid.’
We get many crisis calls from organizations struggling with database applications that are unfixable. Often, their best option–by far–is to treat their legacy application as a prototype, an “alpha” version that helps us see what was intended. They calculate and discover it is less costly to have us redesign and replace the application than to try to renovate a house of stone that was architected without a real blueprint.
As for using in-house IT resources, don’t jump to conclude they are the go-to people to custom-build your system. There’s a good chance they are not specialists in database applications—not at all. They may know your business process well, and that’s good – but a skilled outside development team can do more than good systems analysis. The experienced external development firm can make valuable suggestions based on having implemented similar solutions at other companies, in some cases.
The Classic Project Triangle: You Can Get it Fast, Powerful, or Cheap – Just Not All Three
There’s a triangle often used to describe software development projects. The vertices are named Functionality (often termed Scope), Time, and Cost. This is like the construction company that tells you, “You can get this job done good, fast, or cheap. In fact, you can pick TWO of those. But not all three.” Instead of “good” substitute the term “richly featured” or “powerful”, and you have the classic IT development triangle.
The fact is, if you find a good outside development firm, then your custom solution should be about half made up of what is essentially a packaged application. How so? An experienced developer will have built enough applications on your database platform to have accumulated a library of well-tested, finely programmed functional modules. At Help4Access we have our Bolt-On Library, culled from more than 800 custom projects. These modules add security, auditing, ad hoc reporting and other features that are not native to the database platform.
Squeeze Risk out of “Build”, and “Buy” Looks Less Enticing
The pre-coded library takes much of the ‘project risk’ and cost out of the custom project. It also gives you richer functionality yet saves time.
At Help4Access we focus on custom solutions for valuable business processes and data. The project triangle is key to our clients, as it will be for anyone in your situation. Our particular profile—how we stack up against other developers—is:
- Functionality – extremely strong and robust
- Time – extremely fast, and the byproduct of these:
- Quality – very high
- Cost – fixed price
- and finally Risk, which is not shown in the IT triangle – very low
We are neither the lowest nor highest-cost solution, but here’s something unusual: we will give you a fixed price – yet not build in a fat risk premium. We know the pathway to successful delivery of your custom project, which makes us fast and greatly increases quality and reliability of the software. Functionality will be rich due to the Help4Access Bolt-On Library. Lastly our prices, which are mid-range, are fixed in advance to remove all cost overrun risk for you.