What it costs, and why.
Every project is quoted after we understand it, and the number is written down before any work starts. What follows is how we get to that number, so it is not a black box by the time you see it.
Three ways to work with us.
Which one fits depends on how well the outcome is understood, not on how big the budget is. We will tell you which we think you have.
Fixed-price project
A first release with a shape you can describe
We scope the work, write the plan and name one price before anything starts. You know the number and the date going in, and we carry the risk of our own estimate. It suits a defined outcome: an MVP, an app, a store, a specific set of features.
- A written plan with scope, timeline and price, before work begins
- A working build you can open every week
- Fixed price held unless you change the scope in writing
Staged payments against agreed milestones.
Monthly team
Ongoing product work with no fixed end
A team of the disciplines your product needs, working continuously at a monthly rate. Priorities are set with you each cycle, so what gets built can change without renegotiating a contract. This is how most products are run after their first release.
- A named team, not a rotating pool
- Priorities reset with you every cycle
- Monitoring, fixes and releases handled as part of the arrangement
Monthly in advance, one month notice either way.
Audit and advisory
Existing code you need an honest opinion on
A few days spent inside your codebase or prototype, ending in a plain document: what can stay, what needs rework, what has to be rebuilt, what each part costs and the order to do it in. It stands alone — there is no obligation to have us do the work.
- A written assessment you own and can take to anyone
- Costed, ordered recommendations rather than a list of complaints
- A call to walk through it and answer questions
One fixed fee, paid on delivery of the document.
What actually moves the price.
Six things account for nearly every difference between one quote and another. None of them is a surprise once the brief is clear.
How many disciplines the brief needs
A store is one discipline. A store with an AI assistant, a mobile app and a release pipeline is four. We price only the ones your project actually needs, which is why the first conversation is about the problem rather than the feature list.
New code or someone else’s
Building fresh is usually cheaper than changing an existing system, because the existing system has decisions in it that nobody documented. Work inside an unfamiliar codebase carries an unavoidable cost of finding out how it behaves.
How certain the scope is
A well-understood outcome suits a fixed price. An idea still being discovered does not — a fixed price on an uncertain scope just moves the risk into padding, and you pay for it. We will say which one we think you have.
What it has to connect to
Payment gateways, couriers, accounting systems, an ERP, a legacy database. Each integration is an unknown until we have seen its documentation, and integrations are the most common reason an estimate moves.
Platforms and offline behaviour
Web only is the floor. Adding iOS and Android is more. An app that has to keep working without a connection is more again, because that is a decision about the data layer rather than a feature bolted on later.
What happens if it is wrong
Software handling money, health or legal detail needs more testing, more review and more care than an internal tool where a mistake is an inconvenience. We price the level of assurance the work actually warrants.
In every engagement, whichever model
- The code, in your repository, from the first commit
- Infrastructure in your own cloud accounts, in your name
- A written plan naming the price before any work starts
- A working build you can open and click through every week
- Automated tests on the paths that would cost you if they broke
- A release pipeline, so shipping is one reviewed action
- Handover documentation written for whoever comes next
Questions about money.
The ones worth asking before you commit to anyone, including us.
How do you decide between a fixed price and a monthly team?
By how well the outcome is understood. If you can describe what finished looks like, a fixed price is fairer to you — we carry the estimate risk. If the product is still being discovered, a fixed price would just be padded to cover the unknown, and a monthly team costs you less for the same work. We tell you which one we think fits after the first conversation.
What happens if the scope changes mid-project?
On a fixed price, a change is quoted as a change: what it adds in time and cost, in writing, before it is built. Nothing gets absorbed quietly and nothing gets invoiced as a surprise. On a monthly team, changing direction costs nothing extra — it is what the arrangement is for.
Do you ask for payment up front?
Fixed-price work is billed in stages against milestones, with the first stage before work begins. A monthly team is billed monthly in advance. An audit is billed once, on delivery of the document.
Is there a minimum engagement?
An audit is the smallest thing we do and stands entirely on its own. For build work the practical minimum is the first release of something real — below that you are paying setup costs for an outcome too small to learn from.
Who owns the code, and what if we stop working together?
You own it from the first commit. The repository is in your account and every deployment runs on infrastructure in your name, so ending the arrangement is a matter of us losing access, not of anything being handed over. That is deliberate: it keeps us earning the next month rather than relying on lock-in.
Do you charge for the first conversation?
No. The first call, and the written plan that follows it, cost nothing. We would rather spend that time finding out whether we are the right people than have you pay to discover we are not.
What does it cost to keep it running after launch?
Maintenance is a monthly arrangement sized to the product: monitoring, fixes, dependency and OS updates, and the next round of features. It is quoted separately from the build, and it is optional — you own everything needed to have someone else do it.
Why is a team in Bangladesh cheaper than one in the US or EU?
Cost of living, not corner-cutting. Our engineers are paid well for Rajshahi and the rate still lands below what the same seniority costs in Western Europe or North America. What you should check is the work: look at the case studies, ask to speak to a client, and judge it on that rather than on the rate.