15+ Questions to Ask Before Signing a Web App Design Contract

Key takeaways

• About 35% of outsourced software projects hit scope creep, with overruns averaging 20-30% of the original budget.
• If the contract doesn't transfer IP and source files on final payment in writing, you don't own your product.
• Milestones tied to reviewable deliverables (not calendar dates alone) protect both sides.
• Kill clauses, change-request rates, and a defined warranty period are the three lines most contracts get wrong.
• Use the 17-question checklist below before you sign anything.

A web app design contract decides whether your project ships on budget or turns into a 14-month argument. Most founders skim it and then learn that "two rounds of revisions" meant two per screen, the Figma file isn't theirs, and the kill fee is 60% of the remaining quote. That's a buyer who didn't ask the right questions.

This is the checklist we wish every client had during scoping calls with our web application development team. It covers what breaks contracts in 2026: AI-code ownership, vague revisions, payment splits that punish late approvals, and warranties that exclude the things that break first.

Why this checklist exists

PMI reports 52% of projects suffer scope creep; the Standish CHAOS data puts software and IT above 70%. For outsourced web projects, the average cost overrun is near 27%. On a $40,000 build that's roughly $11,000 of unplanned spend, billed at premium hourly rates because the contract didn't price change orders. Our pricing page is a useful baseline before you negotiate.

The questions sit in seven buckets: scope, IP, source code, milestones, change requests, post-launch support, and termination. If a vendor pushes back on more than two or three, that's your answer. For the hiring side of the same problem, see hiring a design team without regret.

Scope: what the contract says you're buying

"Design the web app" can mean a four-screen dashboard or a SaaS console with 60 states. Get specific.

Question 1. Which screens, states, and breakpoints are in scope? The contract should name every screen (login, empty, error, settings, billing), the breakpoints, and whether dark mode is a separate variant. For complex builds like a multi-tenant SaaS product, demand a screen inventory as an exhibit. "Approximately 20 screens" is where billing fights live.

Question 2. What's the exact deliverable list? User flows, sitemap, low-fi wireframes, hi-fi mockups, clickable prototype, design system, developer handoff, and a written style guide are seven separate things. If it isn't named, assume you're not getting it. Our team treats handoff specs the way we treat shipping code on a website development project: a deliverable with an acceptance test.

Question 3. How many revision rounds, and what counts as one round? "Two rounds" must define whether a round is the entire batch consolidated into a single feedback document, or two separate Loom comments from three stakeholders. The first is reasonable. The second is a trap.

Question 4. Does scope include responsive QA on real devices? Designing in Figma is not the same as confirming the layout holds on a five-year-old Android. Check that the web design and front-end teams agree on the device list.

Intellectual property: who owns what, and when

Founders skip this section; lawyers earn their fees on it. The 2026 best practice is a present-tense assignment clause plus work-made-for-hire language, with explicit treatment of pre-existing IP and AI output.

Question 5. When does IP transfer? Reasonable contracts trigger transfer on final payment of each milestone or the full project. Fine, if it's written. "Transfers upon project completion" without defining completion is not.

Question 6. What about pre-existing IP and third-party components? If the agency uses an internal component library, an open-source UI kit, or a paid Figma plugin, the contract should disclose it and grant you a perpetual licence. Otherwise you're renting your own product.

Question 7. Who owns AI-generated code and design? If the agency uses Cursor, v0, Claude, or Midjourney, the contract should state that all AI output is assigned to you and that the vendor warrants it doesn't violate any tool's terms. Our team uses AI across the pipeline, including the workflows in our breakdown of Claude Opus 4.8 for business, and we put AI ownership in writing. Same rule applies to branding work with generated logos or copy.

Source code, design files, and the handoff bundle

Owning IP is meaningless if you don't get the files. Many contracts grant ownership but never specify handoff format.

Question 8. What files do I receive at handoff? The minimum bundle: the full Figma file (not view-only), exported design tokens, source images and icons in editable format, the developer-ready spec, and prototype links. If the agency also codes the build, add the Git repo, README, environment template, and deployment runbook.

Question 9. Where is the code hosted, and how do I get access? The contract should name the Git provider, state when you get repo access (day one, not at handoff), and confirm you keep access after the engagement ends. This matters more under a staff augmentation arrangement, where developers rotate through.

Question 10. Are there code dependencies on the vendor's accounts? If the build uses the vendor's Vercel, Supabase, or Stripe Connect, you need a written migration plan and transfer window. Otherwise "you own the code" but the database lives in someone else's account.

Milestones and payment structure

The 2026 norm is 25-30% upfront, then progress payments tied to approved deliverables, with the final 10-20% on launch. Anything that asks for 50% upfront and 50% on "completion" is a cash-flow contract, not a milestone contract. For comparable ranges across app categories, see our breakdown of mobile app design cost.

Question 11. Are milestones tied to dates or to approved deliverables? Tie them to deliverables, with target dates as guidance. A milestone that triggers payment on a date regardless of approval gives the vendor zero incentive to ship on quality.

Question 12. What's the approval window, and what happens if I miss it? A 5-7 business day review is reasonable. The contract should add deemed-acceptance language after written reminder, which protects the vendor from indefinite stalls and protects you from being billed for work you haven't seen.

Change requests: the line item that prevents fights

Every project changes. The contract's job is to make that change boring and predictable, not a renegotiation.

Question 13. What's the hourly rate for out-of-scope work, in writing? Get the number. "TBD" means whatever the vendor decides on the day. A defined blended rate (designer plus PM) avoids surprises. Compare to 2026 numbers in our guide to affordable custom website development.

Question 14. What's the change-order process, and who approves? A real process: client emails request, vendor quotes within 3 business days, client signs the change order, work begins. Naming a single approver on each side prevents the "but Sarah said yes" problem. For first-time founders this separates controlled spend from runaway, a dynamic we cover in our MVP vs full-product strategy.

Post-launch support, warranty, and SLAs

The cheapest moment to fix a bug is during the warranty window. After that, you're paying emergency rates.

Question 15. What's the warranty period, what's covered, what's excluded? The 2026 standard is 30-90 days post-launch, covering bugs in delivered scope. Exclude in writing new features, third-party API breakages, and changes you make yourself. Vague warranties cause more disputes than no warranty.

Question 16. What are the ongoing support options and rates? Three common shapes: pay-as-you-go hourly, monthly retainer with rollover, or an SLA-backed contract with response-time guarantees. For revenue products like an ecommerce build or a fintech web app, an SLA is non-negotiable.

Termination, kill fees, and the exit ramp

You may never use this section, and that's the point. Knowing the exit terms before you need them is the difference between a clean break and a lawsuit. Founders shipping a first MVP build should be particularly careful here, because pivots are likely and you want freedom to move.

Question 17. What's the kill clause on both sides? A fair one lets either party terminate with written notice (usually 14-30 days), pays the vendor for work completed and accepted, and transfers all in-progress IP and files to the client on settlement of the final invoice. Asymmetric kill fees (where you pay a penalty but the vendor walks free) are a red flag, as is any clause tying your ability to terminate to "vendor's reasonable opinion".

Bonus question 18. What if the vendor folds or the lead designer leaves? Even a small project benefits from a clause requiring delivery of all current files and credentials within 10 business days.

The 17-point pre-signature checklist

Print this. Take it to the signing call. If any answer is "we'll figure that out later", get it in writing first. Pair it with our full services overview so each line item maps to a deliverable you need.

What a strong contract looks like in practice

The strongest contracts we've signed share four traits. They name the project manager and lead designer with a substitution-notice clause. They include an exhibit listing every screen and deliverable. They tie 70-80% of payments to approved milestones. And they put warranty and kill terms on page one.

If you're picking between vendors, our round-up of strong web application examples shows the polish to expect. Our web app redesign checklist overlaps when you inherit an old codebase, and founders evaluating cross-platform builds should run this against web and mobile vendors both.

Before you sign, confirm

• Every screen, breakpoint, and deliverable is listed in an exhibit you can point at.
• IP, source files, AI-generated output, and third-party assets transfer to you in writing.
• Milestones are tied to approved deliverables, with payment percentages summing to 100%.
• Change-order rate and process are defined before you need them.
• Warranty, ongoing support, and a symmetric kill clause are on page one.

FAQ

Is a web app design contract different from a development contract?

They often live in one document but should have separate scope, deliverable, and warranty sections. Design covers user flows, wireframes, mockups, prototypes, and the design system. Development covers code, infrastructure, QA, and deployment. If your vendor handles both, itemise each side so you can measure progress and payments against the right milestones.

How much should I pay upfront?

The 2026 norm is 25-30%. Above 40% is unusual under $100,000 and signals the vendor may be cash-flow constrained. The rest splits across milestones tied to approved deliverables, with a final 10-15% held back until launch.

What's the fair length for a warranty period?

Thirty to ninety days is standard. Anything less is light; anything more is rare outside enterprise contracts. The length matters less than what's covered: bugs in delivered scope, yes; new feature requests, no; breakages caused by third-party API changes, almost always no. Get those boundaries in writing.

Can I demand source code if the contract doesn't mention it?

Practically you're in a weak position. Without an explicit IP assignment clause and a defined source-code handoff, you may own the right to use the deliverables without owning the files. That's why source code, repo access, and file format are three separate checklist questions.

Are kill clauses necessary on small projects?

Yes, especially on small projects. The smaller the engagement, the more likely either side will want out. A two-sentence kill clause with a 14-day notice period and a clean handover prevents weeks of awkward emails and forces both sides to take the work seriously from week one.

What if the vendor refuses to negotiate these terms?

Walk. A vendor who won't define revision rounds, name an IP transfer trigger, or specify a change-order rate is telling you how the project will run. Plenty of agencies will engage with this checklist line by line. Reach out via our contact page or browse the portfolio.

If you'd rather walk this checklist on a real contract draft, our team does that on every web app engagement. Reach out through contact-us for a review, or compare engagement models on the pricing page.