Pricing and Engagement Models: What to Expect

Fixed-price projects: when they work and when they do not

We offer fixed-price engagements when the scope is genuinely stable: a defined integration, a migration between two known systems, or a bounded feature such as adding Apple Pay and Google Pay to an existing checkout. For a project like that, we run a paid discovery of one to two weeks, produce a written specification, and quote a single number. Illustratively, a checkout payment integration for a mid-size retailer might land between $18,000 and $35,000 over six to ten weeks with a team of three. The number is a range because we have not yet seen your codebase.

Fixed price works when requirements change slowly and the acceptance criteria are testable. It stops working the moment the specification is wrong. If you discover mid-build that your order data model cannot support partial refunds, that is a change order, and we will price it separately. We say this plainly because fixed price is not a discount, it is a risk transfer, and the risk is priced in. Martin Fowler has written extensively on how changing requirements interact with planned scope, and the practical lesson is that the specification is the product of the engagement, not a formality. If you cannot describe the outcome in a page, fixed price is the wrong model.

Time-and-materials: flexibility and cost control

Time-and-materials is our default for anything exploratory. We bill in two-week sprints against a written backlog, you see the hours, and you can stop at the end of any sprint. Illustratively, a two-person team at blended rates of $140 to $190 per hour runs $11,000 to $15,000 per week, so a twelve-week engagement lands near $130,000 to $180,000. Those figures are illustrative and depend on seniority mix and location.

The control mechanism is the backlog, not the invoice. We ask for a product owner who can make decisions inside a sprint, and we publish a burn chart every Friday. If a healthcare scheduling build turns out to need HL7 interface work that nobody scoped, you decide whether to fund it, and the decision costs you a conversation rather than a change order negotiation. The tradeoff is that you carry scope risk. We mitigate it with a monthly not-to-exceed cap that you set, and we flag early when a sprint is trending over. Gartner's guidance on IT cost management consistently favors this kind of incremental funding for work with genuine uncertainty, and our experience matches it. Time-and-materials is not cheaper, it is simply more honest about what is unknown.

Dedicated teams: long-term product development

For products that will run for a year or more, we staff a dedicated team that works only on your codebase. A typical squad is one tech lead, two full-stack engineers, one QA engineer, and a part-time designer, billed monthly at a flat rate. Illustratively, that squad runs $48,000 to $72,000 per month depending on seniority and whether you need on-call coverage. We handle recruiting, replacement, and bench risk, and you get continuity rather than a rotating cast.

This model suits logistics tracking platforms, internal operations tools, and any product where the roadmap is real but the next six months are not fully specified. You direct priorities; we own delivery. We run a quarterly planning session, a monthly review, and a weekly demo, and we expect you to attend all three. Dedicated teams fail when the client treats them as staff augmentation with no product direction, so we ask for a named product owner with at least a day per week committed. If that person does not exist in your organization, time-and-materials with a tighter scope is usually the better fit. We will tell you which one we think you need rather than sell the larger contract.

What drives cost in a software project

Cost is driven by four things, in roughly this order: uncertainty in requirements, integration surface area, compliance and data handling, and the cost of getting it wrong in production. A greenfield internal tool with two integrations is a different animal from a patient scheduling system that touches an EHR, handles protected health information, and must pass an audit. The second is not more expensive because we charge more per hour; it is more expensive because it needs more testing, more review, and more documentation.

Team seniority moves the rate, not the hours. A senior engineer at $190 per hour often finishes a hard task in fewer hours than a junior at $95, which is why comparing blended rates across proposals is misleading. Third-party services add recurring cost you should budget separately: managed PostgreSQL, cloud functions, observability, and CI minutes. Illustratively, a small production system might run $400 to $1,200 per month in infrastructure before any vendor licenses. McKinsey's work on digital transformation repeatedly finds that the underestimated line item is organizational change, not engineering. Plan for training, documentation, and a transition period. We include a handover sprint in every fixed-price and time-and-materials engagement so your team can maintain what we build.

How to compare proposals fairly

Compare proposals on four axes: scope definition, team composition, change handling, and exit terms. A low fixed price with a vague specification is not cheaper, it is a loan against future change orders. Ask each vendor to name the people who will do the work, and ask what happens when one of them leaves. Ask how changes are priced and how disputes are resolved. Ask who owns the code, the infrastructure, and the documentation at the end.

We answer all four in writing before a contract is signed. Our proposals list named roles, a rate card, a change process, and a handover plan, and we will walk you through them line by line. If a competing proposal is materially cheaper, find out which of the four axes it is trading away. It is usually scope definition or exit terms. We would rather lose a bid on a clear comparison than win one on an unclear scope.

Before a discovery call, gather three things: a one-page description of the outcome you want, a list of systems we would need to integrate with, and your budget range and decision timeline. With those in hand we can tell you within one call which engagement model fits and roughly what it will cost. If you already have proposals from other firms, send them and we will help you read them.

Sources

Background for this page was drawn from the published guidance below. Both are independent of this site and were read in full before writing.

• Gartner, IT research
• Martin Fowler, software architecture
• McKinsey, technology research