Our approach
A method that gives the field as much weight as the code
Five stages, from the first interview to the moment your teams no longer need us.
How an assignment runs
Five stages, from the first interview to your independence
- 01
Framing
Understanding the organisation before the tool: interviews with case officers and users, review of what already exists, regulatory and material constraints.
- 02
Design
User journeys, wireframes and technical architecture. The structural choices are made and approved before the first line of code is written.
- 03
Iterative build
Versions delivered regularly and tested by end users. Every increment is functional, documented and covered by automated tests.
- 04
Go-live
Deployment on infrastructure you control, on-premises or in a sovereign cloud. The application is installed, configured and opened to users.
- 05
Handover and support
Team training, delivery of the complete source code and documentation, support during adoption. The objective is your independence.
Commitments
What we commit to contractually
These points appear in our proposals. They are not intentions: they are deliverables and clauses.
Application delivered in service
We do not hand over a code archive for you to make work: the application is installed, configured, put into production and taken over by your teams.
Source code returned in full
Alongside the working application, the entire code base, data schemas and documentation are handed over. You own what you pay for.
Controlled hosting
Deployment on infrastructure you control, in Senegal or in a sovereign cloud, according to your requirements.
Accessibility
Interfaces usable on low bandwidth, on modest equipment and by people with disabilities.
Security and data
Encryption, fine-grained access rights, logging and compliance with personal data protection frameworks.
Interoperability
Open formats and documented interfaces, so your systems can talk to each other and evolve.
Skills transfer
Training of internal teams built into the project, so the solution outlives the assignment.
Support after go-live
Defect correction, operational assistance and scoped evolutions: the end of development is not the end of the relationship.
Terms
How we contract
Four frameworks, most often combined in this order. None is imposed: the framing stage exists precisely to choose what comes next.
- 01
Framing
- Basis
- Fixed price
- Duration
- Two to four weeks
Interviews with the people who do the work, observation of the real circuit, inventory of what exists. This stage is invoiced because it produces something: it does not have to be redone if you award the rest to someone else.
What you hold at the end: A framing document, a costed proposal and a schedule — usable as they stand in a funding application.
- 02
Fixed-price project
- Basis
- Fixed price, paid against milestones
- Duration
- Three to nine months depending on scope
The usual framework once the need is settled. Price and scope are fixed at signature; each milestone is delivered in service and verified with you before it is invoiced.
What you hold at the end: The application in production, your teams trained, the documentation and the source code.
- 03
Dedicated team
- Basis
- Day rate, committed by quarter
- Duration
- From three months
For when the need moves faster than a specification — a product still taking shape, a management team arbitrating as it goes. You set the priorities, we supply the engineering capacity.
What you hold at the end: A delivered, documented increment at the end of every cycle, and the right to stop at the quarter.
- 04
Maintenance and evolutions
- Basis
- Annual envelope, revisable
- Duration
- Twelve months, renewable
Defect correction, operational assistance, small evolutions. Sized on how critical the solution actually is, not on an automatic percentage of the project cost.
What you hold at the end: A committed response time, a periodic review and a log of interventions.
What makes a costed proposal possible
We do not price an intention. Four elements are enough, and they often fit on one page.
- The problem as your teams experience it, not as a solution frames it.
- What already exists: tools in place, data available, what has been tried.
- How many people will use the tool, and under what connection conditions.
- The deadline that constrains you — a council session, a budget cycle, a regulatory obligation.
What does not change between frameworks
- Source code, data schemas and documentation are handed over in full.
- Hosting is deployed on infrastructure you control.
- No proprietary licence dependency that would stop you changing supplier.
- What does not fall to us is said before signature, not during the project.
The amount depends on scope: the framing stage establishes it, and it is firm.
Principles
Five reference points that settle our trade-offs
When a design decision is genuinely difficult, these are what decide it.
Jàppandal
To facilitate, to make accessible, to serve. The company's name is also its working method.
Innovation
Looking for the right solution rather than the fashionable one, and testing it in the field.
Excellence
International engineering standards: code quality, tests, documentation, security.
Inclusion
Interfaces usable by everyone, including on low bandwidth and with a disability.
Impact
Measuring what actually changes for users and staff, not only what was delivered.
Want to test this method against your project?
A first hour is usually enough to know whether the project is ripe, what needs clarifying, and where to start.