# Designing an application around a clear API from the outset

> Designing an application around a clear API from the outset, with a typed database and a frontend that simply consumes it, is the approach I take for custom business application development.

- Source canonique : [https://allaux.fr/en/expertises/architecture-fullstack-api-first](https://allaux.fr/en/expertises/architecture-fullstack-api-first)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## The typical need

Beyond standard CMS-based stores, some needs call for a business application built from the ground up: a client portal with its own logic, an internal tool, or an extension of an existing store that goes beyond what a CMS module can reasonably carry. This kind of project benefits from an architecture designed around an API from the start, rather than a frontend and backend developed in an intertwined way that becomes hard to evolve later.

## How I approach this kind of work

The API-first approach means precisely defining the exchange contract between frontend and backend before building either in detail: what resources exist, what operations are possible, what data format is exchanged. This contract becomes the shared reference, which makes it possible to evolve the visual interface without touching the backend, or evolve the business logic without breaking the frontend, as long as the contract is respected.

On the technical stack side, I choose tools based on the project rather than habit: a Node.js backend with NestJS for a clear modular architecture, a database with a typed ORM such as Prisma or Drizzle to cut down on type mismatches between code and database, a React or Next.js frontend when a rich, responsive experience is needed. End-to-end typing, from the database schema through to the frontend, largely eliminates a whole category of bugs that would otherwise only surface in production.

## Factors that affect the estimate

- **Complexity of the data model** — A business model with many relationships and consistency rules requires more design work than an application with simple entities.
- **Number of users and profiles** — Fine-grained permissions across several user profiles add a layer of complexity compared with uniform access.
- **External integrations required** — A self-contained application is quicker to build than one that needs to exchange data with several third-party systems from the outset.
- **Performance and load requirements** — Limited internal use imposes different constraints from an application aimed at a large number of external users.

## Questions to ask before starting

> Can the API contract be clearly defined before development begins, or is it still unclear at this stage? How many different user profiles does the application need to handle? Which external integrations are known today, and which might be added later?

## FAQ

### Why not use a CMS instead of a custom architecture?

A CMS remains a good fit as long as the need matches what it does well. Once the business logic becomes specific and central to the project, a custom architecture avoids constantly working around the limits of a tool designed for another purpose.

### Is the choice of technical stack fixed?

No, it's made according to the project's real constraints: an existing team who will take over the code, performance requirements, an ecosystem already in place. A stack specified by the client is followed if it's consistent with the need.

### Is this architecture suited to a small application?

The benefit is clearest once the application is expected to evolve over time or take on new integrations; for a very narrow, fixed need, a lighter approach may be enough.