Delivery model
How an assignment is governed, week after week
The risk of remote delivery is not technical but informational: you lose the visibility you would have over an internal team. Here is precisely what you receive, and how often, so that does not happen.
The cadence
None of this is optional or invoiced as an extra. It is the standard operation of every assignment lasting over a month.
Every day
Short team stand-up
Our teams join your daily ritual if you have one, in your tool and at your time. Otherwise an internal stand-up whose notes are accessible to you.
Every week
Written progress report
One page: what shipped, what is in progress, what is blocked and by whom, and days consumed against plan. Sent on Friday, readable in three minutes.
Every fortnight
Demo on a real environment
You watch the software run rather than read a description of what it should do. A feature that cannot be demonstrated does not count as delivered.
Every month
Steering committee
Budget consumed, open risks, decisions needed on your side, technical debt created or repaid. One hour, with the pack sent 48 hours in advance.
Every quarter
Access and architecture review
Named list of who has access to what on your side, revoking anything no longer needed. Plus a review of architecture choices against what has been learned since.
Quality gates
A delivery that fails these gates does not ship. They are verifiable by you, not declarative.
- Every change goes through code review by someone other than its author
- The continuous integration chain must be green: tests, static analysis, formatting
- The test coverage agreed at framing is verified automatically, not asserted
- Every structural architecture decision is recorded in a dated, versioned document
- No secrets or credentials in plain text in the repository, checked automatically on every push
- Every feature is demonstrated on a staging environment before it counts as done
Your tools, not ours
We work inside your environment. That avoids double entry, keeps traceability on your side, and means that at the end of the assignment there is nothing left to retrieve from us.
- Your repository, your branches, your commit conventions and your review rules
- Your tracking tool: Jira, Azure DevOps, Linear, GitLab or another
- Your team messaging, with a dedicated channel where your teams reach us directly
- Your continuous integration chain and your environments
- Your identity provider and bastion for all access
What protects continuity
Two people per file
On every assignment over three months, two people know your context, your code and your contacts. A holiday, an illness or a departure must never stop your project.
A single French-speaking contact
One person accountable for the assignment, directly reachable, who is not a salesperson. You never go through an account manager to ask a technical question.
Documentation written as we go
No end-of-project documentation phase, which never happens. What is learned is written within the week, in your repository, and forms part of the delivery criteria.
Contractual reversibility
Notice period, exit pack contents and assistance duration are written into the master agreement at signature. Exit is not negotiated at the moment you want to leave.
Twenty minutes is enough to know whether we are useful
No sales deck. You describe the need, we say whether it is in scope, at what price and on what timeline. If it is not for us, we say so during the call.