We fit the engagement model to the project, not the other way round. A well-defined requirement does not call for the same contractual framework as a product to be built over time, or as a second technical opinion. This page sets out the engagement models we offer, how a project runs, and the technology stack we work on.
A defined scope, with a committed budget and timetable. This model suits a requirement that is settled enough to be specified. We always precede it with a scoping phase, invoiced separately, whose purpose is precisely to settle that scope.
We take on discovery and scoping, specification, trade-off decisions and end-to-end delivery management of the product. This model suits organisations that have a functional vision but no product capability available in-house to translate it into software.
Development and evolution capacity committed over several months, in short cycles prioritised with you. Suited to live products whose scope sharpens as user feedback comes in.
An infrastructure audit, a performance diagnosis, an architecture or code review, support for a technology decision. Short assignments, written deliverable, no obligation to continue.
These models combine: many projects start with scoping, continue on a fixed price for an initial scope, then move to a retained engagement.
A meeting to understand your context, your main constraint and your deadline. We tell you at that point whether we are the right people for the job.
We set the requirement down in writing: users, processes, business rules, technical and regulatory constraints, interfaces with what is already in place. Deliverable: a written scope, a proposed architecture, a breakdown into work packages, and an estimate of effort and timetable.
Application and data architecture, technology decisions with the reasoning behind them, user journeys and wireframes for the screens that set the structure. The decisions that are expensive to reverse are taken at this stage, not mid-build.
In iterations, released regularly to an environment you can use. You watch the product take shape and can change direction before the cost of a change becomes prohibitive. Automated tests and code reviews are part of the work, not an option.
Functional verification with your teams, load testing where the context warrants it, migration of existing data, tooled and reversible deployment. We also prepare the operations documentation.
Defect correction, security updates, monitoring and functional enhancements. The framework is agreed with you before go-live, not improvised afterwards.
This is a frequent request and we have no reservations about it. An application built by a previous supplier, an internal product whose authors have left the organisation, a prototype to turn into software fit for production: the starting point is always an assessment.
We audit the code, the architecture, the dependencies, the existing tests and the deployment pipeline. We give you a written diagnosis: what is sound, what is risky, what has to be rebuilt. We then propose a phased route forward that preserves what works. A complete rewrite is one option among others, and rarely the first one we recommend.
This is the stack we know best and it covers the great majority of the requirements brought to us. It is not a dogma: where a context calls for a different technology, we say so and discuss it with you rather than forcing a choice.
You own it, and you hold the source, the documentation and the deployment pipeline.
We use standard, documented technologies, so that you can take the application on yourself or hand it to someone else.
Scoping, architecture decisions, operating procedures: what matters is written down and stays with you.
If a request looks expensive relative to its benefit, we say so before we price it.
Both, depending on how settled the requirement is. Fixed price suits a specified scope and commits us to a budget and a timetable; time and materials suits a product whose scope is still moving and which is steered in cycles prioritised with you. In both cases we start with a scoping phase, invoiced separately: that is what allows the right framework to be chosen on an informed basis.
We assemble the team around the project. A single point of contact handles scoping, trade-off decisions and delivery management from start to finish, which avoids information being lost between phases. Complementary skills — front-end or back-end development, DevOps, UX — are brought in at the point where they are useful. We favour tight teams: on line-of-business applications they deliver faster and more cleanly than large ones.
A first conversation can usually be held within the week. A scoping or advisory assignment can start within two to three weeks. For development work, the start date depends on current commitments and the size of the project: we give you a realistic date with the proposal, and we would rather quote a timetable we can hold than one that is comfortable to hear.
Yes, and it is a regular part of our work. We begin with an audit of the code, the architecture, the dependencies and the deployment pipeline, then give you a written diagnosis and a phased route forward. We only recommend a complete rewrite where it is genuinely less risky than a gradual modernisation.
You do. Intellectual property in the code developed for your project is assigned to you, and you hold the source, the technical documentation and the means to deploy the application. You do not need us in order to keep running what we have built.
Yes. We offer a maintenance framework covering defect correction, security updates, application monitoring and functional enhancements. Service levels and response times are agreed with you before go-live. If you would rather bring maintenance in-house, we organise the handover to your teams.
Yes. We are based in Montpellier, in southern France, and we work remotely across France and internationally. We have long delivered projects with software vendors and partners in the United States, so cross-border working is established practice rather than an experiment: we run the whole project cycle in English — specifications, reviews, documentation and go-live — and we are used to working across significant time differences. On-site meetings remain possible where they add something to the project.
Our confidentiality commitments prevent us from naming our clients. We therefore describe our work by its technical content: architecture, constraints addressed, choices made and outcomes achieved. The three case studies on the "Our expertise" page give a detailed view. In a meeting we are glad to go into the technical detail of projects comparable to yours, and to answer your questions on architecture and method precisely.
The first conversation commits you to nothing and lets us tell you whether we are the right people for the job.
