Most software engagements fail the brief before anyone writes code, because the commercial model does not match how the work will actually change. A dedicated team and a fixed-price project are both valid. They answer different questions.
Choose a dedicated team when the roadmap will move
A dedicated team is the right shape when you already have a product direction and you expect the next quarter to revise it. Engineers join your standups, work in your repository, and stay long enough to learn the domain. You pay for capacity, not for a frozen specification.
This fits funded product teams, internal platforms that grow by usage, and any build where the first release is a hypothesis. You keep the architecture decisions. The partner supplies senior people, replacement cover, and a delivery lead if you want one.
Choose a fixed-price project when the scope is settled
A fixed-price project is the right shape when acceptance criteria, timeline, and exclusions can be written down before the kickoff. The estimate is a commitment against that document. Change is handled explicitly, not absorbed into “we’ll figure it out in sprint planning.”
This fits a defined integration, a migration with a cutover date, or a release whose success is a checklist rather than a learning loop. Predictability is the product you are buying.
A practical test
Write the outcome in one sentence, then ask whether you would still want that sentence unchanged in eight weeks. If yes, price the project. If the sentence will be rewritten by what you learn from users, staff a team. Many clients start in one model and move to the other once the work changes shape. That is normal, as long as the contract says how the switch happens.
