Why a project slows down: mistakes in choosing a technology stack
Most often, a project hits a ceiling not because of load, but because of decisions made at the start.
The layers were chosen separately — the frontend with one tool, the backend with another, storage with a third — and incompatibility of components appeared at the junctions: data formats have to be converted on the fly, part of the logic is duplicated, and every new feature becomes overgrown with scaffolding.
The architectural bottleneck in such a project is not where it is sought by metrics: the server handles the load, but response time grows because of unnecessary transformations between layers.
The second source of slowdown is unnecessary dependencies. Each connected library solves a task quickly, but drags along a chain of updates, version conflicts, and vulnerabilities that need to be closed.
After several releases, the team spends more time coordinating updates than on the functionality itself, and the site's technical debt grows faster than capabilities are added.
The third reason is the absence of a development plan. The stack is selected for the current task without checking whether it can withstand growth in the number of users, integrations with external systems, and the transition to a mobile client.
When such a moment arrives, it is not a single module that has to be rewritten, but entire interconnected layers.
Choosing a technology stack is not about trendy tools, but about compatibility of layers, a controlled number of dependencies, and headroom for development. We break down how this is checked before work begins and what to do if the project has already hit a ceiling.
What a well-thought-out stack delivers: speed, reliability, growth
A well-chosen set of technologies shows up not in a presentation, but in day-to-day metrics: how quickly the team ships changes, how the application behaves under peak load, and how much it costs to plug in a new module.
If the stack is matched to the task rather than chosen "out of habit," these figures differ by multiples, not by percentages.
Project build and deploy time. When the frontend and backend use coordinated build tools and a unified configuration format, the build runs incrementally — only the changed part is rebuilt.
A typical release fits into minutes instead of tens of minutes, and deploying becomes a routine operation the team performs several times a day without fear.
This directly affects the speed of shipping new features: the shorter the cycle from edit to production, the faster the product responds to business needs.
Resilience to load. A well-chosen stack assumes horizontal scaling from the outset: the application does not store state on a specific server, and sessions and cache are moved to external stores.
As traffic grows, application instances are added rather than the architecture being rewritten. This removes the main risk — that the site goes down at the very first spike in traffic, and every minute of downtime costs lost orders and reputation.
Extensibility of the web application. A stack with clear boundaries between modules and standard interfaces makes it possible to plug in new services — payments, a user account area, integration with an accounting system — without rebuilding the core.
A new module is added as a separate component rather than being cut into existing code, so the enhancement does not break what already works.
The cost of downtime and maintenance. A predictable stack is easier to maintain: fewer exotic dependencies means fewer sudden breakages after updates, and it is easier to find an engineer as a replacement.
This reduces not only the direct losses from service unavailability, but also the cost of ownership over a horizon of several years.
That is precisely why we start choosing a technology stack from your load scenarios and growth plans, rather than from trendy names. Describe the task — we will come back with an estimate and a plan.
Comparison of approaches: monolith, modular monolith, separation of layers
The choice between these options is not a matter of taste, but a function of team size, rate of change, and how long the product will live. A monolithic architecture delivers the fastest first version: one codebase, one deployment process, transactions work out of the box.
The limitation shows up later — any change affects the shared contour, and the cost of a fix grows along with the number of scenarios.
A modular monolith keeps a single deployment but fixes module boundaries at the level of code and data schema: a module is responsible for its own area, accesses its neighbors through an explicit interface rather than through direct queries to others' tables.
This removes the main pain of a monolith — coupling — while not requiring the infrastructure of a distributed system. Separation of layers (extracting individual services) is justified when part of the system has its own load, its own release cycle, or a separate team.
| Option | When it fits | Limitations |
|---|---|---|
| Monolithic architecture | One product, a small team, a short path to the first version | Fixes affect the shared contour, tests and release slow down as the code grows |
| Modular monolith | The product is growing, areas of responsibility emerge, but a single release is still convenient | Requires discipline: without boundary control, modules grow back together |
| Separation of layers | Areas with different loads or separate teams and releases | Debugging and deployment are more complex, contracts and observability are needed |
In practice, the transition goes from left to right: you start with a monolith, at the first signs of coupling you extract modules, and only then do you extract what truly requires independence.
The reverse order — splitting right away — almost always produces a distributed system with all its overhead where careful boundaries within a single application would have sufficed.
How we select a stack: stages of engineering work
Selecting a stack is not a vote for a favorite framework, but a sequence of verifiable steps. Each stage ends with an artifact that can be shown to the team and double-checked, so the decision does not rest on one engineer's personal taste.
- Audit of the current solution. We look at what is already working: code structure, dependencies, frequency and causes of failures, build and deployment time, load bottlenecks. We record what we reuse and what is cheaper to replace than to carry forward.
- Gathering requirements and constraints. We analyze the load profile, growth scenarios, availability and security requirements, your team's competencies, and hiring plans. A stack that no one can maintain is a risk, not a technology.
- Designing the component scheme. We break the system into layers: interface, server logic, storage, integrations, cache, background tasks. For each node — options and a selection criterion, so the decision can be read without the author.
- Testing hypotheses on a prototype. Contested areas — load, integrations, response speed — we test on a minimal stand, not in words. A hypothesis is either confirmed by measurements or discarded before the main development begins.
- Comparing alternatives and choosing. We compile the options into a table by time to first version, cost of ownership, risks, and entry threshold for the team. We choose not "the most modern," but what gives a predictable result.
- Implementation and migration plan. We define the order of work, rollback points, the method of data transfer, and compatibility with legacy modules. Separately, we discuss how the system lives during the transition period.
- Handover of documentation and regulations. We hand over the component scheme, the rationale for the choice, build and deployment instructions, dependency update rules, and the maintenance regulation. Your team continues the work without us.
Describe your task — we will come back with an estimate and a plan for each stage.
What the client receives: configurations, diagrams, regulations
Project documentation is written not "for show," but as a working tool: with it, a new engineer can deploy the environment without calls with the author, and the operations team understands what to update and when. Below is what exactly remains with you after the stack selection stage.
- Stack description and rationale for the choice — which components were taken, which alternatives were rejected and for what reason. Six months later, this removes the question "why do we do it exactly this way."
- Component interaction diagram — application, database, cache, queue, external services: who communicates with whom, over which protocol, where the trust boundary lies.
- Access policies — roles, read and write permissions, environment separation, rules for handling secrets and keys. Separately — what is prohibited in the production environment.
- Deployment instructions — a step-by-step procedure for bringing up the environment from scratch, including configuration variables and a health check after startup.
- Update regulations — how a new version is rolled out, how changes are rolled back, who makes the decision and by what criteria a release is considered to have gone smoothly.
- Backup and recovery scheme — what is backed up, at what frequency, how long it is stored, and how to verify that the backup actually restores.
- Responsibility matrix — which work our team covers, what is handed over to your engineers, whom to contact in case of failure.
The package is designed for handover: if you decide to run the project on your own or change contractors, onboarding takes days, not weeks. The documents are updated together with changes in the stack — an outdated instruction is more dangerous than its absence.
Case study: how rebuilding the stack eliminated a class of failures
The project is an online store with a catalog of several tens of thousands of items. The stack was assembled piece by piece at different times: a monolith with business logic, a separate search service, synchronous calls to external systems directly in order processing.
While the load was small, the scheme held up, but every deployment turned into an event: releases were scheduled at night, the window was agreed in advance, rollback took hours and required manual actions.
Case study from our practice: we analyzed why failures recurred and rebuilt the scheme of service interaction rather than simply "fixing" yet another incident.
What it was like before the rebuild
Failures came in a single class: a failed external call dragged down the entire order, and after it the catalog and the cart. The frequency of failures was several times a month, each time with manual investigation.
Recovery time was measured in hours: first they found the culprit, then brought the service up, then reconciled the data. Deploying a new version took almost a day, including the window and checks.
What was changed
Critical paths were separated: order processing no longer depended on a synchronous response from external systems — a queue and retries with a limit appeared. Search was moved to a separate contour with its own cache so that a failure wouldn't bring down the catalog.
Build and deployment were switched to automated checks: a version is brought up on a test contour, passes a set of checks, and goes to production without manual steps, while rollback is a return to the previous image.
What it became
The class of failures "external call went down — order went down" is gone: failures of external systems are now absorbed by retries and don't reach the user.
The frequency of incidents dropped by a factor, recovery time — from hours to minutes, because rollback became a single operation. Deployment speed grew from a day to tens of minutes, releases stopped being an event and proceed as they are ready.
A separate effect is predictability: the team sees which node has degraded and responds in a targeted way rather than restarting everything.
This is exactly the result of a competent choice of technology stack — not a set of trendy tools, but a scheme in which the failure of one node does not turn into a failure of the product.
How does choosing a stack for a website differ from a web application?
The difference starts with the question "what does the system store and to whom does it serve it". A content website is primarily the delivery of prepared pages: text, images, markup for search.
Here the stack is chosen for delivery speed and editor convenience: static generation, edge caching, ready-made content management systems. The load is predictable, state between requests barely lives, and traffic peaks are absorbed by cache rather than server power.
A website or a web application — the fork is exactly here. As soon as a personal account appears, the requirements for the stack change: authorization and permission separation are needed, server-side logic on every request, transactions when writing data.
The response can no longer be cached — it is unique to each user and changes with their actions. Add integrations with payments, inventory, CRM, or an external API — and the stack must be able to reliably survive third-party failures: retries, queues, idempotency of operations.
Hence different selection criteria. For a website, what matters is delivery speed, ease of edits, and maintenance cost. For an application — predictability under load, maturity of database handling, availability of ready-made libraries for authorization and background jobs.
The mistake is dragging a heavy server architecture "for future growth" into a content website, or, conversely, building a personal account on a blog engine: the first option complicates maintenance without benefit, the second hits a ceiling on the very first integration.
Stack requirements should be fixed before the start, not along the way: how many user roles there are, which external systems we connect, what happens when they are unavailable, how often content changes.
The answers to these questions directly determine whether a separate server-side part, a database, and a task queue are needed — or whether static pages with a feedback form are enough.
Common technical concerns before starting
Before development begins, the same engineering questions almost always come up — they are not about "which language is trendier," but about how the new stack will coexist with what is already running.
Below is a breakdown of typical concerns that we resolve before the first line of code, not during the process.
Will the new stack break the current infrastructure?
We verify compatibility at the protocol level, not on promises: how the application talks to the existing database, queues, cache, file storage, how it fits into the current load balancing and logging scheme.
If the site already has servers, a reverse proxy, and monitoring — the new service must slot in alongside them, not require rebuilding the entire perimeter.
As a result, you get an integration diagram with connection points and a list of what will need to be additionally configured.
Can the transition happen without taking the site down?
Yes, with phased migration: traffic is switched over in parts, and the old and new versions run in parallel on a shared database for a while. First we move reads, then writes, reconcile the data for discrepancies, and only then shut down the old perimeter.
Rollback means routing traffic back to the previous version, not restoring from a backup. That is exactly why we plan the migration in windows and with a point of no return that can be crossed in either direction.
What should be done with the legacy code that supports the current site?
Old modules do not necessarily have to be rewritten entirely — some are covered with adapters and left running as long as they cope. We rewrite only what is holding back development or harboring vulnerabilities.
This approach reduces transition risks: you do not change everything at once, but replace bottlenecks by priority while keeping the rest operational.
How can transition risks be assessed in advance?
We break the transition down into stages and for each one record what could go wrong: incompatible data formats, performance degradation, loss of some functionality. For each risk there is an action plan and a criterion that shows the stage has gone smoothly. This turns a "blind migration" into a manageable process with clear checkpoints.
Let's discuss your task and come back with an estimate and a plan
To come back with a stack assessment rather than generalities, we need context about your situation. Describe what you already have: the current website or application, what it's built with, who maintains it and how, what loads it handles and where it starts to hit its limits.
If the project is only being planned — tell us about the task, the audience, and growth plans, so we can propose options for a real scenario rather than "for future growth."
After the review, we come back with a work plan that captures:
- Assessment of the current stack — what works, what's slowing down development, and what can be reused without rewriting from scratch.
- Technology stack options — 2-3 alternatives with honest pros and limitations for each, rather than a single "only correct" one.
- Selection criteria — what loads, growth rates, and team size each option suits.
- Implementation stages — a sequence of steps with points where you can stop or roll back the solution.
- Risks and dependencies — what could delay the work and how we close that out in advance.
- Compatibility with the current infrastructure — hosting, integrations, access, data.
- What will be needed from your side — access, contacts of responsible people, priorities on timelines.
Discussing the task doesn't commit you to anything: the goal is to understand the scope and give you material for a decision, even if you end up working with another team.
Describe your situation in whatever form is convenient — a short email or a 30-40 minute call — and we'll come back with a stack assessment and a work plan.