# Notino: a faster platform and ten times the request capacity

> Notino's monolithic storefront slowed pages and releases. Microfrontends and reorganized teams made it 60% faster with ten times the request capacity.

- Canonical: https://techmates.io/en/case-studies/notino
- Client: Notino
- Industry: E-commerce
- Published: 2026-08-19
- Services: Custom software development
- Technology: Microfrontends, E-commerce platform

---

## One tightly coupled application slowed a global storefront

Notino sells beauty and fragrance online across many markets, from a broad catalog. For a shopper, a slow page or a broken release is part of the same experience as finding the right product.

The storefront ran as one monolithic application. Pages loaded slowly, errors were frequent, and every frontend change traveled through the same release path. The customer base kept growing. The application did not keep up.

### Shoppers needed faster pages and fewer broken releases

- Faster page delivery across a broad catalog
- Releases an international operation could rely on
- Room for more requests as the customer base grew

### The monolith tied every team to one release

- Frontend work coupled to the whole application
- Performance delays and frequent errors
- Release dependencies that decided how often teams could ship

## We split the frontend, then rebuilt the teams around the split

We designed a microfrontend architecture: the frontend divided into parts that separate teams develop and release on their own, with far less dependence on the monolith. Delivery continued while the parts were carved out one at a time.

Architecture alone would not have changed how often Notino shipped. We reorganized the frontend teams around the new boundaries so that each area had an owner and a release path of its own. Speed, error rate and request capacity were treated as one problem with the team structure, not as a tuning exercise on the side.

### Each frontend area ships on its own

Frontend areas became independently deliverable parts. A change in one area no longer had to wait for, or risk, a release of the whole storefront.

### Team boundaries follow the technical ones

Teams were reorganized so the architecture could carry more frequent releases. The wider e-commerce platform stayed in place; the frontend stopped depending on its monolithic release.

## Faster pages, more capacity, more releases

| Metric | Before | After |
| --- | --- | --- |
| Page speed |  | 60% improvement |
| Request capacity |  | 10 times more requests per minute |
| Release frequency |  | 10 times more frequent releases |

## The numbers describe a period of change, not one fix

The project record reports a 60% improvement in page speed, capacity for 10 times more requests per minute, 10 times more frequent releases, and fewer bugs after the change.

The figures cannot be attributed to a single technical change. They come from a period in which the architecture, the development practices and the team structure changed at the same time.