The three engagement shapes
Discovery sprint
A fixed engagement of about two weeks that turns an idea into a plan. It suits you if the idea is new, the scope is unclear, or you need something concrete to show colleagues or investors. It covers research, a clickable prototype, a technical approach, a threat model of the core flows and a written roadmap.
Fixed-scope product build
A defined product, designed, built and launched for an agreed scope. It suits you if you know what you need, because a discovery sprint answered the open questions or the requirements are already clear. It covers design, development, automated tests, a release pipeline, a security review before launch with a prioritised fix list, weekly demos, and post-launch care agreed in writing.
Dedicated team, monthly
A product pod that works as part of your organisation, billed monthly. It suits you if the product keeps evolving, your roadmap is longer than any single scope, or you need design, engineering and security skills without hiring for each. The skills are matched to your stack, and the team can scale up or down by agreement.
The three shapes side by side
| Aspect | Discovery sprint | Product build | Dedicated team |
|---|---|---|---|
| Best for | A new or unclear idea | A product with a known scope | A product that keeps evolving |
| Length | About two weeks | Set by the scope | Ongoing, reviewed regularly |
| How cost behaves | Fixed | Fixed for the agreed scope | Monthly, by team size and mix |
| Security | Threat model of the core flows | Threat review first, security review before launch | Continuous reviews, dependency and cloud checks |
| Main risk | Low: short and bounded | The scope list may be wrong | Spending without clear priorities |
What drives the cost of software work
Cost follows how much there is to build and how much can go wrong. The main drivers:
- Scope: user types, screens, features and rules. Every extra flow needs design, building and testing.
- Platforms: web only, or also iOS and Android, native or cross-platform. Each adds build and test effort.
- Integrations: payments, identity, messaging and existing systems bring unknowns and limits of their own.
- Security level: a brochure site and a payments app need different depth of review and testing.
- Languages: English and Arabic are designed together from the start, but each further language and a large volume of translated content add work.
- Content volume: writing or migrating hundreds of pages is a project in itself.
- Deadlines: a fixed date may need more people in parallel, or a smaller first release.
- Team size and mix: a dedicated team's monthly cost follows how many people and which skills.
Our articles on web platform cost drivers and mobile app cost go deeper.
How an estimate is produced
- We list the user types, flows and integrations from your brief and any discovery work.
- We break them into pieces of design, build, security and testing work, and estimate each, with a range where the uncertainty is real.
- We write down the assumptions the estimate rests on.
- We mark the unknowns and say how we would resolve them, for example with a prototype.
- We walk you through it in plain language and adjust it with you.
The assumptions appear in the estimate itself. Typical ones: content arrives by an agreed date, a third-party service does what its documentation says, and feedback comes within the week. If an assumption turns out wrong, we tell you what it changes.
Fixed scope or flexible team: where the risk sits
Neither shape is better in general. They put the risk in different places.
Fixed scope gives you a known cost for a known list. The risk is that the list is wrong: you learn something from users and want something else. Changes are possible, through the process below.
A dedicated team lets you change direction every week. The risk is drift: without a clear priority list and a decision maker, monthly spending continues without a finished product. A roadmap, weekly demos and a named delivery lead reduce that risk.
A rule of thumb: if you can write down what you need and what done looks like, fixed scope fits. If you expect to learn as you go, start with a discovery sprint, then choose.
How change requests work
A change request is any change to what was agreed. We neither absorb changes silently nor refuse them. We describe what the change touches, re-estimate, and you decide: add it, swap it for planned work, or postpone it. How a change is priced and approved is written in your project agreement. How we work shows where this fits.
What is not included unless agreed
- Fees charged by third parties, such as cloud hosting, app store accounts, licences, domain names and payment providers.
- Writing, translation or migration of large volumes of content.
- Support and maintenance beyond the post-launch period agreed in writing.
- Independent penetration testing or compliance audits, scoped as separate work.
- Features, platforms or languages outside the agreed scope.
Questions to ask any vendor about a quote
- What exactly is in scope, and what is explicitly out?
- What assumptions does the estimate rest on, and what happens if one is wrong?
- Is the figure fixed or a range, and if a range, what would narrow it?
- Who is on the team, and how often will I see working software, not only status reports?
- How is security handled, and is it priced in or an add-on?
- How are changes priced and approved, and what support follows launch?
- Who owns the code and the accounts when the work is done?