There is no price list, and this is why.
We price projects, not seats. What a project costs comes out of what it has to do, and that is different every time. This page sets out what moves the number, the one band we can publish honestly, and where the rest of the answer comes from. It is not a rate card.
A rate card would be a fiction.
Software is not a product on a shelf. Two apps that look identical from the outside can cost very different amounts to build, because one talks to a payment provider, a warehouse system and a legacy database, and the other talks to nothing. A published price for “a mobile app” would be right for one of them and badly wrong for the other.
We also do not sell seats. There is no per-user licence here and no subscription tier, so there is nothing a table of prices would actually describe. What we sell is a scoped piece of work with a start, an end, and an agreed definition of done.
Most agencies solve this by publishing nothing at all and making you book a call to learn anything. We would rather tell you what drives the number, give you the one band we can stand behind, and be plain that the rest comes out of scoping. If that leads you to decide we are not the right fit before you contact us, that is a good outcome for both of us.
What actually moves the number.
These are the things we look at in a scoping conversation, in roughly the order they matter. Most of them are decisions, which means most of them are yours.
- Scope
- How many things the software has to do, and how many of them are genuinely required to launch. Scope is the largest lever on this list, and it is the one you control outright.
- Custom vs standard
- Work that a well-known framework or an off-the-shelf module already does costs far less than work that has to be invented. The expensive parts of a build are the parts that are genuinely specific to your business — and those are usually fewer than the first feature list suggests.
- Platforms
- iOS, Android, web, or all of them. A shared codebase like Flutter or React Native keeps one build from becoming several, but each additional platform still carries its own testing, store submission and support.
- Backend and data
- A front end over an API you already have is a different project from one that needs its own backend: a database, roles and permissions, an admin surface, and somewhere for it all to run.
- Integrations
- Every external system — a payment provider, an ERP, a CRM, a logistics platform, a bank, a device — is a dependency with its own documentation, its own edge cases and its own timetable. Integrations are where estimates move most often, so we name them explicitly in the scope.
- Design ambition
- A clean interface built on a standard component library is not the same work as a bespoke design system with custom motion and illustration. Both are legitimate. They are not the same number.
- Data migration
- Moving data out of an old system is real work, and it is routinely left out of early conversations. Data that was never validated, exists twice, or lives in spreadsheets can cost more to migrate than the features it feeds cost to build.
- How certain you are
- A client who arrives with decisions made gets a tighter number than a client who arrives with a direction. Both are fine to start from. They price differently, and they price differently for an honest reason: unresolved questions get resolved during the build, and that is the expensive place to resolve them.
App and MVP builds: a band, not a quote.
This is the only figure on this page. It covers one kind of work — building an app or an MVP — and it is the range that projects of that kind fall into.
App and MVP builds typically start from 5,000 TND for a simple MVP and can go up to 50,000+ TND for complex enterprise solutions.
Treat that as a band, not a quote. It is not a price attached to your project, and nothing is priced until there is a written scope. A scope can put a build at either end of that band, and it can put one outside it. We publish the band because something you can sanity-check your budget against is more useful than silence — not because it is an offer.
What a mobile app really costs — the detailed breakdownThe work we will not put a number on here.
For the rest of what we do there is no band we can publish honestly, and we are not going to invent one. What follows is what the estimate actually depends on. The number comes out of scoping, in writing, before any work starts.
Websites and web applications
A marketing site and a web application share a word and very little else. The estimate turns on how many distinct page types there are, whether content is edited through a CMS and by whom, how many languages it ships in, whether there are accounts and permissions behind it, and how much of the design is bespoke rather than systematic. A multilingual application with roles is a different project from a brochure site, even when both are called a website.
Odoo ERP
Cost follows how far your processes sit from what Odoo already does. Standard modules configured to how you work is the inexpensive end. Custom modules, migrating data out of the system you are leaving, and integrating with the tools you are keeping is where the work is. One thing worth stating plainly: we are not an Odoo partner and we do not resell licences. Whatever you pay Odoo is separate from whatever you pay us, and you pay them directly.
AI automation
The model is rarely the expensive part. What drives the estimate is the state of your data, how many systems the automation has to reach into, how wrong the output is allowed to be, and what has to happen when it is wrong. An automation nobody checks is cheaper to build and considerably more expensive to own, so the review path is scoped as part of the work rather than added afterwards.
Embedded software
Hardware sets the terms. The estimate depends on the board and the toolchain, whether firmware already exists or starts from nothing, which protocols are involved, what has to be certified, and how the thing gets tested — because embedded work is demonstrated on real hardware, and that hardware has to exist before a schedule can mean anything.
The scope comes first, then the number.
- 01
The conversation
You tell us what the software has to do and what it has to work with. It costs you nothing. If the honest answer is that the project is smaller than you think, or that it needs a different kind of team, that is the answer you get.
- 02
The written scope
Features, the systems we have to integrate with, what is explicitly out, and milestones with dates on them. This document exists before any price does. An estimate with no scope behind it is a guess presented as a number.
- 03
The number
Then, and only then, a price. Two models: a fixed price against a written scope when the requirements are stable enough to fix, or a monthly rate when priorities will keep moving. We tell you which one fits your project and why, rather than defaulting to whichever suits us.
- 04
What can change it
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 reopen the number.
- 05
How change requests work
Small changes are absorbed into the current sprint by re-prioritising, not by quietly moving the deadline. Anything larger comes back to you as a written estimate of cost and schedule impact, and you decide before it is built. Every accepted change is logged against the original scope, so at the end you can read what you asked for and what it added.
How to spend less without shipping less.
Every lever here cuts scope, not quality. Cutting quality is the expensive option, because it comes back as rework and rework is paid for twice.
Ship the smallest thing that proves the idea.
Build the one workflow the business actually depends on and put it in front of real users. Much of the original feature list will be reordered by what you learn, and some of it will be dropped. Paying to build those features first is paying to find that out later.
Phase it.
A launch is not a deadline for every feature you will ever want. Agreeing what is in the first phase and what is deliberately not is the cheapest decision available to you, and it makes the first number both smaller and more accurate.
Use what already exists.
Standard authentication, a proven payment provider, an off-the-shelf admin panel, an existing component library. Custom versions of solved problems are the most common avoidable cost in a build, and they are the hardest to justify afterwards.
Cut platforms before you cut features.
One platform done properly beats two done thinly. If your users are on one of them, start there and add the other when the software has earned it.
Bring decisions, not options.
Every open question that reaches the build gets resolved by somebody, and resolving it twice costs more than deciding it once. Content, branding and the rules of your business are cheaper settled before development than during it.
Do not cut testing, documentation or maintenance.
These look like savings and are not. They are what keeps the software cheap to change, and changing it is most of what you will do with it after launch.
The questions people ask about cost.
- Why can you not just give me a price?
- Because a price with no scope behind it is a guess, and a guess that lands low costs you more than no number at all. Tell us what the software has to do and you get a written scope and a real number against it, at no cost and with no obligation.
- Do you publish a day rate?
- No. We price scoped work, not days. A day rate tells you what a day costs and nothing about what your project costs, and quoting one would invite you to multiply it by a duration nobody has estimated yet.
- Is the 5,000 to 50,000+ TND range a quote?
- No. It is a band that app and MVP builds fall into, published so you can sanity-check it against your budget. Your project is priced from its own written scope, and can land anywhere in that band or outside it.
- 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 project is smaller than you think, or needs a different kind of team, that is what you will be told.
- Can an agreed fixed price change?
- Only if the scope changes, and only with your written go-ahead. New features, new integrations or a third-party system that behaves differently from its documentation are re-estimated before anything is built. Our own underestimation is not a reason to reopen an agreed number.
- Is nearshore cheaper?
- That depends entirely on what a team where you are charges, which is a comparison you can make and we cannot make for you. What we can state is the arrangement: we are in Tunis on UTC+1, so the working day overlaps Western Europe end to end, and we work in English, French and Arabic.
- What is not included in the price of a build?
- Anything you pay a third party for: hosting and cloud, app store accounts, domains, licences for software you are keeping, paid APIs. Those accounts are opened in your name at the start, so you pay the providers directly and can see exactly what they charge rather than finding them inside our invoice.
Get a number that means something.
Tell us what the software has to do. You get a written scope and an estimate against it, with no obligation attached to either.
Start a project