Technical debt in software projects of innovative type

The article discusses the feasibility of using rapid architectural solutions in innovative projects. The main thesis of the article is that the conscious use of the technical debt concept at the early stages of high-risk software helps save financial and human resources. Refactoring, i.e. improvement and optimization of software architecture is an important component of the development process. However, it is better to verify the business model first. At the early stages, prior to the confirmation of the business hypotheses regarding the market, deep refactoring can slow down the prototype production and increase the project budget, even before confirmation of its commercial potential. Some limitations should be taken into consideration. The process participants should understand the concept of technical debt and use it intelligently. Even at the early stages of the project, prior to the business model verification, one can complicate the development significantly, if he/ she neglects the internal quality of the code. If technical debt inhibits the project development, compromises its launch or makes the system unstable, it is unacceptable. There are three areas of software engineering, which can accumulate technical debt: at the level of the domain model, software architecture and software code. Each level can accumulate technical debt, thus they should be monitored. Refactoring is most time-consuming and costly at the first and second levels. One should cut costs (to confirm the business model) in the first place but this is not always possible. The cases of searching for a product/service can be an exception, as the elaboration of the project and its specification occurs in the process of development.