A Contract on One Page: Why It's a Recipe for Disaster
In the IT world, there's a dangerous illusion that contracts are bureaucracy and that "we trust each other." Over years of practice, we've seen where this trust leads — and it usually doesn't end well. Here are stories that taught us the most valuable lesson: a good contract protects both sides.
"Build an App" — and That's the Whole Contract
We took over a project from a client who was in a legal dispute with their previous contractor. When we asked about the contract, they showed us a one-page document. The entire text read approximately:
"The contractor will create a web application according to the client's requirements. Price: 8,000 EUR. Deadline: 3 months."
That was everything. No specification. No description of functionality. No acceptance criteria. No milestones. No provisions for requirement changes.
What happened? The client wanted an e-shop with advanced CRM, a loyalty program, and warehouse integration. The contractor delivered a basic e-shop with static pages. Both had a point — because the contract said nothing specific. The lawsuit lasted longer than the original project and cost more than the application itself.
Gentleman's Agreement and Goldfish Memory
Another popular scenario: the client and contractor discuss everything in a meeting, shake hands, and get to work. No contract, no meeting minutes, no emails confirming what was agreed.
We worked with a company where they agreed on mobile app development this way. They talked for two hours in a meeting. The contractor started working. After two months, the client said: "Where's the integration with our accounting system? We discussed that." The contractor replied: "No, that wasn't part of the agreement." The client insisted it was. The contractor insisted it wasn't.
Who was right? Nobody knows. Because there was no document to reference. Human memory is unreliable, especially when money and deadlines are involved. What two people remember from the same meeting can differ dramatically.
The result? Three months of arguments, a damaged relationship, and an application that was eventually rebuilt by someone else (us).
The Contractor Who Vanished Mid-Project
This story is unfortunately more common than you'd think. A company hired a freelancer to develop a web application. They paid a 50% deposit — roughly four thousand euros. The freelancer delivered a first version that more or less worked. Then they stopped responding to emails. Phone went unanswered. LinkedIn status changed to "Open to Work" in a different country.
The contract? It existed, but contained no provisions for what happens if the project isn't completed. No penalties. No milestones with partial payments. No escrow. The deposit was gone, and the company was left with unfinished code they didn't even have repository access to.
When we finally obtained the code (through the hosting provider), we discovered that half the functionality was hardwired to the freelancer's personal accounts — their AWS, their Firebase, their API keys. Decoupling from their infrastructure took longer than the entire original development.
Who Actually Owns the Code?
The question of intellectual property is one of the most critical — and most frequently overlooked — aspects of IT contracts.
A company came to us that had been paying a monthly retainer to a contractor for five years for maintaining and developing their web application. When they decided to switch to a different contractor, the original company said: "Sure, but the code is ours. You were paying for a service, not for the code."
And they were right. The contract didn't contain a single word about transferring copyright. Under most jurisdictions' copyright law, the work belongs to the author — the contractor — unless the contract says otherwise. The company had been paying for five years for a product that legally wasn't theirs.
This is a situation where investing in a lawyer who understands IT pays off. Licensing agreements, transfer of property rights, right to source code — all of this must be explicitly stated in the contract.
Changes Without Amendments? Bad Idea
Software changes during development. That's normal and healthy. But if you don't have a process for managing changes, you'll end up in chaos.
We saw a project where the client continuously added requirements — "just this little thing" and "this will be quick" — without any formal change to the contract or budget. After six months, the project was twice the original scope, but the budget remained the same. The contractor eventually refused to continue, the client refused to pay more. Both were frustrated and the project ended unfinished.
A simple change management process would have prevented this: change request → impact estimate on time and cost → approval → contract amendment. It seems bureaucratic, but it saves months of arguments.
- ✗Vague descriptions like "will create a web application"
- ✗One-time 50% deposit with no milestones
- ✗Handshake deal with no written documentation
- ✗No provisions for code ownership
- ✗Missing process for requirement changes
- ✗No penalties or protection for non-completion
- ✓Detailed specification of features as an appendix
- ✓Timeline with milestones and partial payments
- ✓Change management process
- ✓Intellectual property and source code provisions
- ✓Warranty terms and post-delivery SLA
- ✓Termination and project handover provisions
What a Good Software Development Contract Should Include
After all these horror stories, let's get practical. A good custom development contract should contain at minimum:
Specification of the deliverable. What exactly is being delivered. Not "an app," but a specific list of features, technical requirements, and acceptance criteria. Ideally as a contract appendix.
Timeline and milestones. Project breakdown into phases with specific deadlines and deliverables for each phase.
Payment terms tied to milestones. Payments linked to completion and acceptance of phases, not a single upfront deposit.
Change management process. How changes to the original specification are handled — procedure, approval, impact on price and timeline.
Intellectual property. Who owns the code, design, documentation. When do rights transfer — upon delivery, upon payment, progressively?
Source code access. Where the code is stored, who has access, what happens to the code when the collaboration ends.
Warranty terms. What happens after delivery — warranty period, bug fixes, support.
Termination provisions. What happens if either party wants to end the collaboration early. What are each party's obligations.
Confidentiality and data protection. Especially important when the contractor works with sensitive client data.
Always have a software development contract reviewed by a lawyer who understands IT. An investment of a few hundred dollars in legal review can save you from disputes costing tens of thousands. Pay special attention to intellectual property clauses, source code access, and the change management process.
A Contract Protects the Contractor Too
An important point: a good contract doesn't just protect the client. It protects the contractor too. Without a clear specification, the contractor can't prove they delivered what was agreed. Without a change management process, they can't refuse endless scope expansion. Without payment milestones, they have no assurance they'll be paid for their work.
We have experience from both sides — and we know that a well-written contract is the foundation of a healthy business relationship.
The Lesson
Contracts aren't a sign of distrust. They're a sign of professionalism. A good contract ensures both parties have the same expectations and provides a framework for resolving problems that will inevitably arise.
Moral of the story: A one-page contract is an invitation to disaster. Invest time and money into a proper contract at the beginning — it's a fraction of what a dispute will cost you at the end. And if someone tells you "we don't need a contract, we trust each other" — that's exactly why you need one.
