Machine en verre et métal noir transformant une multitude de documents dispersés en un flux opérationnel unique.

Product & software

Custom software and business applications

Most companies do not suffer from a lack of software. They suffer from software that does not talk, and from spreadsheets that hold the rest together.

Start a project See the work

Expertise: Product & software
Nature: Internal app, back-office, business tool
Scope: Scoping · product · interfaces · architecture
Stack: TypeScript · PostgreSQL · documented API
Ownership: Code, data, and documentation delivered

01 / 06

Why the spreadsheet always comes back

Workarounds are not mess: they describe exactly what the official tool cannot do.

A package imposes its model. When your craft diverges — and it always does somewhere — teams invent workarounds: a parallel spreadsheet, a hijacked column, a shared folder, a naming convention only one person knows.

Those workarounds are the best specification that exists. They describe exactly what the official tool cannot do, and what the craft actually does. We always start by listing them.

The goal is not to replace everything. It is to build the missing web tool, connected to the ones that already work, and to remove the double entry that costs most — in time and in errors.

02 / 06

From observation to production

01
Understand
We watch people work. Real flows, roles, edge cases, regulatory constraints, the moments it jams. Serious scoping is worth months of misdirected development.
02
Prototype
Manipulable mockups on the screens that carry the value, before the code. An interface is judged by using it, not by describing it — and a rejected prototype costs days, not a season.
03
Build
An explicit architecture: a defensible data model, business rules in the right place, a documented API, tests on what is expensive to break — then observable deployment. The aim is that another developer can take over the project.
04
Ship and follow
Progressive production, training, observation of use. The first weeks always reveal things nobody had said: that is when you correct them.

03 / 06

How we work

Scope is written and negotiable; what is deferred is said, not forgotten.
You see something real running on a regular cadence, not a progress report.
Data is modelled to last: that is what costs most to fix later.
Documentation is part of delivery, not an option.
You stay owner of the code and the database, and free to change vendor.

Proof in context

See the work behind this expertise

Product, architecture, and operations choices, explained on real studio projects.

Case studyStellaryThe command post for teams that ship with AI agents. You describe a project, the agents move it forward under explicit rules, and a human keeps hold of what matters. Open beta.Product, design and development

05 / 06

What we get asked most

The answers we give anyway at the first conversation.

How do you know custom work is justified?

A few signals: your teams keep spreadsheets to compensate for the official tool, you pay licences for features you do not use, or a central rule of your craft cannot be expressed in the package. If none apply, stay on what you have.

Can you take our current data?

Yes, and it is a stage of its own: extraction, cleaning, model mapping, verified import. A sloppy migration fails a project that succeeded technically.

What if we change vendor?

Nothing blocking, provided it is planned from the start: versioned and delivered code, a standard database, a documented API, a written deployment procedure. That is our default way of working.

Do you work with our in-house developers?

Yes, often: as reinforcement on part of the product, taking over an existing system, or scoping and architecture with internal execution. The mode is decided from your resources.