
By the time you have two or three finalists, every vendor looks good. Their decks show live products, their reviews are positive and the calls go well. The differences sit in three places: what each proposal assumes, what the contract lets you do when something goes wrong, and how the vendor handles a short paid first milestone. We write proposals and contracts ourselves, so this guide reads them from the vendor’s side of the table.
If you’re still building a shortlist, start with how to choose a software development company. It covers the brief, the scorecard and the questions to ask. This guide picks up where that one ends.
Read the proposal for its assumptions, not its total
A price is only as good as the assumptions behind it. Two proposals with the same total can describe very different products.
| What you see | What it can mean | What to ask |
|---|---|---|
| A wide range, like $30,000-120,000 | The vendor hasn’t decided what it would build | “Which features move the price from the low end to the high end?” |
| A fixed price on a one-paragraph brief | Every unclear item will come back as a change request | “List what’s included and what counts as a change.” |
| Hours by role, with no feature list | You can’t tell what you get for the money | “Break the hours down by feature.” |
| No line for testing | Testing gets squeezed, or you end up doing it | “Who tests, and when?” |
| No running costs | Hosting, store fees and outside services land on you after launch | “What will this cost each month after launch?” |
| A team of “experts” | The people haven’t been chosen yet | “Who exactly, at what level, for how many hours a week?” |
Also look at what the proposal leaves out on purpose. A good proposal says what waits for a later release. If nothing is left out, the vendor either hasn’t read your brief or is agreeing to everything to win the deal.
Running costs start before launch. The Apple Developer Program costs 99 USD per membership year, and a Google Play developer account has a US$25 one-time registration fee. Those are small and fixed. Hosting and paid outside services grow with your users, so ask for a monthly figure at the number of users you expect in the first year.
Check the people, not the company
You sign with a company, but you work with four or five people. Ask:
- Will the people from the sales call work on your project?
- What level is each person, and how many hours a week will they give you?
- Who makes technical decisions, and can you talk to them directly?
- What happens if someone leaves?
The last question matters most, because people do leave. On the Traza project, one of our developers dropped out mid-project. We covered the cost and gave the work to the second developer, so the client’s budget and launch date stayed the same. Ask every finalist for an example like that, and for their rule in writing.
Five contract terms that protect you
Contracts are written for the day something goes wrong. These five terms decide how that day goes.
- Ownership: the code, designs and accounts should be yours. The US Copyright Office’s Circular 30 explains that a commissioned work counts as a “work made for hire”, owned by the party that ordered it, only if it falls into one of nine categories and both sides sign a written agreement saying so. So don’t assume that paying for the code makes it yours. Put the transfer of rights in the contract, and have a lawyer check the clause for your country.
- Access: code goes into repositories you own from the first day, and the cloud, hosting and store accounts are in your company’s name. Apple shows the enrolled organization’s name as the seller of its apps on the App Store, so an app released from the vendor’s account carries the vendor’s name. Enrolling a company with Apple takes a D-U-N-S Number, so start early.
- Change control: how a change is estimated, who approves it, and how it moves the price and the date.
- Acceptance: what “done” means for each part of the work, and how long you have to check it.
- Exit: how either side ends the contract, how much notice it takes, and what the vendor hands over, from code and documentation to access and a handover call.
Send this list before price talks end. A vendor that pushes back on access or exit terms is telling you how a breakup would go.
Ask for a short paid first milestone
The fastest way to judge a vendor is to pay for one or two weeks of work and look at the result. Pick a milestone that:
- takes one or two weeks
- has a fixed price
- ends with something you keep, such as a written scope, designs, an estimated backlog or working code
- is useful even if you don’t continue with that vendor
Ours is the discovery sprint on our MVP development page. It costs $3,000 and takes one week. You get a written scope, up to 6 main screens in a clickable prototype, a technical plan, a day spent testing the riskiest technical question, a backlog with hours and a fixed price for the build. If you continue with us, the $3,000 counts toward the build. If you don’t, any team can use the files.
During the milestone, watch for what a sales call hides:
- Do they ask about your users, or only about features?
- Do they tell you when an idea is expensive, and offer a cheaper way?
- How do they answer a question they can’t answer yet?
- Do they show the work on the day they promised?
If you’re replacing another vendor
Switching vendors adds one step: find out what you have before you agree a price for the next phase. Without that, every new vendor is guessing at the state of the code, and the guess ends up in the price.
Our code and architecture audit costs a fixed $3,500 and takes 5 working days. It covers what you own, the state of the code, security findings and what to keep, fix or rebuild. It’s sold on its own, so you can take the report to any team.
Don’t skip the security part. In Verizon’s 2026 Data Breach Investigations Report, 31% of breaches started with software vulnerabilities, ahead of stolen passwords as the top way attackers got in.
How we would estimate the work before you compare proposals
Proposals are easier to read when you have your own range to hold them against.
- Our project estimate turns your brief into user stories. You confirm what’s in scope, and every hour in the budget traces back to a story you kept. Any feature a proposal adds or drops shows up against that list.
- We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour. It’s a planning range, not a fixed quote.
- For market size, the estimate suggests customer groups and gives each a TAM, SAM and SOM with a note on what the number covers. Treat them as hypotheses to test, not verified demand, and keep only the groups you would really sell to.
- The unit economics show how many customers pay for the build and in which month it’s paid back. You can change any starting number and the math updates.
You can estimate your MVP’s cost and timeline before the first vendor call.
What we would do
- Ask each finalist to rework their proposal against the same brief, with the assumptions listed.
- Put the proposals side by side, using the table above.
- Meet the people who will do the work, not only the sales team.
- Send your five contract terms (ownership, access, change control, acceptance, exit) before price talks end.
- Buy a one- or two-week paid milestone from your top choice.
- Decide on the long contract after the milestone review, not before.
Let’s discuss your product idea.
FAQ
How do I choose a tech vendor?
Compare the finalists on three things: the assumptions behind each proposal, the contract terms for ownership, access, changes, acceptance and exit, and how each vendor handles a short paid first milestone. The milestone tells you more than a sales call.
What should a software development proposal include?
What will be built and what waits for later, the assumptions behind the price, who will do the work and at what level, how testing is done, the running costs after launch, and how changes are priced.
What contract terms matter most with a software vendor?
Ownership of the code, designs and accounts; access to repositories from day one; change control; acceptance criteria; and exit terms with a handover. Have a lawyer check the ownership clause for your country.
Who owns the code a software vendor writes?
It depends on your contract and the law where you are. In the US, the Copyright Office explains that commissioned work counts as made for hire only in set categories and with a signed written agreement. Put the transfer of rights in writing.
What is a good first milestone with a new vendor?
One or two weeks, a fixed price and a result you keep even if you stop, such as a written scope, designs and an estimated backlog. Our discovery sprint is one example: $3,000 for one week, counted toward the build if you continue with us.
Turn your assumptions into a project brief
Roles, approach and resources are easier to judge on a short first milestone than in a sales call. Agree on that milestone, who reviews the work and how you can leave, then decide on a long-term team. Explore dedicated development team and the Livetag case study.
Plan a first milestone with a vendor
Start with an AI-assisted project brief covering scope, budget, market assumptions and risks. Review its hypotheses before making a commitment.