Frequently asked questions

We commit to what the release has to make possible, not to a list of features to tick off. The objective is defined explicitly up front: what the release must let you test, sell or operate.

From there we commit to delivering a version capable of doing that, within the agreed time and budget. The estimation risk sits with Vezero, not with you.

The counterpart is that we take part in product decisions. Proposing trade-offs and driving their execution means owning their consequences. The two are inseparable.

Fixed price, per release. The budget is set at the start, once the objective of the release is defined.

That follows directly from the commitment to outcomes: committing to a result while billing by the hour would be contradictory, since it would make the client pay for our own estimation errors.

The amount depends on what the release has to make possible. That is the first thing we frame together, before discussing budget.

It is expected, and normal. If planned features no longer contribute to the objective, they are simplified, postponed or replaced. If something unanticipated turns out to be essential to the intended outcome, it goes in.

This only works because the commitment is to the result rather than to a list. A project framed by a frozen scope turns every change into a negotiation; a project framed by an objective does not.

Four people: a frontend and mobile architect, a backend and infrastructure architect, a UX/UI expert, and a project lead who is also a data and AI architect. Twelve years of experience on average.

They are the same people from the first conversation to launch. The ones discussing vision and trade-offs are the ones designing the interfaces, writing the code and living with the technical choices.

Four is a methodological choice, not a size constraint: enough diversity of skills to challenge perspectives, enough proximity to keep a shared understanding of the product, and clear accountability without depending on a single individual.

No. No delegation, no outsourcing, no intermediary layer.

A strategic intention becomes a concrete decision without losing information along the way. A trade-off between how polished an interface should be and the time available gets settled in one conversation between the UX expert and the frontend expert, not in two meetings and a write-up.

You do. Intellectual property in the work is transferred to you on delivery, without reservation and without dependence on any tool or account we would control.

That includes the business and technical documentation, maintained throughout the project so that continuity does not rest on our presence.

The arrangements are discussed case by case, depending on what you want to do next: take the product in house, continue with us on a following release, or simply be able to call us when a question comes up.

In every case the product is handed over in a state another team can pick up. The fourth pillar of our method covers this: quality determines how fast the product can still change direction, with us or without us.

Four broad families: building an MVP, upgrading an existing product to a new version, a prototype meant to validate a hypothesis, and auditing a product already in place.

Our clients range from pre-seed to unicorn. What stays constant is the moment: when a release has to meet the market, and the decisions taken start producing lasting consequences.

Yes, and not since language models arrived. We were trained in Machine Learning inside a French unicorn and have worked on these problems for several years.

Fourteen projects running AI models are in production today. We also built Naaro, our own conversational experience.

Our position is simple: AI goes where it delivers real benefit, and how much autonomy it gets is a product trade-off, not a technical feat.

Entirely dependent on what the release has to make possible. We frame that before discussing timelines.

One thing is constant: the deadline is part of the commitment. It is set alongside the budget and the objective, at the start, and we carry the risk on it.