Caira can review your contract in 3 clicks:

• Get suggested changes and comments added directly to your file

• Generate an email summary to send to the other party

It takes less than 30 seconds to sign up for a free trial. No credit card required: Start your free trial

"It Works on My Machine": Why Web Developers Need Better Contracts

The web development world is plagued by the "Gap of Expectation."

You deliver code that meets the spec. The client opens it on an iPhone 6 from 2014 and screams "It's broken!"

You build the CMS they asked for. They call you six months later demanding you fix a bug caused by a plugin they installed.

Development is logical. Clients are emotional. Your contract is the only bridge between the two. Without it, you are signing up for lifetime unpaid tech support.

Here are the legal bugs you need to patch in your Terms of Business.

1. The "Browser Compatibility" Black Hole

The Scenario: You build a sleek React site. It flies on Chrome and Safari. The client's CEO opens it on Internet Explorer 11 at the office. The grid layout breaks. They withhold payment until "it works on everything."

The Legal Reality:

"Works on everything" is technically impossible. Without a specific list, a court might interpret "functional website" as "working on standard business tools," which could include older browsers.

The Fix:

A Supported Browsers Clause.

Be specific. "The Website is designed to function on the latest two versions of Chrome, Safari, Firefox, and Edge. Compliance with legacy browsers (e.g., IE11) is excluded unless expressly agreed in the Specification."

2. Acceptance Testing (The "Launch" Trigger)

The Scenario: You finish the site. You send the link. "Let me know what you think."

Silence for 3 weeks.

Then: "Can we change the font?"

Then silence for 2 weeks.

Then: "Actually, can we move the logo?"

You are 3 months past the deadline and haven't been paid the final 50%.

The Legal Reality:

Without a defined "Acceptance Period," the project is in zombie mode. It's neither finished nor unfinished.

The Fix:

A "Deemed Acceptance" Clause.

"The Client has 7 days from delivery to test the software. If no specific 'Error' (defined as a crash/critical failure) is reported in writing within 7 days, the software is Deemed Accepted and the final balance is due."

This forces them to check it, or pay you.

3. Scope Creep ("Just One Small Change")

The Scenario: You quote for 5 pages. Most way through, the client sends over the copy. It's 12 pages. "I just split the About page up, it's not a big deal, right?"

It is a big deal. It's navigation logic, mobile menu impacts, and content entry time.

The Fix:

Stop quoting for "A Website." Quote for "A Scope of Work."

• Strict Deliverables: "5 x Static Pages. 1 x Contact Form."

The Variation Clause: "Any specific requests outside this Scope will be charged at our standard hourly rate of £[X]. Development will pause until the Vairation is approved."*

4. Who Owns the Code? (IP Rights)

The Scenario: You use your standard "Starter Theme" or a library of helper functions you wrote years ago. The client falls out with you. They demand "Full Copyright Assignment" of all code.

If you assign everything, you legally can't use your own starter theme for the next client. You sold the "tools," not just the "house."

The Fix:

Distinguish between "Bespoke Code" and "Background IP."

"The Developer assigns Copyright in the bespoke design and text layout to the Client upon full payment."*

"The Developer retains ownership of all 'Background IP' (reusable libraries/frameworks) and grants the Client a perpetual, non-exclusive licence to use them for this website."*

5. "Lifetime" Bug Fixing

The Scenario: The site launches. Two years later, WordPress updates. The site breaks. The client calls: "You built it, you fix it."

The Fix:

A Warranty Period.

"We provide a 30-day Warranty period after launch to fix bugs present at launch. Any issues arising after 30 days, or caused by third-party updates (plugins/browser changes), are billable maintenance."

Why Contract Review is Your Documentation

You comment your code. You should comment your business relationship.

AI contract review parses your dev agreement. It checks if you've accidentally promised "fitness for purpose" (a high legal bar) instead of "reasonable skill and care." It ensures your "Acceptance" flow is watertight. It helps you ship the project and get paid, without the legacy debt.

Disclaimer: The information in this article is for general guidance only and is not intended as professional legal, financial, tax, or medical advice.