Pairing Custom Software with Industry Standards
If you’re weighing the pros and cons of custom software development, it’s important to recognize that not everything must be fully custom built.
When crafting software we find that it’s always more beneficial to reuse existing frameworks, software, systems, and paradigms than it is to build and later maintain everything in-house. The cost of creation is only one part of the total cost of software ownership. Maintenance is the always-and-forever, long-term cost to keep systems running as they should. Not considering the future and making efforts to minimize those ongoing expenses is an often overlooked and costly mistake.
With that in mind, a significant part of our job is to:
- Recognize and incorporate your existing business software and processes
- Locate and integrate with industry software and systems
- And where possible, identify where others have solved similar problems and apply those solutions
The custom components of a software application should reflect only those business differentiators, data, and processes which are critically important to or truly make your offering unique. It’s the way your custom processes and flows seamlessly join with all of these other systems that defines your application. And the quality of the decision-making and overall execution of those plans dictates how successful your application solution will be.
These questions have a heavy focus during the discovery phase of a new project. We believe that it’s critically important to recognize early what is novel and valuable about each new project. Everyone’s efforts are properly focused on those items which further enhance your value and drive toward overall success. These considerations are not only part of our process at the start, but they’re on our minds throughout every step of the software journey to completion.
The benefits of reusing existing solutions are numerous, vary greatly, and should never be underestimated. Where your data or processes are nonproprietary, you can often save time and money, as well as avoid future headaches, by leveraging already proven and readily available solutions. Recognizing and incorporating your existing software and processes into a new application is crucial to bringing about rapid, successful adoption by your current and future consumers.
Narrowing Your Focus
Unless your business is just starting up, you already have some systems and software in place. Even if you are just beginning, you certainly carry some existing knowledge, familiarity, and comfort from software and services you’ve used in the past or are already popular within your industry. These may include common desktop software like Excel or QuickBooks, or cloud software and platform services like Salesforce, Constant Contact, NetSuite, or Tableau, to highlight just a few.
For these common, large systems, it’s simple to immediately recognize their value as a separate entity which stands alone from your project. They’re solutions that are backed by huge teams of developers investing thousands of hours of problem solving and development into their specific niche. They’ve identified, overcome, and hidden away many complexities in their core offerings, making sure you avoid those pitfalls. They’ve spent the time and budget to identify problems and iterate their solutions many times over to ensure that when using their products, you avoid all of those issues. By utilizing these services, you not only immediately unlock their full featureset and expertise, but, equally importantly, you get them for a known timeline and cost.
Is it possible to recreate part or all of these systems for yourself? Absolutely. Is it a worthwhile effort or investment for you? Likely not. But as is always the case: it depends.
The Power of Partnership
If you’re building a new email marketing service, for example, you shouldn’t deliver those emails through a competitor. But, you almost certainly should offload processing credit cards and recurring subscriptions to a provider like Stripe or PayPal. Not only does it simplify your application, but it also offloads the responsibility. When working with the banks, merchant accounts, international payments, and fees and the requirement to make changes to your software each time they update theirs.
The lines of delineation between what you should do yourself and what should be done by others begin to blur when the features get smaller or “simpler.”
A deceptively small example: Capture feedback from website visitors. The simple approach may be to add a form to the bottom of every page and when submitted, it emails you. Seems simple enough, but the scope can quickly expand over time. Should the form always be displayed or should it appear after a specific action is taken? Should there be a series of activities or events that trigger the display? Will you need to gather screenshots along with the text? Perhaps some visitors are more important than others and should get a response priority. What happens when the inbox becomes inundated and you need multiple support personnel involved? How do you keep track of what’s been answered versus outstanding? What if someone gets sick? How do you know what’s been answered and what hasn’t?
Seemingly small features occasionally have a way of becoming surprisingly complex when the real world gets involved. If you continue to build out that feedback system – iterating and band-aiding as you go – there is a point at which your product is no longer doing just one thing. Product focus has been lost and you’re now also responsible for building and maintaining a customer support and ticketing tool.
Determining the balance of what your system fully-owns versus what something else can do for you is what makes your custom project unique. Clearly identifying and understanding your core competency informs everything. It narrows messaging, focuses efforts, and highlights your niche. It also defines what you do and with whom you compete. Without this clarity, you’re left to do everything and compete with everyone.
Lowering Future Costs
Once you’ve identified your niche, selecting the right partners with whom to integrate is equally important. The service with the lowest fees or easiest setup may not be the best choice. Considerations should be made for existing knowledge and experience, as well as longevity and the possibility of turnover.
Whether you already have existing staff or plan to hire them some day, it’s useful to understand the tools and systems they already know and expect. Those individuals have already invested their time and effort in learning and familiarizing themselves with those applications, so harness that value where you can. Retraining is expensive and time consuming and those efforts should be considered when evaluating possible options.
When onboarding new employees specifically, it’s drastically easier to bring them up to speed when you’re using tools they already know. At that point, their only focus is not on how to use that tool, but on how you use that tool. This is a far more comfortable situation for them to enter and requires much less effort than learning both a new tool and a new process.
The realistic longevity of a partner should be part of the decision, as well. A new service or provider may seem more agile and responsive, cheaper, or more flashy than the older, possibly stodgy alternatives. But do they have a plan and team in place to last longer than you will? Will they go out of business or need to be replaced in a year? Occasionally transitioning from one provider to another is simple, but often there’s significant effort in transferring data, updating integrations, and retraining staff for new systems to consider.
If you ultimately select a solution which is outside of the norm, your decision process is more informed and everyone’s expectations are better set. There is clear and robust reasoning behind those selections and likely even criteria by which they can be measured. It’s these decisions and selections that inform and define your product and priorities.
Don’t simply go with the cheapest option as it’ll likely cost much more in the end.
Make Use of What You’ve Got
Now that your product focus and partner solutions have been identified, it’s time to build. Here again, the same considerations that were made earlier apply. Do we build it all from scratch or use what is already available? What parts are proprietary to your solution and what is generally enough to be done by someone else?
At a high level, many programming languages have free and open source web application frameworks and libraries readily available. On the server-side, Ruby on Rails for Ruby, Django for Python, Spring for Java are just a few examples. Then there’s Ember, React, Angular, and Vue for the client-side. All of these offer libraries for integrations with common software and service providers and answer many of the mundane initial decisions that can sometimes cause analysis paralysis. Further, utilizing frameworks bypasses the need to build and maintain a significant amount of code yourself. It joins you with a community which will continue to develop and innovate to your future benefit, and provides your new software with a very significant head start.
Similar to using a service partner, these software frameworks come with thousands of hours of developer investment. These framework communities have already done the troubleshooting, iteration, streamlining, and often carry entire ecosystems of tooling, training, and support. There’s no need to “reinvent the wheel” when deciding how to process web requests or interact with a database. Hiring is more targeted and onboarding is more straightforward.
At a lower level, deciding how to structure data and communicate with others can reveal similar opportunities. Your industry may have a common structure for data, like SCORM or xAPI for learning systems. Then, separate from the format of the data, there are yet more standards with how to serialize and communicate that data, like GraphQL, JSON API, MessagePack, or Protobuf. This becomes important if you expect other systems to use your data.
There are thousands of small decisions to make when building custom software. Each one of them has an impact on direction, adoption, and ultimately on success. Avoid putting too much effort toward rebuilding pieces that have already been built or features that someone else has already done better. Focus on what makes your software unique and work with partners who do the same. This keeps your costs down and frees you to pour more effort into what makes you unique and valuable to your audience.
QA is often relegated to an outside team towards the end of the development process, but we have found that the best QA process starts at the very beginning.