Tech Stack

What is a tech stack?

Tech stack (technology stack) describes the totality of technologies with which a software product is developed, operated and delivered: programming languages, databases, server and cloud infrastructure, integrated services from other providers, and tools for development, testing and monitoring. The image of a stack describes layers that build on one another: at the top the interface that users see, at the bottom the machines on which everything runs. Third-party services are usually connected through a programming interface (API).

The tech stack is not purely a matter for the development department. It determines development speed, staffing needs, running costs and dependence on individual providers and people. In a financing round it is the subject of technical due diligence, that is, the review of technology and operations by investors. In a company sale, transferability and integration at the buyer are added.

The layers and how they are chosen

• Interface (frontend): everything that users see and operate in the browser or in the app.
• Application logic (backend): the processing of data and business rules on servers.
• Data storage: databases, caches and file storage.
• Infrastructure: data centre or cloud, network and security services.
• Tools: management of the source code and its versions, automated testing and delivery, monitoring of operations.

In selection, commercial criteria count for more than technical preferences. Widely used technologies make recruitment easier and shorten onboarding. Mature components with active maintenance reduce the risk of missing security updates. Ready-made services speed up the start but tie the company to one provider; in-house development is more flexible but ties up staff. For data storage, location also matters: the transfer of personal data to states outside the European Economic Area is subject to the requirements of Articles 44 et seq. of the General Data Protection Regulation (GDPR).

Costs and dependencies

The costs consist of usage fees for cloud and third-party services, software licences and the personnel for development and operations. Cloud costs grow with usage and, for software providers, count among the direct costs of revenue. If they rise faster than revenue, the gross margin falls, that is, the share of revenue left after these direct costs. Investors therefore look at infrastructure costs per customer over several years, because they show whether the business model is actually scalable.

Under German commercial law, the development costs of internally generated software in fixed assets may be capitalised under Section 248(2) of the German Commercial Code (Handelsgesetzbuch, HGB), that is, recognised in the balance sheet as an asset. Research costs may not be included under Section 255(2a) HGB. In the tax balance sheet, by contrast, internally generated intangible assets may not be recognised (Section 5(2) of the German Income Tax Act, EStG). Whether expenditure on the tech stack appears immediately as a cost in earnings or as an investment (opex or capex) influences earnings and the comparability of metrics between companies.

Dependencies arise on providers and on people. Services that only a particular cloud provider offers in that form can often be replaced only with considerable effort (lock-in effect). For every business-critical service, it must also be checked what availability the provider commits to in its service level agreement (SLA). Even more common is dependence on a few developers who are the only ones to understand a central component. Integrated open source building blocks additionally bring licence obligations.

Transferability on a company sale

In a share deal, the purchase of the shares, contracts with cloud and licence providers remain with the company. However, termination rights on a change of control and licences tied to a particular company or number of users must be checked. In an asset deal, the purchase of individual assets, contracts must be transferred individually, which requires the consent of the respective counterparty.

Access that runs in the name of founders or employees personally is often overlooked: cloud accounts on a private credit card, domains in their own name, code management in private accounts. These should be transferred to the company before a sale process begins. Equally important are the rights in the source code. For programs that employees write in performance of their duties, the economic rights belong to the employer under Section 69b of the German Copyright Act (UrhG). This does not apply to code from freelance developers or from founders before the company was founded. If there is no effective grant of rights, an IP assignment must be made up, that is, an express transfer of the rights of use to the company.

Review by investors and buyers

In technical due diligence, buyers review architecture, currency of components, security and dependencies. Four points are at the centre:

• how many people can maintain each business-critical component,
• which components no longer receive vendor support,
• how long a finished change takes to be delivered,
• whether the technology fits that of the buyer.

The result feeds into integration planning, that is, the planning of how the acquired company is to be integrated, and, where modernisation is needed, into the purchase price. Investors in a financing round usually review less deeply. They look above all at whether the stack carries the planned growth without a rebuild or whether part of the new capital would have to go into modernisation.

Practical example

A software company for route planning with EUR 6 million of recurring annual revenue is sold to a strategic buyer. Technical due diligence produces three findings:

• The route calculation is written in a rarely used programming language that only one developer masters. The buyer agrees a retention bonus with that developer and plans a second person for onboarding.
• The cloud account runs in the name of a founder. The transfer to the company is included in the purchase agreement as a closing condition, so the purchase is completed only once it is met.
• A commercial database licence is restricted to the existing company and ends on a change of control. The seller obtains the licensor's consent before signing.

None of the findings prevents the transaction. Together, however, they extend the timetable by several weeks and shift negotiating room to the buyer, because the seller must promise remedial work under time pressure.

Distinctions from related terms

• Technical debt: the future additional effort that arises from quick rather than sustainable solutions and from outdated components. A modern tech stack can contain high technical debt; an older one can be carefully maintained.
• Software architecture: describes how the components of a system work together. The tech stack names the technologies with which this architecture is implemented.

Common mistakes

• Choosing by preference. A modern technology that nobody on the team masters slows development more than a familiar one.
• Splitting into individual services too early. For small teams, a finely distributed architecture causes more operating effort than it brings in flexibility.
• Unknown switching costs. For every business-critical dependency, it should be known what a switch would cost and how long it would take.
• Accounts in private individuals' names. Cloud, domain and code accounts in the names of individuals make transfer harder and stand out in every due diligence.
• Outdated components. Components without vendor support no longer receive security updates and later force costly migrations.

Frequently asked questions

Does the tech stack influence company valuation?

Indirectly, through development speed, gross margin and risk. If a buyer must plan a multi-year modernisation after the takeover, it deducts the cost from the purchase price or demands contractual protection.

Do investors prefer particular technologies?

No. What matters is that the stack fits the business model, is widespread enough for recruitment and can continue to be operated without individual key people.

When is it worth rebuilding the tech stack?

When the technology demonstrably holds the business back, for example because customer requirements cannot be implemented or infrastructure costs per customer are rising. A rebuild without a business reason ties up capacity that product development lacks.

What should be developed in-house and what bought in?

As a rule, everything that is not part of the core of the offering is bought in, for example payment processing, sign-in or message delivery. In-house development is used where the company's competitive advantage arises.

The Roemer Capital view

For every business-critical component, Roemer Capital asks before a sale how many people can maintain it and in whose name the associated accounts and contracts run. The answers reveal technical dependencies faster than an architecture discussion, and buyers ask the same questions.

In addition, Roemer Capital prepares the infrastructure costs per customer over several years, because they support the gross margin assumptions in the financial model. The clean-up of accounts, licences and chains of rights is initiated so early that the data room is ready within 24 hours at the start of the process.