One does not Simply Accelerate Development without Ready-made Solutions. Fact or Fiction?

Let’s consider the example of 3D modeling. It has a set of models, which can be used as a basis to create more complex ones. The approach is easier and a hundredfold faster than creating complex figures from the ground up. And here we can draw a parallel with development accelerators utilized as the basis for the future app. You couldn’t agree more, that growing business functionality on the ready-made sustainable backbone is easier and faster than dealing with the basics first.

Considering the example of a marketplace, basic functionality, such as authorization, logging in, roles distribution, password recovery, etc. are cornerstones of the application, however, they do not bring any business value. In the meantime, an online showcase or marketing automation is much more important from the business standpoint. Having adopted a ready-made backend, UI, database, and configured connections, you get a chance to channel your resources toward creating business functionality right away.

Rare businesses can afford prodigality, notably startups that require significant investments to be launched. Say, after calculations, you come to a conclusion that the startup accelerator program will save you 20000 USD. Within the scope of a big project with the cost of one million dollars, the percentage of saved amount will not be astronomical, and building basic functionality from scratch with own effort is completely justified. Which can not be said about the project with approximate estimations of 100000 USD. In this case, the saved amount will count 20%, which can be invested in more important things from the business standpoint. The difference is obvious to decide in favor of the startup accelerator program, isn’t it?

As a rule, ready-made functionality is written, fine-tuned, and thoroughly tested. Therefore, by adopting a development accelerator you prevent the risk of gaining delayed technical debt for the stabilization of an adopted third-party solution, including open-source ones.

Development accelerators are applied at the project start to speed up its time to market, so it’s clear that they will not do the trick for existing monolithic applications in use. However, when migrating the cumbersome full-fledged app to a new technical stack or proceeding with monolith to microservices migration — we in fact create a new project. In such a case we are given a chance to dramatically reduce development time owing to accelerators utilized as the basis.

Whichever way you look, a development accelerator is a terrific solution to typical problems faced by business owners launching their products. Faster time to market, rational resource management, minimized technical issues popping up in basic functionality — it’s quite enough to abandon putting effort into development from scratch and harness the development accelerator. However, there are multiple but’s that can’t be ignored.

As a rule, when you introduce an open-source solution, you need to verify the functionality, for which you’ve made the decision to adopt it. That’s why, eying an open-source solution as the development accelerator, keep in mind that its functionality may run counter your expectations. And this will entail additional efforts for code modifications, which is not that simple and cheap. For example, when you adopt an open-source library and make some improvements, you fully understand that further maintenance rests upon your shoulders. It means that in case the community detects a critical vulnerability, and patches the library, it will not appear on your site automatically. You will have to implement the patch manually, apply it, reassemble and maintain it in the usable condition. However, there is a piece of good news to share. Such a risk takes place for big projects only since relatively small ones have no need in cumbersome open-source libraries in general.

As a software development vendor, we know that one system can be built on the basis of different technologies. Especially, if we speak about a microservice system, where one service is developed with .NET, the second with Node.js, the third with Python, and so forth. And here we gain the technological zoo, which requires substantial resources to be maintained. One or even two software developers are not capable of supporting such a system, and taking into account the paychecks of such professionals, expenditures will result in hundreds of thousands USD monthly. Are you ready to pay such amounts for years? If not, it makes sense to base an accelerator choice on the company’s technological strategy and estimate if the decision won’t undermine your budget. Rewriting, searching for other solutions, and technical stack unification can be considered as a way of escape, but time- and effort-consuming, and no guarantee that it would be cheap.

It’s important to commensurate your system in use with the accelerator you intend to implement. Take, for instance, an automation system for a hospital, which is quite cumbersome but lacks email marketing automation. In this case, we can easily implement the accelerator of a similar system and customize it for our own needs. Therefore, the scope of this component will be approximately 5-10%, and integration and entailed maintenance costs will not be that significant. 

Consider also the opposite case when the system in use is much smaller than the accelerator. Say, a business owner’s software in use lacks the leads storage feature and desires to integrate the small system with Salesforce for this one single function. In this scenario, overhead expenses must be taken into consideration. Month-to-month license payment, multiple configurations, integration with the existing software — in total the expenses will turn out to be incomparable with the system written from scratch. Is your business ready to pay extra for knowingly unnecessary functionality? If yes, there are no obstacles.

For the avoidance of rough edges, entailing considerable expenses, paying due attention to the code quality is of critical importance. For example, you utilize the library, which implements non-critical functions. And meanwhile you have certain quality standards, for instance, unit tests coverage or configured linters. In case the library source code quality you introduce in the project does not correspond to the quality standards you adhere to, it will entail additional integration costs, including partial refactoring, or test coverage of used functions. Therefore, expenses depend on technological rules organizations follow.

This is a React-based library for routing fine-tuning. Say, you need to create a big catalog with multiple modules and goods categories. As a basis, you’ve selected the React framework due to its versatility and flexibility. The development process kicks off, and there comes a moment when you need to configure the linking of browser URLs with the website logic. The thing is that the existing routing feature in React allows for automating routing within one module only. If one module contains hundreds of elements, you won’t have to write the route for each element, but the template for each module must be written and configured manually. It seems to be not that time-consuming if there are 2-3 modules on your website. But if there are 50-100 of them?

To free developers from the necessity to waste precious time writing separate templates for each module, our engineers designed a specific library for routing fine-tuning. This React add-on you configure only once (it’s adjustable though) to ensure a flawless routing process across all existing modules. 

A seemingly simple thing helping save time at the initial testing phase is a checklist template for smoke testing. It implies a mini-test that can be expanded for regression and used as a basis for full-scale test case creation if we consider long-playing projects. Checklists split checks into templates, so you can select smoke, regression, statuses and a negative scenario. The approach saves time as you have a possibility to give a report at once and categorize checks.

We developed our own cataloged framework template with ready-made entities underlying other automation frameworks that we use for a variety of projects. This test base framework has off-the-shelf abstracts, entities, hooks and there is no need to write them from scratch. With the help of the framework a package of smoke autotests can be deployed within days instead of weeks. The approach significantly saves time and expenditures for testing, because the ready-made basis covers different cases, including mobile UI automation, web API automation, web regression and UI elements comparison.

A universal approach, which could be utilized by companies of all sizes and types, exists only in dreams. The choice of an accelerator affordable by an international bank will be absolutely unacceptable by a small local restaurant and vice versa. To do right at once, not to get stuck in the abyss of reworks and unnecessary expenditures, and not to turn the development accelerator into the development brake, it’s better to think carefully and pay attention to the accelerator’s characteristics: