10 Questions to Ask Before Signing a Software Contract

The ten questions at a glance

Here is the full list, printable, in the order they usually matter. The sections that follow unpack what good and bad answers look like for each group. Anyone selling custom software development services worth buying can answer all ten in writing within a day — hesitation on any of them is itself an answer.

• 1. Is the price fixed, and precisely what does it include and exclude?
• 2. What triggers extra cost, and who has to approve it before it is incurred?
• 3. What is each payment tied to — a date, or a deliverable I can verify?
• 4. Who owns the code and designs, and at what moment does ownership transfer?
• 5. Where does the code live during the project, and do I have access from week one?
• 6. What third-party services and licences does the build depend on, and who pays for them?
• 7. What are the acceptance criteria, and what happens if a deliverable fails them?
• 8. What does the warranty cover, for how long, and what counts as a bug versus a change?
• 9. How does either side terminate, and what do I walk away with if we stop halfway?
• 10. Who exactly is doing the work, and what happens if that person becomes unavailable?

Money: questions 1–3

A fixed price is only fixed if the scope it covers is written down with equal precision — the number is meaningless without the boundary. Good answers to question 1 include an exclusions list; the absence of one means every ambiguity will be resolved in an invoice. Question 2 then closes the loophole: extra cost should require your written approval before the work happens, not a surprise line item after it. The phrase to insist on is that change requests are quoted and approved in advance.

Question 3 is where hourly and milestone billing quietly diverge. Payments tied to calendar dates pay for time passing; payments tied to deliverables pay for work existing. Insist on the latter, and make each deliverable something you can personally verify — 'booking flow works end to end on the staging site' rather than 'phase two complete'. A deposit at the start is normal and fair; the balance of risk across the remaining payments is what you are negotiating.

Ownership and access: questions 4–6

Question 4 has a precise good answer: all intellectual property in the deliverables assigns to you upon payment, stated in plain words. Be alert to the difference between assignment and a licence — a 'perpetual licence to use the software' means the developer still owns it, and you may not be able to modify it, resell your business cleanly, or hire someone else to extend it. If the developer retains reusable components or pre-existing tools, the contract should name them and grant you a broad licence, while everything written for your project assigns to you.

Questions 5 and 6 make ownership practical rather than theoretical. Code in a repository you own from week one means termination never becomes a hostage negotiation. The third-party inventory matters because your product will depend on accounts and licences — payment processing, hosting, email delivery, LLM APIs — and each should be registered to you, paid by you, and portable with you. A build wired to the developer's own accounts is a lease dressed as a purchase.

Delivery, quality and exit: questions 7–10

Acceptance criteria (question 7) turn 'done' from an opinion into a test. The contract should say what happens on failure — typically the developer fixes at their own cost within a stated window — and should give you a defined review period rather than deeming work accepted the moment it is delivered. Watch for 'deemed acceptance' language with very short windows; five business days is workable, 48 hours is not.

The warranty (question 8) needs three numbers and a definition: how long, response time, and what distinguishes a bug (developer's cost) from a change (yours). A defensible market range for small projects is two weeks to two months — PINCLER's own written warranty runs 14 to 60 days by tier. Questions 9 and 10 cover the endings nobody plans for: you want termination for convenience with payment for work completed and delivery of everything built so far, and you want to know whether the senior person you met is doing the work or subcontracting it to someone you will never speak to.

The clauses to search for by name

Contracts answer these ten questions in specific, findable language. Open the document and search for each term below; where a term is missing entirely, that question is unanswered — which in a dispute means answered against you. This list is what a lawyer will look at first, so checking it yourself makes the legal review shorter and cheaper.

• 'Assignment' / 'intellectual property' — should assign IP to you on payment; beware licence-only language.
• 'Work made for hire' — common in US-style contracts; usually paired with an assignment clause as backup.
• 'Background IP' / 'pre-existing materials' — the developer's reusable tools; fine if named and licensed to you.
• 'Acceptance' / 'deemed accepted' — check the review window and what failure obliges the developer to do.
• 'Warranty' / 'defects' — duration, response time, and the bug-versus-change definition.
• 'Limitation of liability' — usually caps at fees paid; just know the cap exists before you rely on more.
• 'Termination' / 'termination for convenience' — can you leave, on what notice, keeping what?
• 'Auto-renewal' / 'renewal term' — mostly a maintenance-contract trap; diarise the notice window.
• 'Non-solicitation' — restricts hiring their staff; common and fair, but check the duration.
• 'Confidentiality' — should run both ways, covering your business data as well as their methods.

Why the money questions matter: the overrun record

The published numbers explain why questions 1–3 come first. McKinsey's study with the University of Oxford, covering more than 5,400 IT projects, found large projects running 45% over budget and 7% over time on average, delivering 56% less value than predicted — and 17% overran so badly they threatened the company's survival. The Standish Group's CHAOS research tells the same story from another angle: only around 31% of projects succeed outright, while roughly half limp home late or over budget and 19% fail completely.

An open-ended hourly contract converts that industry-wide risk into your personal invoice. Suppose a build is estimated at 300 hours at $50 per hour: $15,000. Apply the 45% average overrun from the McKinsey research and it becomes 435 hours and $21,750 — $6,750 of pure estimate error, borne entirely by you, with no contractual recourse because every hour was 'worked'. A fixed price against a written scope moves that same risk onto the builder, which is the only place the incentive to work efficiently does any good.

This is why every PINCLER project is fixed between $500 and $2,500 before work starts. Across our 79 documented projects — the dataset is published at /research/what-you-can-build — the median build is $1,450 and 13 days, and the number a client pays is the number on the quote, because the contract puts estimate error on our side of the table. Whoever you hire, that is the arrangement worth asking for by name.

A payment schedule you can defend

Question 3 deserves a worked example, because 'tie payments to deliverables' is easy to say and vague to sign. The schedule below shows the shape on a project at our median price of $1,450; the percentages matter more than the dollars, and they scale to any project size. Each trigger is something a non-technical person can verify by sitting at the product — no payment ever depends on taking the builder's word for progress.

Contract questions for AI-assisted builds

Production reality has moved faster than contract templates. Stack Overflow's 2025 Developer Survey found 84% of developers using or planning to use AI tools — and 46% saying they do not trust the accuracy of AI output, up sharply from 31% the year before. Google's DORA research in 2024 similarly reported 75.9% of respondents relying on AI for part of their work while 39% had little or no trust in AI-generated code. None of that is an argument against the tooling; it is an argument for asking, in writing, who reviews machine-written code before it ships and putting a named quality process into question 7's acceptance terms.

Two clauses cover it. First, the quality process: the contract should state that all code, however produced, is reviewed by a senior engineer before release — which is how disciplined AI-assisted studios already work. Second, ownership and licences: AI-generated code should assign to you exactly like everything else in the deliverables, and since Black Duck's OSSRA research has reported that 97% of audited codebases contain open-source components, the licence-compatibility obligation from question 6 does most of the remaining practical work. Two sentences, both cheap to add and awkward to retrofit.

Before you sign

Send the ten questions in writing and keep the answers with the contract — in most jurisdictions the written record shapes how ambiguity gets resolved later, and in every jurisdiction it shapes how honestly the relationship starts. Then have a lawyer read the actual document; an hour of review on a small contract is cheap insurance against every clause above.

We think the fastest way to make a contract safe is to make it short and unambiguous: a fixed price between $500 and $2,500, deliverable-based payments, IP assigned on payment, your repositories from day one, and a written warranty. If you want to see what those answers look like in practice before you sign anything anywhere, our free 30-minute intro call comes with a written quote covering all ten questions — or browse a use case first to see scope, price and timeline stated up front.