01The three models side by side
None of these is better in general. Each one moves risk between you and the team, and each fits a different kind of project.
Fixed scope
- Works best when
- You can list the features and they will not change much
- The main risk
- Changes outside the list are quoted separately, so a vague brief causes friction
Time and materials
- Works best when
- The work is exploratory or will change as you learn
- The main risk
- The total is not known up front, so it needs regular reviews of progress and spend
Dedicated team
- Works best when
- A long-running product needs steady output every month
- The main risk
- You pay a monthly fee, so you need enough work to keep the team busy
02When fixed scope is the right call
Fixed scope rewards a clear brief. If you can write down the screens, the user roles, the integrations and what done means, a fixed quote gives you a number to plan around.
- The project is a defined first release, such as a first working version of a product.
- You have a budget ceiling and need to know the price before you commit.
- The requirements come from a document, a tender or a fixed process, so they are unlikely to move.
The catch is change. Anything outside the agreed list is quoted separately, so agree what counts as a change before work starts.
03When time and materials fits better
If you are still learning what users want, a fixed list will be wrong by the second month. Paying for hours worked lets you change direction without renegotiating.
- You are testing an idea and expect to change features as feedback comes in.
- The work is investigation, such as untangling a legacy system or fixing performance.
- Priorities shift often, so a fixed list would be out of date quickly.
To keep control, ask for regular demos, a running view of hours used and a way to pause or re-plan at any point.
04When a dedicated team makes sense
A dedicated team means engineers who work with you full time for a monthly fee. It suits a product with a steady stream of work, where you want the same people to learn your system and stay with it.
It is the wrong fit for a one-off project with a clear end, where fixed scope is simpler.
05A common path: start fixed, then move
Many projects mix models. A fixed-scope first release gets something working and gives you a known price for the first step. After that, hourly or monthly work covers the changes you learn from real use.
- Phase one: fixed scope for a first release.
- Phase two: time and materials for changes based on real feedback.
- Later: a dedicated team once the product needs steady monthly output.
06Questions to ask any team before you choose
- What exactly is included in the price, and what counts as a change?
- How is work split into milestones, and when will I see something working?
- Who owns the code and the accounts when the project ends?
- For hourly work: how will I see the hours used, and how often?
- Can I switch model after the first phase?
07How we work with MOUNTSMY
We start with a free 30-minute call with an engineer. Afterwards you get a written plan and quote with the scope, timeline and price, before any work starts. You can choose fixed scope, hourly or a dedicated team, and you own the code.
If you are not sure which fits, we can start with a small, fixed-scope project and grow from there.
?Frequently asked questions
Is fixed price always cheaper?
Not always. A fixed price gives you certainty, not a lower total. If the scope changes, the changes are quoted separately, and a vague brief can end up costing more than hourly work.
Can I change the model partway through?
Yes. A common path is a fixed-scope first release followed by hourly or monthly work. Agree this before you start so the handover between phases is smooth.
What if I do not know my full scope yet?
Start with a small, fixed-scope first version or an hourly discovery phase. You learn what the full scope is without committing to the whole project.
Who owns the code?
With MOUNTSMY you own the code, whichever model you choose.