Tech field report: why these stack choices at Fragments?

Choosing a tech stack is never a neutral act. It is a bet on the future, a trade-off between immediate velocity and long-term maintainability. At Fragments Studio, in 2026 we stabilized a coherent ecosystem built around TypeScript, favoring structure and predictability over pure raw performance.

In 2026, the web development landscape has never been so fragmented. Between the explosion of AI-native frameworks and the growing complexity of rendering tools, it is easy to get lost in the "hype". Yet a development studio has to give its clients a guarantee: that the code it produces will still be usable, performant and easy to hire for in five years.

Here is our detailed field report on our stack choices, our doubts and the compromises we accept every day.

Important note: This field report describes our default choices, not an imposed stack. Every project we support starts with an analysis of its constraints: existing technical setup, teams in place, budget, hiring goals, third-party dependencies. We always adapt our recommendations to the client's real context: choosing the best stack means, above all, choosing the right stack for this project.

Frontend: Why React + Vite rather than Next.js?

This is probably the topic that fuels our internal discussions the most. In 2026, React remains the dominant tool, but the way it is used has diverged.

Choosing the SPA with Vite

We chose to favor Vite for most of our business applications (SaaS, internal tools, dashboards). Unlike Next.js, which pushes more and more toward Server Components and a complex hybrid architecture, the React + Vite pairing lets us keep a clear separation between client and server.

Vite acts as an ultra-fast build tool that uses native ES Modules. At Fragments Studio, moving from Webpack to Vite cut our development server startup times by 85% (from 40 seconds to under 3 seconds on our largest projects).

• The compromise we accept: SEO. A purely client-side application (SPA) performs less well for initial indexing. For clients that need aggressive SEO, we switch to Next.js, but we accept the extra complexity (server cache management, hydration) only when it is strictly necessary.

Backend: NestJS and PostgreSQL, the predictability duo

For the backend, we standardized our development on NestJS paired with a PostgreSQL database.

NestJS: the structuring framework

We have often been tempted by the lightness of Express or the speed of Fastify. However, NestJS won out because it brings a structure inspired by Angular (Modules, Providers, Controllers). In an agency context, this structure is vital.

It lets a Fragments Studio developer move from one project to another without an architecture discovery phase. Everything is in its place. TypeScript support is native and deep, which guarantees end-to-end type safety.

Choosing PostgreSQL

In 2026, despite the rise of vector databases for AI, PostgreSQL remains our backbone. It is an ACID (Atomicity, Consistency, Isolation, Durability) relational database that now natively handles JSON and vectors (via pgvector).

• Comparison with MongoDB: We have moved away from NoSQL approaches for the core of our applications. The rigor of relational schemas prevents 90% of data bugs as the product evolves.

Mobile: The winning bet on React Native and Expo

For mobile, the question hardly comes up anymore: we use React Native with the Expo ecosystem.

Why not native (Swift/Kotlin) or Flutter?

Native development costs twice as much for a performance gain that is often imperceptible for 95% of business applications. As for Flutter, although it performs well, it imposes the Dart language, which breaks our 100% TypeScript team synergy.

Expo radically changed the game in 2025-2026. Thanks to Continuous Native Generations (CNG), we no longer need to handle the iOS and Android folders manually.

• Concrete benefit: We share about 30% of business logic (through internal packages) between our React web applications and our React Native mobile apps.

Infrastructure: AWS for control and scalability

Rather than depending on "all-in-one" platforms such as Vercel or Supabase (which we sometimes use for MVPs), we favor AWS for our production infrastructure.

App Runner and ECS Express Mode

We mostly use AWS App Runner for its simple container deployment, or ECS (Elastic Container Service) for more complex needs. In 2026, migrating to ECS Express Mode lets us reduce deployment latency while keeping full control over costs.

• The real doubt: AWS complexity is a burden. But the cost of leaving proprietary platforms is often higher in the long run. At Fragments, we prefer to invest time in Infrastructure as Code (Terraform) to guarantee our clients' independence.

The surrounding ecosystem: Better Auth, Shadcn and Framer

Beyond the main building blocks, our supporting tools make the difference on Developer Experience (DX).

1. Better Auth: In 2026, we replaced NextAuth and Auth0 with Better Auth. It is an open-source, framework-agnostic authentication solution that lets us keep control over user data while offering a modern experience (Passkeys, Social Login) without exorbitant recurring fees.
2. Shadcn/UI & Tailwind: We dropped rigid component libraries such as MUI in favor of Shadcn. The "copy-paste the code rather than import a lib" approach gives us full control over the design without the weight of a massive external dependency.
3. Framer for marketing: For showcase websites where design is a major stake, we use Framer. It lets our designers ship to production without going through a classic frontend development phase, which speeds up time-to-market by a factor of 3.

Frequently asked questions

Does Fragments Studio impose this stack on all its clients?

No. This field report describes our reference foundation, not a dogma. Before making any recommendation, we audit what already exists: languages and frameworks the in-house team already masters, hosting or compliance constraints, tools already in production, migration budget. If a client works with an experienced Laravel team, we are not going to impose NestJS on them. If a project relies on an existing Azure infrastructure, we integrate it rather than rebuild everything on AWS. Our role is to find the best balance between our quality standards and the client's operational reality.

Why not use No-Code tools exclusively in 2026?

No-Code is excellent for prototyping, but our clients come to us for tools that must last and integrate into complex ecosystems. Custom-built code (TypeScript) offers a flexibility and intellectual property ownership that No-Code cannot yet match at scale.

Is unifying on TypeScript really an advantage?

Yes, absolutely. It lets our developers become "Full-Stack" by nature. A developer can fix a bug in the mobile app in the morning and optimize a SQL query in the afternoon, because the syntax and the tools (ESLint, Prettier, Jest) are the same.

Is PostgreSQL enough for AI projects?

With the pgvector extension, PostgreSQL has become an excellent vector database. For most of the RAG (Retrieval-Augmented Generation) use cases we implement for our clients, it is more than enough and avoids adding a complex technology layer such as Pinecone.

Need technical expertise for your project?

Choosing the right stack is the first step toward a successful digital product. At Fragments Studio, we put our hands-on experience at the service of your vision.

• Discover our web development offering to build scalable tools.
• If your project needs a high-performing application, explore our custom development expertise.
• Get an initial assessment of your stack with our project estimator.
• Or let's talk directly to audit your current architecture.