Contracts for Custom Development

A good contract protects both the client and the developer. A bad contract creates disputes and prevents the project from succeeding. Take contracts seriously.

Why Contracts Matter

A contract is not a sign of mistrust. It's a shared reference for what both sides agreed to. When questions arise (and they always do), you can point to the contract. Without it, everyone remembers things differently.

For the client: A contract protects you against scope creep, non-delivery, and price surprises. It defines what you'll get and how much it costs.

For the developer: A contract protects you against scope creep (you're paid for what you quoted, not unlimited additions), specifies payment terms (you don't work for free waiting for payment), and clarifies IP ownership (you get credit for your work).

Contract Types

Fixed-Price Contracts

"We will build X for $Y." The client pays a fixed amount regardless of how long it actually takes. This is what most clients want—no budget surprises.

Pros: Budget is predictable for the client. Easy to understand.

Cons: The developer carries the risk. If the estimate is wrong, the developer loses money. This causes developers to quote conservatively (higher prices) or cut corners (lower quality).

When it works: When scope is very well defined and the developer has done similar projects before. For example: "Build an admin dashboard with these 5 specific pages following this design."

When it fails: When scope is ambiguous or novel. The developer estimates low and then spends months trying to fit work into a budget. This creates bad outcomes for everyone.

Time and Materials Contracts

"We will charge you $X per hour (or per developer-day) for the actual work performed." The client pays for what's actually built, not a pre-agreed amount.

Pros: Transparent. You pay for actual work. Changes don't require re-negotiation (you just pay for the extra hours). Flexibility.

Cons: Budget is uncertain. The project might take longer than expected, costing more. Clients dislike this because the final bill is unknown.

When it works: When scope is uncertain or the project will evolve. For example: MVP development where you'll iterate based on feedback. Or when the developer is trusted and the client trusts the estimate.

Sprint-Based Retainer

"You pay $X per month for Y sprints of development." A fixed monthly fee for a predictable amount of work (e.g., 80 hours per month). This is common for ongoing product development or maintenance.

Pros: Predictable cost for both sides. Clear commitment. Good for ongoing relationships.

Cons: If the team is more productive than expected, the client pays the same. If less productive, the developer loses money. Requires mutual trust.

When it works: For ongoing product work, maintenance, or development where you're in a partnership.

Key Contract Clauses

Scope of work: Clearly define what will be built. Reference the requirements document. Include any constraints or assumptions. Specify what happens if scope needs to change (change request process).

Price and payment terms: State the total price (for fixed-price) or hourly/daily rate (for T&M). Specify payment schedule: maybe 30% upfront, 30% at milestone 1, 30% at milestone 2, 10% on delivery. Never accept 100% upfront or 100% on completion. Milestone-based protects both sides.

Timeline: When will the project start? When will it finish? What are the milestones? What happens if the developer is late (usually nothing enforceable, but the clause clarifies expectations). What happens if the client is late providing requirements (usually extends the timeline)?

IP ownership: Who owns the code and documentation after the project is done? Typically: the client owns everything (the most common arrangement). Alternatively: the developer retains ownership and the client gets a license to use it. Be explicit.

Confidentiality and NDA: Both sides agree not to disclose the other's information or the project details without permission.

Change request process: How do you handle requests for features not in the original scope? Usually: document the request, assess effort impact, agree on timeline/cost impact, get approval, proceed.

Warranty and post-launch support: Is there a warranty period where the developer fixes bugs found post-launch? Usually 30-90 days. After that, bugs are paid separately or part of ongoing support.

Termination rights: What happens if either party wants to stop mid-project? Usually: you owe for work done to date, plus wind-down costs. Rarely is there termination without cause, and it usually costs money.

The IP Ownership Clause

Who owns the code after the project is done? This is important. Here's what usually happens:

Client owns the code outright. This is the most common and most fair arrangement. You pay for the development, you own the result. The client can modify it, sell it, whatever. The developer gets credit ("developed by [company]") but no ongoing ownership.

Developer retains ownership, client licenses it. The developer owns the code and the client gets a license to use it. This protects the developer if the client is difficult. The developer can also reuse patterns or libraries across clients. But clients usually dislike this because they depend on the developer's goodwill.

Hybrid: custom code is client's, libraries are developer's. The client owns the custom code written for them. The developer retains ownership of libraries or open-source components used. This is reasonable but requires clarity about what's what.

The clearest arrangement: client owns everything. Period.

Payment Milestones

How should payments be structured? Never accept 100% upfront or 100% on completion. A typical structure for a 4-month, $300k project:

• 30% ($90k) upon signing (covers initial setup and planning)
• 30% ($90k) at end of month 2 (covers half the dev work)
• 30% ($90k) at staging completion / QA start (covers final dev)
• 10% ($30k) upon production launch (payment for launch bugs/fixes)

Milestone-based payments protect both sides. The client doesn't pay for work not done. The developer doesn't work for free waiting for final payment.

Common Contract Mistakes

Vague scope. "Build a web application" is not a scope. "Build a web application with these 5 specific features, defined in the attached requirements document" is. The scope needs to be specific enough that both sides agree on what will be built.

No change request process. Without defining how changes are handled, every request becomes a negotiation. Define it: if it's in scope, it's free. If it's out of scope, we assess impact and renegotiate.

Ambiguous timeline. "As soon as possible" is not a timeline. "Development starts on [date], MVP is delivered by [date], with these milestones in between" is clear.

No payment schedule. "We'll pay after the project is done" means the developer works months without payment. This is unfair. Structure payments in milestones.

Unclear IP ownership. "We assume the client owns the code" is not enough. State explicitly in the contract: "Upon final payment, all code and documentation become the property of [client]."

Consulting on Contracts

For significant projects (over $100k), consider having a lawyer review the contract. A lawyer familiar with software development can catch issues and language that protects you. The legal review costs $500-$2000 and is money well spent for large deals.

For smaller projects, use a template. Many platforms have standard contract templates. The key is having something in writing that both sides agree to.

Never rely on verbal agreements or email exchanges as a contract. Memories fade and people interpret things differently. Write it down.