Language · in regular use
TypeScript agency in Nice
JavaScript with a type system: a large share of errors surface while writing rather than in production.
What we do with it
TypeScript at our clients, concretely
Used by default on all our recent front-end and Node work — monitoring tool, configurator, client portal. This very site is written in it.
The limits
When we recommend something else
On a throwaway script of a few lines, typing does not pay for itself.
Our work
Projects we delivered with TypeScript
Paradigm
Platform for a Nice business centre: registered address, digitised mail, messaging and assistant.
TypeScript: Typing across the whole interface, chatbot included.
Read the Paradigm case studySilversun — prospection
B2B prospecting tool for renewable energy: geocoded projects and enriched prospects.
TypeScript: Interface typing.
LLM Monitor
SaaS that measures how visible brands are in AI answers.
TypeScript: Typing of both applications.
Read the LLM Monitor case studyOrdelya
Restaurant management platform: back office, tablets, kiosks, screens and website.
TypeScript: Typing across every interface.
Mejid & Co
Installable web app for tracking disbursements for Mejid & Co's clients.
TypeScript: Typing of the application and its forms.
Read the Mejid & Co case studyJeu-concours Snake
Six-level retro contest game, with quiz and sign-up, for a laptop marketing campaign.
TypeScript: Typing of the game and interface.
Read the Jeu-concours Snake case studyAngeles Immobilier
Multilingual website for a Côte d'Azur estate agency: listings, search and blog.
TypeScript: Typing of the website and its API routes.
Read the Angeles Immobilier case study
Method
How we bring TypeScript into a project
On a new project, TypeScript is set to strict mode from the first commit: values that may be empty must be handled explicitly, and the compiler rejects implicit types. We first define the business objects (a customer, an order, a consumption reading) in a dedicated folder that both the interface and the Node server import. When the back end publishes an OpenAPI description, types are generated from it rather than copied by hand.
Types check nothing at runtime. At the application's boundaries, forms, external API responses, imported files, we therefore validate data with Zod, whose schemas also produce the TypeScript types: each rule is written only once. On an existing JavaScript codebase, we enable the option that lets both languages coexist and convert file by file.
Continuous integration runs tsc without emitting files, ESLint with type-aware rules and the test suite; a type error blocks the merge just as a failing test does. The documentation we hand over sets out the chosen configuration, where the shared types live and the command that regenerates them.
For your business
What it changes in practice
Your users never see TypeScript, but they notice its effect: fewer screens showing "undefined", fewer buttons that stop working after an update, fewer badly formatted amounts. Some of the faults a customer would otherwise stumble on are caught before anything goes live.
For the business, the change lies in how safe it is to modify the software. Renaming a field, adding an order status or altering a calculation rule becomes a change whose every consequence the compiler lists, rather than a gamble on what might break. Updates therefore ship with fewer urgent fixes following them. When a new developer, in-house or at another supplier, opens the project, the types describe the data structure without a separate document to keep up to date. For a small business without a dedicated testing team, that automatic safety net, which runs on every change without anyone having to remember it, matters more than it does for a large organisation.
Our reading of it
What we take away from TypeScript
TypeScript is not added at the end of a project, it sets the vocabulary at the start. Its value lies less in the types themselves than in what they prevent: a field renamed on the server breaks the build before release, instead of showing an empty box to your customer three weeks later.
The benefit multiplies when one language holds both ends of the chain. Our React interfaces and our Node.js APIs share the same business-object definitions, written once and imported on both sides. Angular enforces it natively, which explains part of its reputation for rigour. The trade-off is real: a compilation step to configure, dependencies to type, and a learning curve for a team used to plain JavaScript.
Decision guide
Should you choose TypeScript?
TypeScript or plain JavaScript for an application several people will maintain?
TypeScript, without question. Once code has more than one author or lives longer than a few weeks, types act as documentation that is actually checked: the editor flags that a function expects a date but receives text, before any test runs. A change in one file immediately shows what it breaks elsewhere. Plain JavaScript only makes sense for a throwaway script of a few lines, where declaring types does not pay off.
TypeScript on the server with Node.js, or another language such as PHP or Python?
If the interface is already in TypeScript, writing the server in the same language lets both sides share data definitions: the shape of an order or a customer is described once, and front end and back end are both checked against it. That is how we build our recent Node work. PHP remains relevant if your existing systems or hosting require it; Python, if the project centres on AI.
Should we convert an existing JavaScript codebase to TypeScript?
Yes, but gradually. TypeScript happily coexists with JavaScript files: convert the most frequently changed or most sensitive modules first, such as pricing calculations or access rights, then the rest as features evolve. A one-off conversion of everything ties the team up without shipping anything. We advise against a full rewrite when the current code works and your users rely on it every day.
Client questions
What clients ask us about TypeScript
Does TypeScript make development slower and therefore more expensive?
Writing the code first time round takes a little more discipline, since the shape of the data has to be described. That time is recovered later: fewer bugs found by your users, safer changes and faster onboarding for a new developer. For an application meant to last, we see it as a saving rather than an extra cost.
Does TypeScript protect our application against security flaws?
Not directly. Types are checked while the code is written, then stripped out: the browser and the server run ordinary JavaScript. Data sent by a malicious user must therefore still be validated at runtime. What TypeScript does reduce are the logic errors that often open gaps, such as a forgotten field or an unexpected empty value.
Will we easily find developers able to maintain TypeScript?
Yes. Any JavaScript developer can read TypeScript, and most current front-end and Node projects already use it. Types even make it easier for a newcomer to get started, because the structure of the data is visible without having to ask the original author. This site is itself written in TypeScript, like all our recent front-end and Node work.
Is TypeScript worthwhile if our back end is in PHP or Python?
Yes, on the interface side. The server does not share the language, but it can publish a description of its API in OpenAPI format, which Symfony, Laravel and FastAPI can all produce. We generate TypeScript types from it: if the back end changes a field, regenerating them immediately shows which screens are affected. Without that step, a mismatch between server and interface only surfaces in production.
Do our existing JavaScript libraries work with TypeScript?
Yes. TypeScript compiles to JavaScript and can use any JavaScript library. Most widely used libraries already ship their own type files, or have them available through a community package. For an older in-house tool without any, we write a declaration covering only the functions actually called, which is enough to restore type checking wherever the code relies on it.
Going further
TypeScript sits within our Software development
A technology does not make a project. The method around it decides the outcome: scoping, prototypes, short cycles, and a clean way out.
Neighbouring technologies
A TypeScript project in mind?
The first conversation is free. We will tell you plainly whether this technology is the right one, and if not, which is.
Updated on