A founder sits at her kitchen table at midnight, three vendor proposals open in browser tabs, cursor hovering over a signature field she cannot fully read. Before signing any software build contract, a non-technical founder should be able to answer five questions: who owns the finished code, what counts as a scope change and what it costs, how the vendor proves the software works, what happens if the relationship ends early, and who is checking any of this for her before money moves.
Who owns the code once it’s built
Ownership of the code, not just the finished app, needs to be spelled out in writing before anyone signs. Many contracts assign intellectual property to the client only after final payment clears, which sounds routine until a billing dispute leaves a founder locked out of software she believed she already owned.
This clause is often buried in a “deliverables” section written for lawyers, not founders. It matters because a vendor holding the repository, the domain credentials, or the deployment keys has real power in any disagreement, no matter what the invoice says.
What counts as a change, and what it costs
Every build contract needs a written definition of a “change request” and a rate for pricing it, because vague scope is the most common reason a fixed budget doubles. A founder should get a rate card, or at least an hourly range, for changes before work starts, not after the first surprise invoice.
Founders often assume the first draft of a scope document is final. It rarely is. Requirements shift once real users touch a product, and the question is not whether scope will change but who absorbs the cost when it does.
How the vendor proves the software works
A contract should name what “done” looks like: written acceptance criteria, a testing window, and a specific person authorized to sign off, not just a delivery date on a calendar. Without this, a founder frequently discovers bugs only after paying customers do, with no contractual basis to demand a fix at no extra charge.
Acceptance criteria sound like a formality until the first handoff. A vendor who ships on schedule but against no written standard has technically met the contract, even if the product does not do what the founder actually needed.
What happens if the relationship ends early
Every contract needs a clause describing exactly what the founder receives if the vendor is fired, or quits: source code, documentation, admin credentials, and a defined transition window measured in days, not a vague promise of cooperation. Founders who skip this often learn, mid-crisis, that the vendor is the only party holding a working copy of the codebase.
This is the clause people are least likely to negotiate, because nobody wants to plan for a breakup while signing the marriage papers. It is also the one that costs the most to ignore.
Who reads this before you sign it
Reading a software contract for legal language is not the same as reading it for technical risk, and most attorneys will not catch a vague acceptance clause or a missing ownership date, because that is not the job they were hired to do. Fractional technical leadership exists partly to close that gap, reading a proposed contract the way an engineer would rather than the way a lawyer would.
Kody Doherty works as a fractional CTO, and his site, , describes the kind of pre-signing technical review that catches exactly these five gaps before a founder is locked into them. That review is not a substitute for legal counsel. It is a different lens on the same document, one that asks whether the technical promises in the contract match what the vendor can actually deliver.
None of this requires a founder to become technical overnight. It requires asking five specific questions, in writing, and refusing to sign until the answers are in the contract itself rather than in a verbal assurance from a salesperson who will not be on the project in six months. A contract that cannot answer these five questions clearly is not ready to sign, no matter how good the demo looked.
