Custom Software Development Pricing Model: Fixed Price Contract

Fixed price is not just a pricing model in custom software
development; it predefines project processes and responsibilities of all involved parties. First and foremost, the constraints of the well-known Project Management Triangle—scope,
time, and cost—are all fixed. They don't have the ability to go
over budget, and that's the most favorable outcome for both parties.
First, the scope must be defined. The Client should put forth the
product requirements. After that, the contractor will calculate the
price and timeframe. Thus it becomes easier for the project manager to
control the app development process. The contractor will bear more risks, and the
team maximizes the precision of their estimates.

The
main problem of a fixed software development price is that there is almost no flexibility for the Client.
Flexibility becomes a necessity in
midsized and large projects, which are under constantly changing
business and technology conditions. In that case, the dedicated team approach and its pricing become optimal from the business point of view, and the software development price equals the contractor's standard hourly rate. As opposed, fixed price works well for
small- and midsized projects that take on average up to 3 months:
more documented requirements, less backend logic.

In
order to understand how we make a custom fixed price project successful,
let's take a closer look at the software product development process, with specific details related to this contract type.

How
Does A Fixed Price Project Run?

1.
A fixed price project is never started without fully documented
requirements:

•
Acceptance
criteria, which define
what must be treated as a ready product. They may comprise:
checklists of actions with expected results, selected test
devices, supported browser and platform versions.

These
requirements must either be created by the Client or elaborated
together with the contractor, and then clarified and approved. When
the scope is fixed, an estimate for development can be made. The
Client and the contractor should know precisely what they want and
come to an agreement on it.

2.
After the requirements are elaborated and approved, the contractor
receives an offer of
implementation, which
typically includes type of collaboration, goals, a fixed scope
divided into milestones with indicated intermediate results,
scheduling of work and payments, possible risks and ways of solving
them, terms of acceptance, and procedure of work with change
requests.

3.
A pre-payment is conducted. Typically it amounts to 50%. Further payments are due upon achieving
each milestone.

4.
The result of each milestone is an intermediate product build
with implemented features. It is provided to the Client in order to
track the progress.

5.
Any change in requirements is handled via a change request –
an additional agreement, created by the project manager.
Mid-development changes affect the scope and software development cost, and the team makes
re-estimations, including them into the change request. Then it
either gets approved and signed by the Client, or rejected, and the
development goes according to the initial approval.

6.
The penultimate milestone results in the alpha build with all
the features being implemented. The team makes sure that the product
works properly on a test server.

7.
The final milestone is refinement and polishing. It results in
the beta build (the final build). The product is put into the
Client's actual work environment on a production server. The product
starts its work with real users and real data.

8.
After the Client is provided with the final build, the acceptance
period begins. During this time, the Client checks the product
according to the approved acceptance criteria and sends feedback to
the contractor. The acceptance period usually lasts 5 days. If there
is a bug on an approved test device, or a mismatch with the
checklists is found, it is corrected by the contractor and the Client
does not pay any additional costs. The time spent on these fixes is
not included in the acceptance period.

9.
After the test period is successfully completed, the contractor
receives the final payment, sends the source code to the Client,
receives feedback, and generally finalizes the project. At this stage,
the custom product may be deployed on the application store, as a standalone operation conducted at the Client's will according to the contractor's standard pricing.

Fixed Price Contract: Pros & Cons

What
Are The Possible Risks Of Fixed Price Software Development?

#1.
Scope-related risks are carried by the Client. They can be resolved through
the abovementioned Change Requests, which in turn affect the cost.

#2. The Client also bears the risks that concern third-party services, which have to work under certain approved conditions, defined by the Client in product requirements. The contractor should be aware of them from the beginning.

#3.
Human risk factors are carried by the contractor. They can affect
the scheduling, but not the cost of software development. In case a developer cannot perform their duties, the
Client is warned, and a substitution is selected.

#4.
Risks concerning third-party libraries,
services, API, SDK, or other tools selected by the contractor
for development, become the contractor's responsibility. They do not affect the cost.

What's
next?

After
the delivery, the Client starts
getting feedback, bug reports, suggestions of new features from
users, and so on. The understanding of product concept and functionality may
change. It may as well be dictated by business and technology.
Therefore, the Client has two options: either to continue the iterative software product evolution, or
employ the team for minor updates and fixes (usually 10-20 hours per
month). The pricing equals the contractor's standard hourly rate.

Conclusion: Which pricing model should be used for custom software development?

Agile
software outsourcing companies tend to avoid projects with fixed price because there is no changeless weather in the world of custom software development. Sometimes it's the Client's will that introduces changes,
sometimes it's a technological necessity or a business condition, dictated by the dynamic market.
When the custom product is bound to evolve, iterative
development is an advisable solution. It's
faster, because there are no Change Requests and lengthy re-estimations. It shows
the progress, because the Client receives intermediate builds upon each
milestone.

What's most important, it allows for changes and flexibility, and
immediate reaction to any change on the market. The product's
relevance is easier to maintain. Otherwise, if a particular project
fits well into the fixed price approach in terms of both requirements and cost, it surely is the better way for the Client.