Short answer: fixed price or time and materials?
Pick fixed price when you can write the scope down and agree how it will be accepted before work starts. Pick time and materials (T&M) when the work cannot be specified yet and someone on your side can steer it every week. The model itself rarely causes a failed project. A mismatch between the model and how well the scope is known does.
Most comparison articles stop at "fixed price is for small, simple projects". That has not been our experience. Lytvynov Production sells fixed-price work every month, including AI features and agents where the outcome is less predictable than a CRUD screen: our AI Sprint delivers one working AI capability in 4 weeks for a fixed $10,000, and every other project gets a fixed quote after a short scoping call. Our minimum project size is $10,000.
This guide covers the head-to-head choice. If you are also weighing a dedicated team, read dedicated team vs fixed price vs time and materials. For the details of fixed pricing on AI work, see fixed price AI development.
What do you actually pay for under each model?
Under fixed price you pay for a result: an agreed scope, delivered by an agreed date, accepted against agreed criteria. Invoices follow milestones, not hours. The vendor carries the risk that its own estimate was wrong, and you carry the risk that the scope you wrote was the wrong scope.
Under time and materials you pay for capacity: hours worked at an agreed rate card, plus any direct costs such as licences or cloud services. Invoices follow timesheets, usually monthly. You carry the risk of overruns, and in return you can reprioritize, cut or add work on any day without a contract change.
| Fixed price | Time and materials | |
|---|---|---|
| What you sign | Scope document, price, milestones, acceptance criteria | Rate card, roles, reporting rules, often a budget cap |
| What an invoice says | "Milestone 2 accepted" | "312 hours in March, by task" |
| Who pays for a wrong estimate | Vendor | Client |
| Who pays for a wrong idea | Client, through change requests | Client, through more hours |
| How a change happens | Change request: estimate, approval, new price | Next sprint's priorities |
| Budget known before start | Yes, for the agreed scope | Only as an estimate |
| What the vendor is pushed to optimize | Delivering the scope efficiently | Delivering value per hour, if you watch |
| Your time needed | Heavy at scoping and acceptance, light in between | Steady: weekly priorities, reviews, approvals |
| Typical way it goes wrong | Argument over what "done" or "in scope" meant | Hours keep growing while the finish line moves |
One row deserves attention. A fixed price does not protect you from building the wrong thing. It protects you from paying extra while the right thing takes longer. If you are unsure what to build, a fixed price simply moves the uncertainty into change requests.
A worked example: the same project under both models
Take one MVP estimated at 500 hours of work: web app, accounts, payments, an admin panel and one integration. The rate below is an illustration using a typical 2026 range of $30 to $50 per hour for senior engineers in Ukraine; it is not our rate card.
Under T&M at $40 per hour, the estimate is $20,000. If the scope stays as planned, you pay about $20,000. If the integration turns out to have a poorly documented API and the admin panel grows by a few reports, 500 hours become 650 and you pay $26,000. If the founder changes the onboarding flow twice, it can go further.
Under fixed price, the vendor adds a risk buffer, often 15 to 30 percent. With 20 percent the quote is $24,000. If the work takes 650 hours, you still pay $24,000 and the vendor absorbs the difference. If the founder changes the onboarding flow, that is a change request with its own price, say $1,500 to $3,000 depending on size.
| Scenario | T&M at $40/h | Fixed price with 20% buffer |
|---|---|---|
| Work goes to plan (500 h) | $20,000 | $24,000 |
| Hidden complexity (650 h) | $26,000 | $24,000 |
| Hidden complexity plus two scope changes | $26,000 + change hours | $24,000 + two change requests |
The pattern holds for most projects: T&M wins when the estimate is accurate, fixed price wins when it is not, and scope changes cost you under both. What fixed price really buys is a number you can plan around, for a seed round, a board approval or a budget line that cannot move.
In practice the gap is often smaller than 20 percent, because a team that has built many similar projects estimates tightly and needs a smaller buffer. With us, most MVPs land at $10,000 to $20,000 at a fixed price; see the MVP development cost guide for what drives the range.
When is fixed price the better choice?
Fixed price is the better choice when the finish line can be described in a page or two and you need to know the cost before committing. Typical cases:
- An MVP after scoping. A founder with a defined first release, a limited budget and a launch date. Our MVP development work is quoted this way.
- One AI capability. A feature that drafts, classifies or extracts, an assistant over your documents, or an agent for one workflow, measured on real examples.
- A rebuild to a known target. A redesign to a finished design system, a migration with a clear start and end state, a specific integration.
- A first project with a new vendor. A fixed, bounded piece of work shows how the team estimates and delivers with your risk capped.
Our freelance experts marketplace project is a clean example: the public web experience of a French IT marketplace was rebuilt after a rebrand, from landing pages to freelancer search, profiles and authentication, on desktop and mobile. The brand guidelines defined the scope, so it was delivered within a fixed scope and budget.
How do you make a fixed price safe on AI work?
You make a fixed price safe on AI work by fixing what can be fixed, measuring quality with numbers, and naming in advance what stays variable. AI adds one risk that ordinary software does not have: the output is right most of the time, not all of the time. A contract that ignores this turns "is it good enough?" into an argument. This is how we handle it in practice.
- Scope one capability in a scoping call. "Draft replies to warranty claims from our policy documents" can be priced. "Add AI to support" cannot. The call ends with a short written scope: what the feature does, which inputs it handles, which systems it touches, and what is out.
- Turn acceptance into an evaluation set. We collect 30 to 100 real examples with expected outputs before the work starts. Done means a measured result on that set, plus a fallback for uncertain cases, such as a human review queue.
- Look at real data before fixing the price. Scanned PDFs, missing fields and duplicates are found in sample files, not in the sales call. If the data is messy, the scope is narrowed or cleanup becomes a separate item.
- Route scope growth into the next sprint. Another document type or another language is a reasonable request and a new piece of work. In an AI Sprint it becomes the next sprint at the same fixed price, rather than an open invoice.
- Simplify instead of extending. If a target proves harder than expected inside the sprint, we narrow the input types or add a review step together. The price and the date do not move.
- Deliver working software every week. Problems surface in week 1 or 2, while there is still time to adjust the scope.
Some costs cannot be fixed by anyone, because they depend on your traffic and your accounts. A fair fixed-price AI quote lists them separately:
| Fixed in the quote | Stays variable, paid separately |
|---|---|
| Design of the AI flow, development, evaluation, deployment | Model API usage, billed per token by the provider |
| The agreed capability and its evaluation set | Hosting, vector database and other cloud services |
| Source code in your repository, architecture note, handover | Large data cleanup that was not in the written scope |
| An estimate of monthly model and hosting cost | Third-party licences and accounts in your name |
Model usage is the item buyers ask about most. It is paid by you directly to OpenAI, Anthropic or another provider, and it ranges from tens of dollars a month for an internal tool to several thousand for a busy customer-facing feature. We measure cost per request during the sprint so the monthly bill is known before launch. Our own product AI Resume Master, which reached 50,000 monthly active users, is where we learned to watch that number from the first week.
When is time and materials the better choice?
Time and materials is the better choice when nobody can write the finish line yet, or when the work is a stream rather than a project. It fits:
- Research and feasibility work, where nobody knows whether current models or a given approach can do the job at all. Fixing a price there is a bet. A short time-boxed experiment, then a fixed price for the build, is the usual answer; our AI proof of concept guide describes it.
- A live product after launch, where priorities change every week based on user feedback.
- Support and maintenance, with a small and unpredictable volume of work.
- Work inside a system nobody has documented, where the first weeks are discovery.
- Teams with a strong product owner who has time to set priorities and review output every week.
T&M needs process to stay healthy: a prioritized backlog, estimates per task, a weekly demo, time reports by task and a monthly budget review. If a vendor cannot tell you what last week's hours produced, the problem is the vendor, and a fixed price would not have fixed it.
Hybrid models: what most well-run projects use
Most projects do not need to choose one model for their whole life. The common hybrids combine the budget certainty of fixed price with the flexibility of T&M at different stages.
| Hybrid model | How it works | Good for |
|---|---|---|
| Fixed price per milestone | The project is split into milestones, each with its own scope, price and acceptance | MVPs and larger builds where priorities may shift between releases |
| Repeating fixed sprints | A fixed price per time box with a scope agreed before each one, as in our $10,000 AI Sprint | AI features and products built step by step |
| Capped T&M (not-to-exceed) | Hourly billing with a ceiling that needs written approval to exceed | Work that is mostly clear but has one uncertain area |
| Discovery, then fixed build | A short paid scoping or experiment, then a fixed quote for the build | New products and AI ideas that are not yet specified |
| Fixed build, then flexible support | Fixed price to launch, then T&M or a monthly team | Products that move into continuous improvement after launch |
Two things make hybrids work. Each fixed piece needs its own acceptance, so problems do not pile up until the end. And the contract should say how the team, code and knowledge carry over between phases, so the switch does not cost a new onboarding.
Assumptions belong in the scope as well. In our flower subscription project, Telegram ordering and Uklon Delivery dispatch ran in sandbox mode until the client connected real accounts. Writing down which accounts the client provides, and when, keeps a fixed-price build from stalling on something outside the vendor's control.
Contract clauses to check before you sign
The clauses that protect you are different under each model. The general terms that apply to every model, such as IP assignment and client-owned accounts, are covered in our engagement models guide. These are the model-specific ones.
Fixed price contract:
- Scope annex with assumptions. The written scope is attached to the contract, together with what you provide (data, accounts, content, decisions) and by when.
- Explicit exclusions. What is out of scope, and which costs are paid separately: model usage, hosting, licences, data cleanup.
- Acceptance criteria and window. How each milestone is checked, how many days you have to accept or list defects, and what happens if you do neither.
- Change request procedure. How changes are estimated, the rate or method used to price them, and who on your side may approve them.
- Payment tied to milestones. Payments follow accepted deliverables, not calendar dates alone.
- Warranty period. Defects against the agreed scope found after acceptance are fixed at no cost for a set period.
- Termination and work done. What you pay and what you receive (code, documentation, access) if either side stops early.
- For AI work: the evaluation set and the fallback. The examples, the quality bar and what happens if the bar is not reached, for example scope simplification rather than an open extension.
Time and materials contract:
- Rate card by role and seniority, and who is allowed to bill at which rate.
- Budget cap and warning threshold. A not-to-exceed amount per month or phase, and a written warning when spend reaches an agreed share of it.
- Estimate variance rule. The vendor tells you before a task goes meaningfully over its estimate, not after.
- Time reports by task, with access to the task board, at the same frequency as invoices.
- Billing increments and non-billable time. Whether onboarding, internal meetings and fixing the vendor's own defects are billed.
- Notice period to scale the team down or stop, and the handover obligations when you do.
How to choose: five questions
Answer these honestly. If most answers point one way, start there.
- Can you describe done in two pages, with how it will be checked? Yes points to fixed price. No points to discovery first, or T&M.
- Does the budget have a hard ceiling? Yes points to fixed price or capped T&M.
- Will someone on your side spend several hours a week setting priorities? No points to fixed price; T&M without a product owner drifts.
- Is the technical approach proven? For AI, if nobody knows whether a model can do the task, run a time-boxed experiment before fixing the build.
- Is this a project with an end, or a product with a roadmap? A project fits fixed price or milestones; an ongoing roadmap fits T&M or a dedicated team.
How we price at Lytvynov Production
We are a Ukrainian team founded in 2020, with senior engineers working with AI coding agents and clients in the US and Europe. Our default is a fixed quote after a short scoping call. AI work runs as fixed $10,000 sprints of 4 weeks, which you can repeat month by month or stop after the first one and keep everything built. Larger builds are split into fixed-scope milestones. Once a product moves into a stream of weekly changes, we switch to a model that fits that, usually a dedicated team.
If you have a project and are not sure which model fits, book a 30-minute call on our contact page or get a range with the price estimate. We will tell you whether we can fix the price now, what would need to be clarified first, or why a flexible model would serve you better.