What Every Line of a Dev Proposal Actually Means

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A first-time technical founder in Dubai raising a pre-seed round who has received two or three proposals from dev partners and cannot tell whether the pricing differences reflect scope gaps, quality differences, or margin padding — and has never commissioned a build before

If three dev proposals landed on your desk this week with wildly different numbers, the price gap almost never comes from one vendor being greedy. It comes from unspecified scope, acceptance criteria written in the vendor's favour, and change-order clauses that let the budget drift once you've signed. This post gives you the 15 questions to put to each shortlisted partner before you commit — the ones that force the hidden assumptions out of the PDF and onto the table.

Context for why this matters: 40% of software projects fail to deliver on original objectives, and the top three causes — unclear requirements (39%), scope creep (33%), and inadequate planning (29%) — are all things a proposal is supposed to pin down. When projects with clear requirements documented before development start are 97% more likely to succeed, the review you do in the next ten days matters more than the vendor you pick.

You are not looking for the cheapest proposal. You are looking for the one where you understand what you are buying.

Before the questions: how to read the budget table itself

Three vendors can price the same brief at vastly different numbers for legitimate reasons: one assumes you have design, another is budgeting a UX designer; one assumes AWS, another assumes you want multi-cloud; one has priced two integrations, another three. Fixed-fee proposals typically embed a 20–30% risk premium to cover unknown technical debt and shifting dependencies, so a fixed-fee bid that looks higher than a time-and-materials bid may actually be the honest one.

Before you ask a single question, line up the three proposals side by side and highlight every assumption each vendor made that the others did not. That diff list is your real agenda for the vendor calls.

The 15 questions, and how to score the answers

1. “For each milestone, what is the written acceptance test I will run before I release payment?”

Why it matters: This is the single clause that decides whether you or the vendor controls payment timing. Without objective acceptance criteria per milestone, the vendor decides when they're done. Vague milestone language is one of the most common sources of payment disputes, and acceptance can quietly default to automatic.

Good answer: “Each milestone has a numbered checklist in the SOW. For Milestone 2, that's: user can sign up with phone OTP in under 8 seconds on a 4G connection, OTP delivery success rate >98% across Etisalat and du, and you can create and log in to three test accounts without engineering support. You sign off within 5 business days or it's deemed accepted.”

Red flag: “We'll demo it and you approve.” Or acceptance criteria that read “the feature works as discussed.”

2. “What exactly triggers a change order, and what is the dollar threshold below which small changes are absorbed?”

Why it matters: If every clarification becomes a change order, your budget leaks weekly. If nothing is a change order, the vendor absorbs everything and starts cutting corners silently.

Good answer: “Anything inside the signed SOW is included. Anything that adds a new user flow, a new integration, or more than ~8 hours of work triggers a written change order with a fresh estimate. We absorb everything under that threshold — typically small copy, UI tweaks, bug fixes.”

Red flag: “We'll handle changes flexibly as we go.” Flexible means undefined, and undefined always resolves in the vendor's favour.

3. “Who owns the code, the repos, the design files, and the AI models or prompts — and when does ownership transfer?”

Why it matters: If ownership transfers only on final payment, the vendor holds leverage over you for the entire build. If AI prompts or fine-tuned models aren't explicitly included, you may own the wrapper and not the brain.

Good answer: “You own all IP from the moment each milestone is paid. Repos are in your GitHub org from day one, we have contributor access. Figma files, prompt libraries, fine-tuned model weights, and any data pipelines are listed in the IP schedule and transfer with milestone payment.”

Red flag: Silence on AI assets. Or “IP transfers on project completion” without defining completion.

4. “Can you walk me through a project where the original estimate was wrong, and what happened to the overage?”

Why it matters: Large software projects run 66% over budget on average. Every vendor has overrun. The question is whether they ate it, split it, or billed it to the client.

Good answer: A specific story with a number. “Vahak-style marketplace build, we under-scoped the dispatcher logic by about three weeks. We ate two weeks, client paid one week at cost. Here's the retrospective doc.”

Red flag: “We hit all our estimates.” Nobody does. This vendor either lies or has never shipped anything hard.

5. “Who are the specific humans on my project, and are they named in the contract?”

Why it matters: Sales shows you the A-team. Delivery sends the B-team. If names and seniority aren't in the SOW, you have no recourse when a senior engineer gets swapped for a junior in month two.

Good answer: Named engineers, their LinkedIn profiles, their allocation percentage, and a written clause that replacements require your written approval and must be equivalent seniority.

Red flag: “We'll assign the right team at kickoff.”

6. “What is your weekly reporting rhythm, and what metrics appear on it?”

Why it matters: Weekly status in prose is marketing. Weekly status with burndown, open bugs by severity, hours by engineer, and risks with owners is engineering.

Good answer: A sample report. Burndown chart, sprint velocity, open P0/P1/P2 bug counts, hours booked vs. budgeted per workstream, top three risks with owner and mitigation.

Red flag: “We'll do weekly check-ins.” Check-ins are not reports.

7. “What does your handover look like if I fire you in month three?”

Why it matters: This question tells you whether the vendor is building for your long-term success or for lock-in. The answer also tells you whether their code is actually inheritable.

Good answer: “Repos are already yours. We maintain a running README with architecture decisions, env variables, and deployment runbooks. On exit we do a two-week knowledge transfer with recorded sessions and a successor onboarding doc. Here's one from a past client.”

Red flag: Hesitation, or “We've never had a client leave mid-project.”

8. “What is your bug SLA post-launch, and what counts as a bug versus a change request?”

Why it matters: The “bug vs. feature” argument is where launch-week relationships die. Define it before you sign.

Good answer: “Anything that doesn't match the acceptance criteria for a shipped milestone is a bug, fixed free for 60 days post-launch. P0 (production down) < 4 hours, P1 < 24 hours, P2 < 5 business days. Anything that matches the spec but you now want different is a change request.”

Red flag: No warranty period, or warranty that excludes “issues arising from use.”

9. “Where will my data and code physically live, and does that comply with UAE data-residency requirements for my sector?”

Why it matters: If you're in fintech, health, or anything touching PII of UAE residents, the answer isn't optional. A dev partner who hasn't thought about this will cost you a replatforming job later. Note that your lawyer, not your dev partner, should sign off on the final compliance read.

Good answer: “Prod data in AWS Bahrain or UAE region, dev environments can be elsewhere but with no production data. Here's our data flow diagram. We recommend you have your legal counsel confirm the setup against your specific licence conditions.”

Red flag: “AWS is compliant everywhere.”

10. “How do you estimate, and can I see the estimate broken down by feature and by role?”

Why it matters: A single number for “build the MVP” is not an estimate, it's a wish. You need the breakdown to compare proposals apples-to-apples and to know what to cut if you need to.

Good answer: A spreadsheet. Features down the left, roles across the top (backend, frontend, mobile, QA, PM, design, DevOps), hours in the cells, assumptions in a notes column.

Red flag: A one-line total, or a breakdown only by phase with no feature-level detail.

11. “What have you deliberately excluded from this proposal that I will need?”

Why it matters: This is the honesty test. Every proposal excludes things — third-party licence costs, SMS gateway fees, Apple developer accounts, security pen-tests, load testing. A vendor who claims nothing is excluded is either lying or hasn't thought about it.

Good answer: A written exclusions list. “Not included: SMS/OTP costs (budget ~AED X/month at your projected volumes), Apple/Google developer accounts, third-party API costs beyond free tiers, external security audit, and load testing beyond 500 concurrent users.”

Red flag: “Everything you need is in there.”

12. “Give me two reference clients at my stage whose projects did not go to plan.”

Why it matters: Reference calls with happy clients tell you nothing. Reference calls with clients where things went sideways tell you how the vendor behaves under pressure. 25–50% of outsourced projects fail due to misalignment and unclear expectations — you want to hear how this vendor handles that moment.

Good answer: Two names, with permission to contact. “Call them. Ask about the pivot in month four.”

Red flag: Only happy references, or “all our clients are happy.”

13. “What is your payment schedule, and is any of it tied to outcomes rather than time?”

Why it matters: 50% upfront with monthly billing is vendor-friendly. Milestone-triggered payments against written acceptance criteria (see question 1) is buyer-friendly. The gap between those two is where founders lose six figures.

Good answer: “10–20% mobilisation, remainder tied to milestone acceptance per the SOW schedule. We don't invoice for a milestone until you've signed it off.”

Red flag: “Monthly retainer regardless of delivery.” That's a staffing contract, not a build contract. Fine if that's what you want, but don't let it masquerade as the latter.

14. “Who writes the technical specification, and does it exist before I sign — or after?”

Why it matters: If the detailed spec is written after you sign, the vendor can expand its interpretation of “MVP” to fit the budget they want. If the spec is a precondition to signing (and is paid for separately as a discovery phase), both of you are committing to the same thing.

Good answer: “We do a paid 2–3 week discovery that produces the spec, wireframes, and the fixed estimate. You can take that spec to any vendor. We'd like to build it, but you aren't locked in.”

Red flag: “We'll figure out the detail during sprint one.”

15. “If I need to pause the project for 60 days because fundraising slips, what happens?”

Why it matters: You are a pre-seed founder in a Dubai ecosystem that saw $2.6B in early-stage funding across H2 2023–2025, and where a new digital startup lands every 13 hours. Timing slips. Your contract should assume it.

Good answer: A written pause clause. “You can pause once for up to 60 days with 14 days notice. We hold the team for 30 days at reduced retainer, after that we release them and resume with a 2-week ramp when you're ready.”

Red flag: No pause clause, or “we'd have to discuss it at the time.”

What a sensible proposal review process looks like

Do not try to ask all 15 in one call. The sequence that works:

1. Written round: email questions 1, 2, 3, 10, and 11 to each vendor. Give them a week. Compare answers in writing before any call.
2. Vendor call: questions 4, 5, 6, 12 — these need voice to read.
3. Reference calls: use the names from question 12. Spend 30 minutes each.
4. Legal/compliance pass: have your lawyer look specifically at the acceptance criteria clause (question 1), IP transfer (question 3), and the data-residency clause (question 9) before you sign anything.

How CodeNicely can help

If you're a pre-seed founder in the UAE weighing offshore and onshore proposals, the engagement that probably rhymes with yours is GimBooks — a YC-backed fintech we built from MVP through scale. What made that work was the discovery phase before the build: a written spec, feature-level estimates, and milestone acceptance criteria that let the founders release funding against evidence rather than optimism. We run the same process out of our Dubai practice for founders raising locally. If you want a second pair of eyes on a proposal you've already received — not a counter-bid, just a read — that's a 30-minute call.

Frequently Asked Questions

How much should a pre-seed MVP proposal in Dubai actually cost?

The honest answer is that the number is driven by four things: feature count, number of third-party integrations, whether you need native mobile or can ship web/PWA first, and whether design is in scope or you're bringing it. A proposal without those four variables stated explicitly isn't an estimate, it's a guess. To turn any range into a quote you need a written spec, a wireframe set, and a clear list of integrations with their API docs. That's the discovery phase — ask any shortlisted partner (including us) to scope that first.

Is a fixed-fee or time-and-materials proposal better for a first-time founder?

Fixed-fee gives you budget certainty but embeds a 20–30% risk premium and incentivises the vendor to argue every change. Time-and-materials is cheaper on paper and more flexible but requires you to manage scope actively, which most first-time founders can't. For a first build, a hybrid works best: fixed-fee for a tightly specced MVP phase, T&M for the iterate-after-launch phase.

What's the single most important clause to negotiate?

The acceptance criteria tied to each milestone payment (question 1 above). Everything else is recoverable. If payment releases on vendor say-so, you have no leverage when quality slips or timelines slide — and vague milestone language is the top source of payment disputes in outsourcing.

Should I use a local Dubai partner or go offshore to India or Eastern Europe?

Depends on what you need beyond code. Local gets you same-timezone standups, in-person workshops, and easier compliance conversations. Offshore gets you a larger talent pool and lower hourly rates. Many Dubai founders run a hybrid — local product and tech lead, offshore delivery team under the same contract. Ask any vendor how they structure that and whether all parties sit under one SOW with one point of accountability.

How long should the proposal review process take?

Plan for two to three weeks from receiving proposals to signing. Rushing this is where founders lose the most money. The vendors worth signing with will respect a thorough review; the ones pushing you to sign this week are telling you something.