How to Evaluate a Dev Shop Quote: The AED 300k Question

Evaluate a dev shop quote by tracing every expensive line from a promised outcome to its assumptions, exclusions, acceptance test, evidence, buyer-owned account, decision owner, and handover proof. If a line says only “admin dashboard — AED 60k” or “AI integration — AED 90k,” you do not have a milestone. You have a label and a price.

For an AED 300k proposal, do not begin by bargaining for ten percent off. Begin by making the work legible. That process may reduce the quote by removing unvalidated scope, duplicated roles, premature infrastructure, and vague contingency. It may also show that the number is justified. The goal is not the lowest bid; it is a build you can inspect, accept, operate, and leave.

What should you ask before comparing agency totals?

First, make every agency quote the same product. One proposal may include product discovery, design, analytics, release engineering, monitoring, app-store submission, and three months of support. Another may price only coding. Comparing their totals is like comparing rent with a mortgage payment and ignoring everything else.

Ask each shop to separate six buckets: discovery and product decisions; user-facing workflows; integrations and data migration; quality, security, performance, and recovery; deployment and operations; and support and handover. Then ask what is explicitly excluded. The exclusion list is often more useful than the feature list because it reveals where later change orders will come from.

Provider-authored guidance points in the same direction, although it is not an independent market standard. WeWeb recommends validating the problem and narrowing the first build to a core workflow. Better Software recommends phased deliverables and working references. Use those as questions, not proof of delivery.

Which line items belong in a serious dev shop quote?

A serious quote describes the system outside the happy-path screens. Read it in this order:

1. Business workflow. Which user completes which job, from start to finish? If the quote lists screens but not the outcome they support, the scope is already drifting.
2. Roles and permissions. Who can view, create, approve, refund, export, delete, or impersonate? “Admin panel” is not a permission model.
3. Integrations and data. Which API, account tier, rate limit, import format, migration, webhook, failure path, and manual fallback are included?
4. Quality and failure handling. Which critical flows receive automated tests? What gets logged and alerted? What is the backup, restore, rollback, and incident path?
5. Delivery. Who owns source control, cloud, domain, analytics, email, app-store, model-provider, and monitoring accounts? Which environments exist, and who can deploy them?
6. Exit. What source history, documentation, credentials, dependency inventory, unresolved-risk register, runbook, and support window arrive at handover?

NIST's Secure Software Development Framework gives producers and purchasers shared vocabulary. It does not certify an agency or prescribe your contract; use it to make responsibilities, evidence, and exceptions explicit.

Use a quote-to-control ledger, not a feature checklist

Copy each material proposal line into this ledger before signing. If the agency cannot complete the row, the scope is not ready for a fixed estimate.

Swipe horizontally to see all columns →

The amounts remain engagement-specific. The ledger does not tell you whether a payment flow should cost AED 20k or AED 80k. It tells you whether two agencies are pricing the same responsibility and whether you will receive evidence that the responsibility was completed.

What looks like padding, and what is legitimate risk?

A legitimate risk allowance names the uncertainty, the investigation that narrows it, the owner, and the rule for unused capacity. Padding stays vague.

• Duplicated management: project manager, delivery manager, account manager, and fractional product lead all billing for the same status loop.
• Premature platform work: multi-region infrastructure, microservices, elaborate data platforms, or custom admin tooling before the first workflow has users.
• Hidden discovery: a fixed-price build whose assumptions say requirements will be clarified after kickoff.
• Unbounded integration risk: “integrate with client systems” without naming APIs, access, data quality, rate limits, or a manual fallback.
• Support sold twice: stabilization inside each milestone plus a separate warranty line that excludes the same defects.

Legitimate cost usually becomes clearer when challenged. The agency can explain which engineer owns it, which failure it prevents, what evidence closes it, and what changes if the requirement is removed. If the only defence is “this is our process,” ask for the buyer outcome that process buys.

Which questions can shrink the quote without creating a worse product?

1. What is the one workflow that proves the business? Defer secondary roles, dashboards, automation, and integrations.
2. Which assumption needs a paid discovery spike? Test the riskiest API, migration, model behaviour, or platform constraint before pricing the full build.
3. What can remain manual? A founder-operated review, import, refund, or exception queue can be safer than premature automation.
4. Which product replaces custom work? Authentication, billing portals, analytics, support, and content management rarely need bespoke version one implementations.
5. What do we own? Fast decisions, test data, vendor accounts, content, and acceptance feedback reduce waiting time and risk premiums.

This is the same discipline behind an AI MVP that survives month two: reduce the product, not the evidence. Cutting tests, account ownership, observability, or handover only defers the bill.

How should milestone acceptance work?

Dates are planning tools; they are weak acceptance criteria. “Backend complete by 30 November” tells a non-technical buyer almost nothing. Replace it with a result you can observe, plus technical evidence an independent reviewer can sample.

Each milestone should end in one written disposition: accepted, conditionally accepted with named exceptions and expiry dates, or rejected against the agreed rule. A demo is evidence, not the decision. A status call is not evidence. The buyer should receive the staging build, test result, deployment record, account access, and exception list before approval.

A buyer-focused acceptance-packet guide from DealDigg similarly separates demonstration, acceptance evidence, handover, and unresolved exceptions. Treat it as practitioner guidance rather than legal advice; have qualified counsel adapt payment and contract language to the jurisdiction and deal.

When is software handover actually complete?

A repository transfer and a documentation folder are inventory, not operational control. The strongest test is deliberately inconvenient: give a successor developer only the delivered package and buyer-owned access. Ask them to set up from a clean environment, run tests, deploy to a fresh non-production environment, complete one core business flow, rotate vendor credentials, and exercise an appropriate rollback or restore path without calling the agency.

Practitioner pages from Bitecode and KUMO make the same distinction: possession of code is weaker than reproducible setup, release, recovery, access control, and successor independence. Product criticality should determine how deep the test goes.

What evidence should you request for AI-assisted code?

Do not argue about what percentage of the code was AI-generated. Ask who reviewed the critical paths, which tools and account tiers were approved, what data could enter them, how public-code or licence matches were handled, which tests protect the money and data paths, and what component or dependency inventory arrives with the release.

Where the delivery pipeline supports it, provenance can strengthen the evidence trail. GitHub artifact attestations can bind an artifact to repository, workflow, organization, environment, commit, and triggering-event claims, while GitHub explicitly warns that an attestation does not prove software is secure. SLSA provenance defines verifiable information about where, when, and how an artifact was produced. Neither replaces code review, tests, licence review, or demonstrated operation.

Who should review the quote if you cannot read code?

You need independent buyer-side judgment, not another builder competing for the project. A short review should test architecture fit, exclusions, integrations, milestone evidence, account control, and whether the exit package can be exercised.

This is narrower than technical due diligence and more applied than my founder-agency overview. The output is a redlined ledger and five decisions: remove, clarify, investigate, accept, or defer.

Frequently asked questions

How do you evaluate a dev shop quote?

Trace every material line item through seven fields: the promised outcome, assumptions and exclusions, an objective acceptance rule, evidence due before approval, the buyer-owned account or asset, the named decision owner, and the handover proof. A feature label and a price are not enough to sign.

What should a software development quote include?

It should identify user flows, integrations, data work, non-functional requirements, delivery environments, tests, security and recovery work, support, handover, assumptions, exclusions, team roles, change control, and acceptance criteria. The quote should also say which accounts and decisions remain under the buyer's control.

When is a software handover actually complete?

Handover is complete when a successor can use only the delivered package and buyer-owned access to set up the product from a clean environment, run the tests, deploy to a fresh non-production environment, complete one core flow, rotate vendor credentials, and exercise an appropriate rollback or restore path without calling the agency.

The bottom line

An AED 300k quote is not expensive or cheap in isolation. It is opaque or legible. Make every promise survive the full chain: scope, assumption, acceptance rule, evidence, buyer control, disposition, and handover. Then compare agencies on the same responsibility instead of comparing totals that describe different products.

The best negotiation is often not “reduce your rate.” It is “remove this unproven workflow, name this exclusion, test this integration first, and show me the evidence that releases payment.” That produces a smaller quote when scope is inflated and a safer quote when the work is real.