The answers you want before you sign anything.
Choosing a software team is a risk decision before it is a technical one. This page sets out how a project is scoped, how it is priced, what you see while it is being built, who owns the result, and what happens after launch. All of it is written down before development starts.
A project runs the same way every time.
- 01
Scoping
We start with a conversation about what the software has to do and what it has to work with. It costs you nothing, and it ends in a written scope: the features, the systems we have to integrate with, what is explicitly out, and milestones with dates on them. Correcting that document is cheaper than correcting the code.
- 02
Estimate
The estimate follows the scope, never the other way round. Two models: a fixed price against a written scope when the requirements are clear enough to fix, or a monthly rate when priorities will keep moving. We tell you which one fits your project and why.
- 03
Build
Work runs in sprints, inside your tools — your Slack or Teams, your issue tracker, your repository. At the end of every sprint you get a demo of running software rather than a status report, and on real hardware when the work is embedded. You talk to the people writing the code.
- 04
Changes
Requirements move; that is normal. Small changes are absorbed into the current sprint by re-prioritising, not by quietly extending the deadline. Anything larger gets a written estimate of cost and schedule impact, and you decide before it is built. Every accepted change is logged against the original scope.
- 05
Handover
Handover is documentation, the deployment pipeline and a walkthrough with the people who will maintain the system — not an archive dropped in your inbox. The repository has been yours since the first commit, so there is nothing to transfer at the end: hosting, cloud and store accounts are already in your name.
- 06
After launch
Defects against the agreed scope are ours to fix, not a new invoice. After that you can keep us on for maintenance and new features, or take the documentation and the running deployment and continue with your own team. Both are normal outcomes.
What goes in writing, every time.
You own the code.
IP in everything we produce transfers to you. We work from day one in a repository you control, there is no proprietary framework to license, and there is no lock-in on hosting or maintenance.
The scope exists before the work does.
Features, integrations, exclusions and dated milestones are written down and agreed before development starts. An estimate with no scope behind it is a guess presented as a number.
You talk to the people writing the code.
There is no account manager between you and the engineers. A question is answered by whoever is going to implement the answer.
A demo, not a status report.
Every sprint ends with software you can use, on real hardware where the project is embedded. Progress you cannot click on is not progress.
An honest schedule beats a comfortable one.
If a date is not achievable we say so before the contract, not in month three. Scope decides the schedule, so we size the work before quoting instead of after.
A working day that overlaps with yours.
We are in Tunis, on UTC+1. For a team in Paris, Berlin or Madrid that is the same working day, one hour apart at most during European summer time — a question asked in the morning is answered in the morning.
- Time zone
- UTC+1 in Tunis. The working day overlaps with Western Europe end to end, one hour apart at most during European summer time.
- Languages
- English, French and Arabic. Calls, written documents and code review happen in whichever of the three suits your team.
- Tools
- Yours. We work in your Slack or Teams, your issue tracker and your repository, so the history of the project stays where you can read it.
- Rhythm
- A demo of running software at the end of every sprint, plus whatever day-to-day contact your team prefers.
We also build and run our own software. Dextra, a fitness coaching web app, is live in Arabic, French and English, with real users and certified coaches.
See how Dextra was builtQuestions worth asking before you sign.
- What does the first conversation cost?
- Nothing. We go through what the software has to do, tell you what we think it involves, and put the result in writing. If the honest answer is that the project is smaller than you think, or needs a different kind of team, that is the answer you get.
- What can change an agreed estimate?
- A change to the scope, and only with your written go-ahead. New features, new integrations, or a third-party system that turns out to behave differently from its documentation are re-estimated in cost and schedule before anything is built. On a fixed price, our own optimism is not a reason to re-open the number.
- What do I actually see while the build is running?
- The repository, from the first commit. The issue tracker, because it is yours. And a demo of running software at the end of every sprint — on real hardware when the work is embedded.
- Who owns the code, the IP and the accounts?
- You do. IP in everything we produce transfers to you, the repository is yours from the first commit, and hosting, cloud and app store accounts are opened in your name at the start rather than transferred at the end.
- What is included in handover?
- Documentation of how the system is built and deployed, the build and deployment pipeline itself, and a walkthrough with the team that will maintain it. Nothing in the delivery depends on a tool only we can run.
- What happens if we stop working together?
- You keep everything: repository, accounts, deployment, documentation. There is no proprietary framework to license and no hosting you cannot move. Ending the engagement is an email, not an extraction project.
Start with the scoping conversation.
Tell us what the software has to do. You get a written scope and an estimate, with no obligation attached to either.
Start a project