Startup Software Development: How to avoid key mistakes in primary architecture and technology choices
Startups, i.a. due to their dynamics and various factors that put pressure on them, e.g. the pressure of time and expectation of shareholders, must face challenges during software development, that the large organizations with a well-established position are not facing, or must overcome them, but to a much lesser degree.
However, an important role is played primarily by financial limitations. In the case of large organizations, we often speak of their „too big to fail” status, i.e. a situation where a company had expanded to such a degree, that its possible failure will be followed by problems for its partners, or even entire industries. In terms of startups, the „too big to fail” status cannot apply, while financial amortization of failures is barely there.
I.a. that is why it is advisable to distinguish between these areas of operations, on which software development startups should focus primarily and, in essence, unconditionally, regardless of whether it is a company operating in fintech, insurtech, or on the social media market. While it may seem, that in each case one should execute different approaches, there are some common denominators that should be a must-have for all startups from the very beginning.
How to avoid key mistakes in primary architecture and technology choices
Table of contents:
1. Safety first
As we have been realizing through the recent years, one of the aforementioned is to design a service so that its security is a priority from the very beginning. The majority of European and global norms, as well as, local regulations, place particular requirements on all enterprises, including startups, regarding auditing, regular internal testing of security, infrastructure, as well as, software in compliance with the doctrine of offensive security.
However, we are speaking of a situation, where we are dealing with a mature product. Appropriate security standards may be implemented from the first line of code. Recently, the discussion has been brought up by i.a. Microsoft which noticed that most vulnerabilities comes from flaws in memory management, resulting from the lack of appropriate mechanisms in C and C++ programming languages. Redmond experts are currently performing test conversions to Rust – a programming language which is safer regarding memory management.
A similar approach is more often executed in terms of high-level code, with which startups must work on an increasing scale. Here, Microsoft may also be an example, as they developed an original version of the JavaScript language, called TypeScript. As the name indicates, it is focused on strengthening mechanisms related to type security, while being more clear than JS. Startups cannot allow themselves to develop a solution and perform tests and audits afterwards. Security must be a priority from the start.
Obviously, in pair with code, security of infrastructure that stands behind it must also be a priority. One may extensively rely on European norms, that strictly regulate, how to secure back-end, i.a. by conducting regular, internal and external audits, or the procedures of reacting against incidents that violate cybersecurity. The core of security should be meticulously and regularly conducted security tests, both unit and modular. It is incredibly important to apply tools allowing for automation of implementing code standards developed by a company. In architecture security, the ability to act preemptively, and to skillfully plan integration with external systems, e.g. by providing appropriate API, is worth its weight in gold.
The rest of the article is available below free e-book form.
2. Selection of scalable infrastructure
It often happens, that the initial plans of startups are focused on directing a product or a service to the local market, or at times, neighboring markets. Often the specifics of their operations are limited to a number of cities. However, if we approach the issue from the aspect of the designed software architecture, it may turn out, that local thinking will become a serious issue in the future. At times, an issue that cannot be solved. It may turn out that the solutions designed with a couple hundred thousand users in mind, will be difficult or even impossible to scale.
Therefore, if the dynamics of the startup plan expand and an expansion to other markets will be necessary, and possibly, a weighty expansion of the product’s functionalities (e.g. on the basis of the users’ feedback), one cannot allow the architecture designed at the initial stage of the project to become an obstacle during its evolution.
A similar case is with tools used directly to work on programming both within the area of used programming languages, as well as, frameworks. In case of architecture, a rich portfolio of cloud service providers lends a helping hand, as they may dynamically add and delete subsequent instances, regardless of the number of users, however, a project should assume such integrations from the very beginning. In terms of languages and frameworks, the selection should be dependent on the specifics of load and the experience of team members.
3. Localization, or even better – hyperlocalization
The matter of startup development and the necessity of preparing for software architecture development, further integration with other modules, as well as, ensuring a properly scalable and efficient infrastructure, is related with one more challenge: product localization. Obviously, we are not speaking solely of translating the application interface. This issue will surely be dealt with better and better, in time using automated machine translators. For example, already today, programmers who publish applications in Google Play may use automated translations.
However, the issue of localization is much broader, as was learned by American internet service providers after the launch of GDPR. For startups, ensuring legal compatibility of their solutions with the local market reality had been a priority from the start. There are more and more challenges, like the cultural ones, as well as… functional. An interesting case is Showmax, a company who offers VoD services, which, in African countries where there is often no access to payment cards, expanded its service with SMS payments.
4. Perspective technology selection
In the case of startups, it is not the best selection to follow trends, or tools which balance on the line of the legacy status. Both the aforementioned selection of programming languages, frameworks or methodologies, should be directed at long-time business plans and should be much more perspective-driven, than temporary business plans. As already mentioned, it is difficult to predict the direction and intensity of expansion, however, it even further forces startups to implement elements that will allow them to expand in a particular direction.
Currently, when even advanced applications operate on the basis of microservice architecture and are built from many modules (including external, open source ones, like Elastic products), standardized API, documentation allowing to update or even replace entire modules is a necessity. One must remember, that the adopted V test model, where both unit, integration, system and acceptance testing are performed. Therefore, not only modules, but also programs-converters or database modules will be put to testing.
5. Final thoughts on how to avoid key mistakes in primary architecture and technology choices
The greatest challenges, which startups must face, e.g. short deadlines, strict budget burdened with pressure from shareholders, and lacks in documentation or staff, allow to state that overcoming these obstacles is possible if a startup works on it from the very beginnings. Therefore it is important, to skillfully and consciously select both team members and the technology, so that their fluent scaling will be easier during every phase of project development.
The aforementioned limitations cannot be a justification for shortcomings in security, or in ensuring software quality. Underestimating these issues during initial phases of startup development may have grave consequences, when it comes into maturity, e.g. in form of data leaks of a large number of users of a given solution.
