Fixed-price software development: how we make the numbers hold

A software vendor quotes a sum for a project. A couple of months later, the invoice is noticeably bigger, and nobody can point to the exact moment the number changed. That gap is the single biggest reason founders and operations leads distrust fixed-price contracts: not because fixed price is a bad idea, but because many vendors quote it without the discipline to keep it.

Fixed price works when the scope is locked before the quote, not after. This piece walks through what an honest fixed-price engagement looks like: what should be in the contract, what drives the cost, where the model breaks, what to check in a contract in Kazakhstan, and how we run it at Pazl.

What "fixed price" actually means

A fixed-price contract sets one number for one defined scope, delivered by one date. That is the whole idea. The catch is the word "defined". If the specification is vague, "fixed price" just means the vendor picked a number and hopes.

Three things have to exist before a price can honestly be called fixed:

1. A written specification both sides sign off on: screens, flows, integrations, data, what is in and what is out.
2. A payment schedule tied to stages and acceptance, not to hours worked.
3. A change process for anything requested after the specification is locked: separate, in writing, and agreed before work starts.

Without all three, a "fixed price" quote is really time-and-materials with a number attached for marketing purposes. The client finds out the difference the first time they ask for "one small addition".

Three ways vendors quote fixed price, and where the risk hides

Padded time-and-materials. The vendor estimates hours, multiplies by a rate, adds a buffer for the unknown, and calls the total "fixed". If the project runs long, the buffer disappears fast and the vendor either eats the loss (rare) or starts finding "extra" items outside scope (common). The client pays for the vendor's risk twice: once in the padding, again in the change orders.

A price on a vague specification. The contract states a price but the specification is a page of bullet points, not a description of how the system works. Every ambiguity gets resolved in the vendor's favour during the build, because there is no document to hold them to.

Specification first, price second. The specification is written and approved before the number is set. The price reflects a defined deliverable, so scope creep becomes visible immediately: it is the thing not in the document. This is the only version that actually behaves like a fixed price.

The difference is not in the contract wording. It is in whether the specification was finished before the price was, or after. We compare the two models point by point in fixed price vs. hourly billing.

How we structure a fixed-price engagement

Our process is built around locking scope before locking price, and it runs the same way regardless of project size.

Call. We talk through what the software needs to do, who uses it, and what it connects to: a bank and payments, Kaspi, 1C, a CRM, a till, an internal database. No quote happens on this call.

Proposal. We write up the scope as we understand it and attach a price tied to that scope, not a guessed number.

A contract with a fixed price and a fixed timeline. The specification is signed as an appendix. We sign the contract with your LLP or sole proprietorship, priced in tenge. The specification is the boundary of the contract: if it is not written down, it is not included.

Development with regular demos. The client sees working software as the project goes, not a status email. This is also the fastest way to catch a misread requirement before it costs a rebuild.

Acceptance. The client reviews the delivered work against the signed specification and signs the acceptance certificate.

A six-month warranty on everything we built, starting from acceptance.

Revisions that fall inside the original specification are free: that is not a change order, that is us finishing the job we quoted. Anything that was not in the specification gets its own short agreement and its own price before we touch it, not a surprise on the invoice. We answer quickly on active projects, because a fixed-price client waiting three days for an answer is exactly the situation that makes people distrust fixed price.

Two cost items sit outside our number by design: hosting and servers, and the domain and SSL certificate. They go on the client's own accounts, so the client owns the infrastructure, not us, and there is no lock-in through a server the vendor controls. Why that matters in the long run is covered in your own software or vendor lock-in.

We hand the source code and credentials over to the client. How the rights to the software pass to the client should be stated explicitly in any contract you sign, with us or anyone else; have a lawyer check the wording.

Our starting prices: a website from 540 000 ₸, a web app or customer account area from 1 000 000 ₸, a standard integration of two systems (1C and Kaspi, for example) from 270 000 ₸. Larger builds scale with scope, not with hours logged.

What drives the price: typical projects

The prices below are the lower bound of our price list, not a quote. The final number depends on integrations, data volume and design complexity. Treat the table as the start of a conversation, not an estimate.

Two scope traps show up in almost every quote dispute. The first is "integration" meaning something different to each side: read-only sync, or two-way exchange with error handling? The second is "admin panel" meaning a login screen to one party and a full role-based permission system to the other. Get both defined in the specification, in writing, before the price is set. You can see how we describe an exchange with an accounting system on our 1C integration page.

Where fixed-price contracts actually break

Undefined third-party dependencies. If the software depends on a bank's API, Kaspi or a till vendor, and that API changes mid-build, who absorbs the cost? A well-written contract states plainly that the vendor is not liable for a third party's breaking change, because no fixed price can account for a partner's roadmap.

"Just one more thing". Every added field, screen or rule that was not in the signed specification is a change order, full stop. The discipline protects both sides: the client knows the original price is honest, and the vendor does not do unbounded work for free.

A specification that was never actually finished. We have seen specifications dozens of pages long, built around a database schema and written for engineers, not for the business decision the client needed to make. That is not a usable specification; it is a stack of assumptions. A workable specification is short enough to argue about before the money moves, not after.

Payment tied to time instead of stages. If invoices go out weekly regardless of what shipped, there is no real alignment of incentives. That is time-and-materials wearing a fixed-price label.

A contract in Kazakhstan: what to check

This section does not replace a lawyer's advice, but a few things are worth checking in any development contract:

• Parties and subject. A contract between your LLP or sole proprietorship and the vendor, the specification as an appendix, the price in tenge, the timeline and the acceptance procedure.
• Stages and payment. Payment is tied to delivered stages and signed acceptance certificates, not to the calendar.
• Closing documents. An invoice and an acceptance certificate. VAT payers issue invoices electronically through the ESF e-invoicing system (Tax Code of the Republic of Kazakhstan, Article 492(1), text on adilet.zan.kz). Ask your accountant which documents your books need.
• Rights to the code. Who receives the rights to the software and the source code, and when. Spell it out and have a lawyer check the wording.
• Changes. Any work outside the specification goes into a supplementary agreement with a price and a timeline.
• Personal data. If the system stores data of citizens of Kazakhstan, the database must be located in the country (Law No. 94-V of 21 May 2013 On Personal Data and Their Protection, Article 12(2), text on adilet.zan.kz). This belongs in the specification from day one, not as an afterthought.
• Disputes. The claims procedure and jurisdiction. Usually negotiation and a written claim come first.

How this looks in practice on our projects

We have built systems across a handful of recurring patterns that map directly onto fixed-price engagements.

One was an AI agent for an events agency buried in repetitive client messaging: meeting questions, status updates, everyday details, arriving as text, voice, photos and video. Instead of hiring more staff to keep up with growth, the agency needed the routine handled automatically, with a person pulled in only when a conversation needed judgment. We built the agent to hold context across a conversation, create tasks in the tool the team already used, and hand off to a manager with the full thread attached when something got sensitive. The specification defined exactly which messages the agent could resolve alone and which always escalated. That boundary was the actual deliverable, not the AI model itself.

Another was an ERP for a logistics company whose fleet, documents and finances lived in separate programs and spreadsheets. We built one system where a dispatcher, an accountant and an owner each see the part of the data relevant to their job.

A third was a loyalty app for a retail chain connected to its tills and 1C: a digital card, cashback at checkout, and an admin panel for running promotions without a new app release. The hard part was not the app; it was the exchange with tills and an accounting system that have their own rules about how transactions are read and written. That integration boundary went into the specification in detail before we quoted a number. We apply the same rule across our mobile app development: every integration is specified before the price is set.

In every case, the specification did the actual work of keeping the price fixed. The build was the easy part once the boundary was clear.

The takeaway

Fixed price is not a pricing trick; it is a discipline that depends entirely on how well the scope gets nailed down before the number does. A quote without a signed specification is a guess with a number on it. A quote built on a specification, with stage payments, a defined change process and a warranty that starts after delivery, is a real commitment both sides can hold each other to. For how this works on the first version of a product, read how we develop an MVP.