In 2016, HeyTutor's founders came to us with a one-page spec. Before we built the platform, that page had grown into forty. Each of the thirty-nine new pages recorded a decision the founders hadn't made yet: how tutors get matched, what happens when a session is cancelled, who sees which payment state, what the admin can override. None of it was carelessness. A one-page spec is what a web product looks like before anyone has worked through its edge cases, and nearly every buyer of web application development services starts in that position.
The expansion matters because web application development services are sold in two forms, and the two forms treat those thirty-nine pages very differently. A fixed-scope project prices them as risk up front, then bills for whatever turns up later as change orders. A dedicated team works through them one sprint at a time and bills for the time spent. My position after eleven years of building web apps: if the application is the business, buy a team. A fixed bid is the right purchase in a narrower set of cases than most buyers assume, and I'll define that set exactly below.
The Two Options, Stated Plainly
Option one is the fixed-scope project. You hand over a spec, the vendor quotes a price and a date, builds to the spec, and hands over the code. The contract defines success as matching the document. Option two is the dedicated team. You get a stable group of engineers, usually three to six with a tech lead, billed monthly. They work in two-week sprints against a prioritised backlog you control. Here success means the product moves forward every sprint.
The usual view is that the fixed bid is the safer choice because the cost is capped. That holds for the part of the work the spec actually describes. The weakness is that the spec is also the part most likely to change. HeyTutor's spec grew fortyfold before we wrote code, and a fixed bid on the original page would have capped the price of a product nobody wanted to ship. Four axes decide which model fits, and I'll take them in turn.
Control: Who Decides What Gets Built Next
Under a fixed bid, the contract holds the control. Once it's signed, every change to scope is a negotiation: the vendor has to price it, you have to approve it, and the schedule moves. That's reasonable behaviour on the vendor's side, since their margin depends on the scope holding. The result, though, is that the moment you learn something from users is the moment it gets expensive to act on.
Under a dedicated team, the backlog holds the control, and you own the backlog. Every two weeks you reorder it. If a sales call shows that the reporting module matters more than the onboarding wizard, the next sprint builds reporting and nobody has to amend a contract. For a web app still searching for its shape, that ability to reprioritise is the main thing you're paying for.
Cost: The Cap Covers Less Than It Appears To
Our price bands are public: a SaaS platform usually lands between $60K and $150K, and a two-sided marketplace between $80K and $200K. What moves a project within those bands is mostly the number of roles, the number of integrations, and how much of the spec is settled on day one. A typical four-person dedicated team costs roughly $25,000 to $55,000 a month, depending on seniority mix and stack.
A fixed bid on the same scope has to include a premium for everything unresolved, because the vendor carries that risk. On a spec as thin as HeyTutor's original page, the premium is large, or the vendor bids low and plans to recover the margin through change orders. Either way you pay for the uncertainty, and you pay for it before you know how much of it will turn out to be real. The team model charges you for the uncertainty that actually shows up, in the sprint where it shows up.
Then there's year two, which a fixed-price quote leaves out entirely. A web app that customers use needs security patches, framework upgrades, new integrations and the features the first release deferred. A fixed-bid engagement ends at handover, so year two becomes a new procurement: a new vendor, a new ramp-up, and a new team reading code it didn't write. The capped price was only ever the price of release one.
Speed: Fixed Bids Start Slower and Finish Earlier Than They Should
A fixed bid can't begin until the spec is detailed enough to price. That usually means weeks of requirements work and contract negotiation before any code gets written. At the other end, the contract rewards declaring the work finished once the spec is met, whether or not the product is ready for users.
The team model reverses both ends. Work starts once the first sprint's worth of backlog is clear, and
The clearest case in our history is Nautical Commerce. We inherited a codebase that was already a year old and delivered against a 90-day go-live for a marketplace-as-a-service model. Hitting that date on someone else's code depended on renegotiating scope inside every sprint: shipping what the launch needed and deferring the rest without a contract amendment each time. A fixed bid written on day one would have locked in the wrong scope before we'd read the codebase.
AI coding tools don't change that balance. Our engineers use Claude Code and Cursor as reviewed accelerators, and they shorten the time it takes to type out a decision. They don't shorten the time it takes to make one, and most of a web app's calendar goes on deciding.
Risk: The Fixed Bid Moves the Smaller Risk
A fixed bid moves cost overrun risk onto the vendor. It leaves the larger risk with you: shipping the wrong product, or the right product on a codebase nobody can extend. Those are the risks that actually end web products.
Meal4U came to us after a previous team had failed to deliver the build. We spent a week breaking the scope apart and re-estimated it about ten times, cutting 30 to 50 percent on each pass, until we reached the smallest product that could ship. That kind of repeated cutting only works when scope can change without triggering a contract dispute. It amounts to managing risk by shrinking scope, which a fixed-price structure has no clean way to accommodate.
Quality risk works the same way. When a fixed-bid project runs over its estimate, the vendor absorbs the loss, and the first things to go are the ones the client can't see: test coverage, refactoring, and code review. At EltexSoft, a second senior engineer reviews every pull request before it merges. That is a real line of cost, and a vendor protecting a fixed margin has every reason to cut it. You won't see the effect at handover. You'll see it about eight months later, when a small feature takes three weeks.
Where the Fixed Bid Is the Right Call
The fixed-scope project fits a specific kind of web app, and when the fit is there it's the better purchase. It suits an internal admin panel replacing a spreadsheet workflow, a migration where the end state is a known system, a portal whose screens and rules already exist in another form, and a compliance-driven build where regulation has already fixed the requirements.
The test has four parts. The spec is settled and signed off by the people who will use the app. The build fits in roughly three months. There's no product roadmap after launch. And you'd be comfortable if nobody touched the code for a year. If all four hold, a fixed bid gives you a real cap on a real scope, and paying a monthly team would just buy flexibility you'll never use.
Where the Dedicated Team Is the Right Call
Everything else calls for a team: SaaS platforms, marketplaces, B2B products with paying customers, and any web app whose roadmap runs past its first release. These products are never finished. They change as users change them, so the thing worth buying is a team that already knows the codebase when the next change arrives.
Continuity is the mechanism here, and it shows up over years. We've been MyFlyRight's engineering partner since 2016. We built their claims-automation platform from scratch on React, Laravel and PostgreSQL, and the same team has carried it for close to ten years. The platform has since processed more than a million claims for air passengers, and that volume came from a decade of changes made by engineers who knew why every earlier decision had been made. No handover document could have transferred that knowledge.
The Call
Buyers usually frame the choice as fixed price versus open-ended cost. The better question is whether your web app is a deliverable or a product. A deliverable has a finish line, and a fixed bid prices it well. A product has a roadmap, and a fixed bid prices only its first stretch, then leaves you to buy the rest on worse terms from a team that doesn't know the code. If the app is how your business makes money, it's a product.
Our engagement model follows from that. It starts with a free discovery week that turns your spec into a backlog, whether it's one page or forty. That leads into a paid pilot with no lock-in, so you judge the team on shipped work before committing, and then into two-week sprints with daily standups. If you have a web application you're about to put out to bid, bring the spec to a discovery week, and by the end of it you'll know whether it's a fixed-bid job or a team job.
Last updated November 2, 2026