Hire by Technology
SERVICES
Contents
Share this article
Key Takeaways
Most software development proposals are clear about what's included. Most problems result from what is excluded being omitted, creating a bunch of grey areas where it is unclear who takes responsibility.
The disputes that follow aren’t necessarily based on bad intent, but from unstated assumptions.
In a regulated build, the exclusions matter more, because the items commonly left out are security review, compliance evidence, and QA, none of which you can skip.
Let’s take a look at what is most commonly included in custom software development services, what isn’t, and how to choose a partner based on what you actually need.
At Trio, we specialize in fintech software development, so you can rest easy knowing that everything you need for a regulated product is included.
In our experience, two proposals can name the same deliverables, "development," "QA," "deployment," and mean materially different things by each one.
This is largely because the boundary of each deliverable sits somewhere different, and neither document says where.
Most disputes that our clients have mentioned on previous software engagements come from unstated assumptions. Nobody set out to under-scope, but vague statements mean you are relying on people to interpret the scope of work the same way.
This is a different problem from the hidden costs of outsourcing, ramp-up time, management overhead, and attrition.
| Phase | Typically Included | Where the Boundary Usually Sits |
| Discovery | Requirements clarification, technical planning, estimation | Often billed separately, or offered free and correspondingly shallow |
| Design | UI design for agreed screens | Design system creation, and revision rounds beyond a stated number |
| Development | Building the agreed feature set | Anything not explicitly enumerated; "similar to X" isn't enumeration |
| QA | Functional testing against acceptance criteria | Load, security, accessibility, and device-matrix testing |
| Deployment | Getting the product live once | Environment setup, infrastructure-as-code, and CI/CD pipeline construction |
| Post-launch | A defect warranty for a defined window | Everything after it, including platform-forced maintenance |
We always recommend that you pay for discovery if the option exists.
A paid discovery phase produces a scope document specific enough to argue with directly, since it allows you to cover every screen, integration, and acceptance criterion named individually.
Free discovery, on the other hand, produces a proposal, which is a sales document with different incentives behind it.
"Included QA" almost always means functional testing specifically.
Performance, security, and accessibility testing are entirely separate disciplines with separate tooling and expertise. If you want these, they will probably need to be listed as separate line items, even when a proposal's language makes "QA" sound like it covers everything.
The warranty window is by far the sharpest boundary on this whole table.
After that window ends, any defect fixes become billable work.
There are a couple of exclusions that are rarely listed in generic software development agreements, but they almost always exist. It is important that you know about these so that you can prepare ahead of time, or ask about explicitly including them.
Third-party licenses and subscriptions, the design tool, the monitoring platform, a component library, and a KYC provider's sandbox environment rarely show up in the development quote itself.
Cloud infrastructure costs are usually the client's (yours) from day one, not bundled into the build price.
If you need to migrate data from an existing system, those costs and responsibilities will also belong to you, and will rarely be scoped by the vendor.
In far too many cases, integration work against third-party APIs whose behavior differs from their documentation gets scoped as if the vendor's docs are accurate.
Content and copy need to be written by someone, but at the end of the day it's rarely the development team unless that was stated explicitly.
Rework caused by a decision the client changes mid-build is legitimate change-order territory, but only if a change-order process was actually defined before the change happened.
App store submission, review handling, and rejection remediation sit largely outside most development quotes.
Security review or penetration testing is commonly excluded entirely unless named specifically. Accessibility remediation is expensive precisely because it wasn't designed from the start.
Once the app is live, you’ll still need development work. Platform-forced maintenance, annual OS releases, enforced API level deadlines, dependency and SDK churn keep arriving. None of this is usually covered.
Monitoring, incident response, and on-call coverage are their own separate commitment.
A recurring source of dispute is disagreement about whether a piece of work is a scope change or the correction of a defect.
That distinction is so important because it decides who pays for it.
Agreeing what counts as a defect, in writing, before work starts, is the best way to resolve more future arguments.
| Model | Who Carries Overrun Risk | Scope Behavior | Fits |
| Fixed price | Vendor | Rigid; every variation is a change order | Well-defined, stable, short scope where budget certainty matters most |
| Time and materials | Client | Flexible; direction can shift without renegotiation | Exploratory work, post-launch iteration, maintenance |
| Dedicated capacity | Shared | Scope functions as a roadmap, not a fixed contract | Continuing products where the work doesn't have a natural end date |
Fixed price transfers overrun risk to the vendor. To combat this, the quote will usually include a contingency buffer.
As a client, this added cost is often worth it because you're paying for certainty.
The failure mode here is that a vendor protecting a fixed margin protects it somewhere. This could be through less testing, skipped refactoring, and more junior staffing on the actual build. You essentially shift the goal from the best product to hitting the target date.
The opposite hiring option, based on time and materials, removes change-order friction entirely and lets a team improve the product each sprint based on what's learned.
It has its own failure mode, of course, which runs in the other direction. You have an increased risk of reduced project management discipline, as well as scope and timeline drift. Nobody in particular is accountable for these issues either.
The best option, and the most common one that we are seeing in 2026, is a hybrid model, where you use fixed price for a well-defined initial build, then time-and-materials or a capacity retainer for the iteration and maintenance that follows.
Regardless of which option you decide to go with, there are three things to have in place:
While everything that we have discussed applies to both general and regulated products, industries like fintech have unique requirements that need to be layered on top of that.
The items most commonly excluded from a standard scope (security review, penetration testing, deeper QA, documentation, and evidence retention) are not optional.
A scope boundary that's perfectly reasonable for a marketing site can be a genuine compliance gap on a payments product.
What to insist stays inside scope, or budget explicitly outside it if it doesn't:
This is part of why fixed price fits regulated builds less comfortably.
To accurately compare two proposals, you need to normalize the scope first. Two proposals aren't comparable at all until both list the same screens, integrations, and acceptance criteria, so you should ask both vendors to price the identical document.
Ask for the exclusions list explicitly: "What's not included that we might reasonably assume is?"
Also make sure that you clarify how a defect gets distinguished from a change, and get the answer in writing before signing anything. Check whether "QA" in the proposal means functional testing only, and ask about what happens once the warranty window ends, and what maintenance actually costs after that point.
Once that is done, you can test the fixed price directly.
If the product itself is regulated, also make sure to find out about compliance obligations once the code ships.
At Trio, we can walk you through all of this. Our extensive experience means you get contracts and developers that have been thoroughly tested in production environments.
To see if we are the right fit for you, request a consult.
Expertise
Subscribe to our newsletter
Related
Content
Continue Reading
