Creating a new software application is exciting – similar to building a new home. As the designs take shape, you already picture yourself admiring the views from the balcony, or in the case of an app, imagine the users navigating their way around to solve important problems.
Once the house is built (our analogy for building a software platform), the initial excitement dwindles, but the work is far from done. Just like your new home needs ongoing maintenance to ensure it stays in a good condition, your software – particularly if it’s a software-as-a-service product – needs the same upkeep to ensure it remains functional and relevant to users.
We are not talking about adding new features. That’s fun. Maintenance is not. At its best, proper maintenance is carefully planned, forecasted, budgeted, and executed, often without anyone noticing, making it far less sexy than new feature development. Yet, with your new home, as with your company’s software product, you ignore these essential maintenance tasks at your peril.
Often, teams with great ideas are understandably keen to see the product come to life quickly as part of a mission to attract new users and generate additional revenue. However, this is only one facet of software development. Just as the concrete foundation of a new house needs a few weeks before it’s strong enough to be built upon, the same applies to software. Skipping important steps at any point in the process could be costly or even disastrous in the long run.
Many homes aren’t properly inspected until they are up for sale. That’s often when serious issues, such as mold, are first discovered, jeopardizing a sale or resulting in a substantial reduction in market value.
Unfortunately, this is also true in software development. Investor due diligence (when an investor does a thorough check of the business and its assets) is similar to a home inspection and is often the moment when product teams first realize the extent of the liability associated with their deferred maintenance.
Due diligence often entails a number of evaluations, including a security risk assessment and code review. If the software application has not been properly maintained and too much “tech debt” is discovered at this point, the deal may not go through.
Technical debt is a term that refers to consequences that arise due to poorly written code, poorly planned code architecture, neglected upgrades, and other compromises often made to save money and move faster. Like financial debt, if your technical debt is left unpaid, it will cost you more later and could even result in the loss of your assets. Since a credit rating isn’t available to evaluate your debt, the prospective buyer will likely require a deeper dive to assess the entire stack as part of estimating the total tech debt.
The only way to avoid this is to commit to regular maintenance and risk analysis from day one. In the case of software, what does regular maintenance entail and whose responsibility should it be? If a due diligence event becomes your team’s trigger for maintenance, it might be too late to react without consequences.
In this article, we argue that only an experienced team of technologists and product owners has the perspective to foresee potential risks and put the necessary processes in place to avoid or mitigate them. Assigning your maintenance tasks to such a partner, internally or externally, is the best way to ensure the longevity and success of your software product while also keeping your valuations at the highest multiples.
This refers to the infrastructure of your software product. Due to cost issues, some owners may be inclined to choose a self-hosting solution, unaware of the risks and complexity this choice introduces. If the server is down, the software is not usable unless there are backup resources and teams working around the clock. The existing infrastructure may be assessed if the buyer intends to leave the application in place.
Instead, a technology partner may advise on choosing the right hosting providers with distributed networks and content delivery systems that provide close to 100% up-time. They also offer out-of-the-box security and incident management which would be very expensive and complex for a single company to deploy and maintain.
The foundation of a product is dynamic and is continuously changing. Many of these changes, such as security patches, are minor and can be done without any interruption to your clients, but not all updates can be made without interruption.
The maintainability and scalability of this foundation will be thoroughly examined during a due diligence exercise as prospective investors or new owners will want to understand how easy it is to scale or grow the product and what type of additional investment is required to do so. If there are major flaws that prevent efficient and rapid growth, they may reduce the overall valuation or, even worse, become obstacles to a transaction.
The software framework is the largest element of the application’s environment. It’s used by developers to implement the standard structure of application software. These frameworks are maintained by the publisher with security and bug fixes, with new versions released periodically. Maintaining the current version in this part of the environment is crucial to ensure support. This requires testing the application at each new framework release. As time passes (and it passes quickly), and upgrades aren’t tested and completed, they accumulate as tech debt, which was discussed earlier. Your application will be tested upon each new release. It’s just a question of doing it all at once or a little at a time. It takes discipline and a planned approach to accomplish this as time passes, and not as a large project at some point in the future, where there may be a looming deadline.
Speaking of looming deadlines. In rare instances, the original framework may even be “sunsetted”, which means support for the framework ends. This occurred recently with Angular. This doesn’t necessarily mean the product stops working, but that security and functionality (bug) patches will no longer be provided. When this happens, it puts your business and clients at risk. It also makes the product unpalatable to investors.
Sunsetting doesn’t just happen overnight. Users have time to plan for it, provided they are aware of it and know what to do. What needs to happen, is to move the application to another framework, which is no small feat. Changing frameworks can involve close to a complete rewrite of the application, taking months to complete. In rare cases, a third party that offers extended support of the application frameworks past their sunset time may be available but be prepared to pay a premium. Consider it a down payment on paying off your tech debt.
This is a severe, but very real, example. Maintaining the current version of the framework ensures the latest security and bug fixes are deployed. It also means if the application were to be moved to another environment, it would work with the current version of the framework, which is the one that will be deployed in the new infrastructure. This is obviously important if the buyer plans to move it.
Another example of how tech debt translates into real money involves an outdated version of Python. When the platform was moved to a new infrastructure, the automatically deployed high capacity/availability option wasn’t available because it used the latest version of the language. This required a custom-built infrastructure that costs more to design, build, and maintain.
Experience plays a major role when planning on which framework to use in the first place.
Choosing the right framework with broad-based support, documentation, and a long projected lifespan can pay significant dividends in the future, whereas the wrong one can cause engineering churn and downtime.
What constitutes “the right” framework depends on many factors, including how easy it is to modify or add new functionality and what the framework’s talent pool looks like. Periodic research into the framework’s industry usage and future plans is crucial.
An experienced partner will know what to look for and how to help you navigate your way around or through these risks so that your team can stay focused on innovation and optimizing user experience.
A code review typically confirms that best software development practices have been followed in the creation of the application.
In the same way that a property condition report helps a homeowner get a baseline understanding of the home’s condition, a software code review provides the recipients with a baseline understanding of the accumulated tech debt and overall scalability. It’s about the construct, and ultimately the portability and maintainability of the code for current and prospective owners. More importantly, it asks the question: What will it take to modify or add new functionality?
Scalability or maintainability is especially important during a due diligence assessment when an acquisition hinges on how easy it is for the potential new owner to scale the business and maintain the codebase at reasonable levels of cost and effort. In this area, a monolithic code-base (aka spaghetti code) is a red flag. It puts immense complexity on the developer’s plate to search and find the needle in a haystack every time changes are required. As a result, the development speed is poor and it is difficult, if not impossible, to scale.
A code review looks at system design, architecture, codebase size, technologies used, and complexity. It illuminates the privacy and security risks, as well as any 3rd party dependencies.
The robustness of algorithms and data models may also be evaluated as part of a deeper investigation. An algorithm represents a succession of steps to solve a specific problem. These optimized solutions (algorithms) are grouped into reusable libraries to reduce development time in the future and make the code more transferable and maintainable. A proper evaluation can help determine how durable and scalable the algorithms and data models are for future growth.
The review doesn’t just look at the minutia. It also examines the trajectory of the application and its framework for the future. Only an experienced product owner or technologist who has launched and maintained numerous products before, having learned through their mistakes, will see the full picture. It’s the difference between what the strategy says and what really happens that differentiates the great teams from the average teams.
Returning to the home analogy, security is more than just checking the locks on the doors. It includes motion-detecting cameras, sensors, and more.
Updating security patches in software is part of the ongoing maintenance discussed above. This includes incident or defect analysis, privacy and security risks, 3rd party dependencies (open source or another kind), and infrastructure risks (servers, cloud, hosting). This part of the due diligence will also examine your protocol for command and control of machine and human access to information and will document any anomalies.
In some industries where the law requires that data security standards be met at the risk of stiff penalties for any breaches, companies are required to establish and maintain a data security plan. These plans are usually based on one of several different established frameworks and are as focused on human processes as they are on the underlying technology.
In the case of nontechnical security processes, it’s important to have procedures and training codified in corporate governance documentation.
For these reasons, a security assessment is an important part of the due diligence often demanded by potential acquirers, larger customers, and investors alike. It’s all about the potential risk. Finding it, recognizing it, and doing everything possible to eliminate or mitigate it.
While previous sections discussed the foundation, application environment, and the current state of the code, there is another very important aspect of due diligence. It’s the product’s future life. A clearly defined product roadmap is required during due diligence.
Just as the product has a future, so does the house it lives in. A well-documented plan for the future of technology maintenance is critical to surviving due diligence.
Yes, important humans are also involved. There must be product and process documentation that mitigates the loss of a “key person’s” departure. This documentation should be sufficient to operate the application in the key person’s absence.
The involvement of an experienced technical product owner from the outset is very beneficial as they’ll be able to advise on issues such as setting up the right infrastructure, choosing the best environment, and maintaining it. Ensuring no crucial steps are missed
If these maintenance activities are managed methodically and integrated into the feature enhancements and new releases, product teams can easily plan the future work needed to maintain the product and wow analysts during due diligence.
Experienced entrepreneurs and technical product owners who have bought and sold their own companies, know what to look out for and are able to advise product owner(s) on how to combine their expectations with the reality of software development.
To ensure scalability, experienced partners will advise on the use of modern frameworks and libraries, as well as out-of-the-box hosting solutions to scale a product seamlessly. They can assess the product’s scalability from the outset and advise on factors that influence future growth.
At REEA Global – all our team members are experienced entrepreneurs who have launched dozens of new products, started and sold companies and all the other stuff that founders do. We are not consultants, we are builders and entrepreneurs who work alongside you as partners helping to keep your product in optimum health to optimize your engineering efforts, accelerate your product development, and maximize its value.
Our experience means having the right people in your corner to keep your house in order.
Contact us to see how we can help you increase valuation and reduce tech debt.
The imminent sunset of Drupal 7 signals a crucial juncture for enterprises.With January 2025 fast approaching, the end-of-life for Drupal 7 necessitates immediate attention and strategic action.
At the core of every digitally-driven business resides a network of intricately interlinked processes and workflows, serving as the bedrock of organizational productivity and triumph.With extensive experience in leading product teams across various industries, we've witnessed firsthand the challenges businesses face as they approach expansion and evolution.
In the dynamic world of software development, leadership transitions bring both opportunities and challenges.As a new leader in a pivotal role with decision-making authority related to software development projects, you may find yourself at a crossroads where you have the power to effect significant change.
” Their work was on time, within budget, and of the highest quality. In addition to their core expertise, the REEA GLOBAL team has a lot of skill in anticipating unspoken needs. The result was a final deliverable that was much better than envisioned ”
Court – Executive Director
” Our entire team, including our executive leadership, found this to be an incredibly valuable investment that allowed us to change a few things, even mid-build to ensure the next version release of our product was as user-friendly as possible ”
Jessica – Head of Product
” They went above and beyond meeting our design needs and easily saved our company 6 months to a year’s worth of work. REEA delivered a gorgeous product design that put us on par with our much larger competitors. We are now punching way above our weight and REEA is one of the reasons why. ”
Tim – Co-Founder
” It has been a pleasure to work alongside their experienced frontend and backend developers as a team to meet our product goals. REEA Global’s staff is professional, reliable, and trustworthy — a great partner through the challenges of software development. ”
Deena – Head of Product
” The team is super responsive and is helping us prioritize our needs. The weekly meetings allow us to check in and give us an opportunity to bring up issues in a timely manner. ”
Karen – Director of Clinical Programs
” The team was organized and prepared in addition to providing the executive team with seamless communication and full transparency during the process, something we had lacked in prior relationships I would highly recommend the REEA Global team. ”
Evan – CEO & Founder
” REEA was seamless in their setup and, more importantly, integration with the existing team. The work product was excellent, and we certainly plan to keep using them ”
Jason – CEO