Questions before you sign a SaaS build

Before you sign a SaaS development company, get seven answers in writing. Who owns the copyright on the day the contract is signed, and which instrument moves it. Which account holds the repository from the first commit. What done means for the first release, as one sentence a user can fail. Which named people will write the code, and which parts an assistant will write. What is excluded. What you keep if you stop before the end. Where customer data sits and who can read it. A signature on a proposal does none of these by itself, and neither does payment. The questions are the contract. The rest of this article is how to tell a warm conversation from a document you can actually use.

This is not the reference call, and it is not the exercise of explaining why one quote is four times the other. Those happen earlier, and they answer different questions: what a firm was like on someone else's bad week, and whether two proposals are pricing the same product. The moment in front of you now is the signature. If a term is not in the paper you are about to sign, it is not a term. A founder who has done the calls and still signs a two-page proposal has spent the diligence and then declined to keep it.

None of what follows is legal advice. Copyright default rules are statute, and a lawyer in your state reads them against your actual draft. The point of knowing the statute before that meeting is so you can see whether the draft does the thing you think payment already did.

Copyright does not move because you paid. For work created on or after 1 January 1978, the U.S. Copyright Office's Circular 30 restates the statute. A "work made for hire" is either a work prepared by an employee within the scope of employment, or a work specially ordered or commissioned that meets every one of four tests. The four, in the Office's own numbering: the work must fall within one of nine listed categories; there must be a written agreement between the party that ordered the work and the individuals who actually created it; that writing must expressly say the work is a work made for hire; and every party must sign. "If a work fails to satisfy any of these requirements, it is not a work made for hire" (U.S. Copyright Office, Circular 30: Works Made for Hire). The nine categories are a contribution to a collective work, a part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, and an atlas. A software product, standing on its own, is not one of those nine names.

Read that against the arrangement you are actually buying. An agency is not your employee. A statement that you are purchasing "all work product" is not, by itself, the express work-made-for-hire sentence Circular 30 requires, and it is not signed by the people who wrote the code unless they are parties to it. When the work is not a work made for hire, copyright starts with the author — the person or company that wrote it — and it moves only by a transfer. Section 204 of the Copyright Act makes a transfer of copyright ownership, other than by operation of law, invalid unless there is an instrument of conveyance, or a note or memorandum of the transfer, in writing and signed by the owner of the rights conveyed or that owner's duly authorized agent (17 U.S.C. § 204). The practical ask is short. The contract assigns the copyright in a writing the owner of those rights will sign, and it says what happens to pre-existing tools the vendor is reusing. You want your product. You do not need to own their deployment scripts from the last ten clients, and a clause that pretends you do is how negotiations stall on the wrong sentence.

The repository is in your account from the first commit. A zip file on the last day is not a repository. History, reviews, and the issue tracker are the record of why the code looks like this, and they are useless if they live in an organisation you lose access to the day the relationship sours. The Digital Services Playbook, on the contracting play, tells government buyers to specify "that software and data generated by third parties remains under our control, and can be reused and released to the public as appropriate and in accordance with the law," and the delivery checklist beside it tells the team to use a source-code version control system and to give the entire project team access to the issue tracker and that system (U.S. Digital Services Playbook, playbook.cio.gov). You are not a federal agency, and you may have no intention of releasing anything to the public. The control point still transfers: the organisation named on the account is yours, the vendor is invited in, and revoking that invitation does not revoke the history.

Ask to see the account before you sign, not a promise that it will be transferred at acceptance. A firm that hesitates is telling you the default in their shop is the other way around. That default is convenient for them and expensive for you, and it is the thing the handover is trying to prevent at the end. It is cheaper to prevent it at the beginning, because a history that was never in your account cannot be handed over later. It can only be exported, partially, by someone who still likes you.

Done is one sentence a user can fail. Not a feature list, and not a phase called launch. One workflow, one kind of user, and a sentence that is false if the workflow does not work: a clinic can check eligibility for one patient and see a yes or a no, without calling anyone. If the vendor cannot write that sentence, they are not scoping a release. They are leaving the acceptance test for the week you are tired. Which judgements you personally have to own, including that sentence, is what a non-technical founder should own. How to cut the list until the sentence can be true inside a bounded build is a different article. Do not let a vendor fold those two conversations into "we'll know it when we see it."

Ask who writes the code, and which parts an assistant writes. The name on the proposal is not always the name in the editor. The 2024 DORA Accelerate State of DevOps report heard from nearly 3,000 working professionals. On the quality of AI-generated code, 87.9% reported some level of trust, and that phrase is easy to misuse: the same paragraph says the degree of trust was generally low, with 39.2% reporting little trust (27.3%) or none (11.9%) (DORA, Accelerate State of DevOps Report 2024). "Some" includes "little." The figure is not a ban on the tools, and it is not a claim that your vendor's code is bad. It is a reason to ask a specific question: which parts of this product will an assistant draft, and what does a person check before it is merged. A vendor who has an answer will describe a review, a test, or an evaluation. A vendor who is offended by the question is relying on the feeling the DORA respondents had already separated from the measurement.

The people question has a second half that has nothing to do with AI. Are the people who scoped this the people who will build it, and do they stay if the individual leaves. You are not owed a particular person's entire career. You are owed a written statement of what happens to the work when that person is no longer on it, because that event is ordinary and the contract is the only place it gets decided in your favour.

Exclusions are part of the price. A low number with a silent exclusion list is not a bargain. It is a change-order schedule with the dates left blank. The comparison between two very different quotes is its own exercise, and you should do it before you are in a room with one vendor and a pen. At signature, the job is narrower: the exclusion list from that exercise is attached, and a change is a written decision with a cost, not a Slack message that felt like agreement. If the draft says out-of-scope work is billed at the vendor's then-current rates, ask what those rates are today and whether they can move without notice. A rate that can change unilaterally is not a cap. It is a blank.

What you keep if you stop at week six. Engagements end early for reasons that are not dramatic: the hypothesis died, the money did, someone got sick. The contract should say what you already own at that moment — the repository, the designs, the accounts, the data — and what you still owe. A clause that conditions delivery of the code on payment of the entire contract, including unperformed months, is how a founder pays twice: once to leave, and again to hire someone who has to reconstruct what was never handed over. Tie delivery to the work performed, not to the work imagined.

Where the data sits is the question your first customer will ask you, and you cannot answer it from a vendor's assurance. Which region, which account, who besides you can read a production record, and what happens to a copy in a vendor's log. Your first security questionnaire is the spreadsheet that arrives after you have a customer. The contract is where you make sure the honest answers exist. If customer data will sit in the vendor's own cloud account "for convenience during the build," convenience is doing a lot of work, and it should have an end date.

There is a version of this meeting you should walk out of. You do not yet have one workflow and one user, and you are signing so that someone else will discover them. That is a research project priced as a build, and the copyright clause will not save it. When an AI-coded MVP needs an engineering partner is the earlier decision, about whether you are past the point of prompting alone. If you are not, these seven questions are premature, and a two-week AI readiness assessment is the wrong purchase for the same reason: it assumes there is a system to assess. Spend the signature on a product that already has a sentence.

When the sentence exists, the firm you want can answer the seven without a follow-up deck. We do not publish a ranking of who that is, and a page that did would be advertising. The criteria for judging a top SaaS development company are public, and they include tests we would fail if we skipped them, which is the point of writing tests down. What the work looks like when the account really is the customer's — subscription billing, role-based access, and an admin-trained assistant in one workspace, with the permission model and the assistant constraining each other — is a multi-tenant agency operating system we built. Nothing in that description is a headcount or a duration. The shape is the point: the repository and the customer data were never a favour to be delivered at the end.

Take the seven into the meeting on one page, and leave with the page initialled or with no signature. Copyright assignment, signed by the owner of the rights. Repository in your organisation before the first commit. One acceptance sentence. Named people, and a straight answer on assistant-written code. Exclusions attached. What you keep if you stop. Where the data sits. A startup software development company that treats the page as ordinary is showing you how the engagement will feel in month three. One that treats it as a lack of trust is telling you the defaults run the other way, and the defaults are what you will be living with after the call.