IT Software Development Company Red Flags: What Vendor Contracts Hide

Signing a contract with an IT software development company is a moment of high optimism for a CEO. You have seen the beautiful UI mockups, agreed on a budget, and the vendor has promised a blazing-fast launch.

However, the reality of enterprise IT is that optimism does not write code. Contracts do.

When an offshore or nearshore IT project fails, it rarely fails because the developers forgot how to write JavaScript. It fails because the legal and operational framework of the contract was designed to trap the client in a cycle of dependency and hidden costs.

This pattern is common enough that it has a name in procurement circles — “proprietary core lock-in” — and it is the specific mechanism behind a large share of the vendor-switching disputes that end up in legal review: a client who wants to leave discovers the code they paid for was never fully theirs to take.

Before you sign a Master Services Agreement (MSA) with any custom software development firm, you must aggressively audit the contract for these four industry red flags.

Red Flag 1: The “Proprietary Core” Trap (Vendor Lock-in)

This is the most dangerous trap in modern IT contracting.

A vendor will quote you an incredibly low price to build your SaaS application. The catch? The contract states that the application will be built on the vendor’s “proprietary internal framework” to speed up development.

Why it’s a trap: If you ever decide to fire this vendor or bring development in-house, you legally cannot take the core framework with you. Your entire codebase becomes useless outside of their agency. The Fix: Demand a strict Work-For-Hire clause. The contract must explicitly state that 100% of the Intellectual Property (IP), including all custom code, scripts, and architectural configurations, transfers entirely to your company upon payment.

Red Flag 2: Hostage-Style Infrastructure Access

Many agencies will offer to set up and manage the AWS, Azure, or Google Cloud infrastructure for you to “make things easier.”

Why it’s a trap: They create the AWS account under their company name and give you “Guest” or “Read-Only” access. If a dispute arises over an unpaid invoice or a delayed deliverable, they have the power to shut down your live production servers with the click of a button. The Fix: You must create the AWS/Cloud account using your company’s credit card and your corporate email. You then grant the offshore development team IAM (Identity and Access Management) privileges to work within your environment. You must always retain Root Access.

Red Flag 3: Vague “Bug Fixing” vs. “Change Request” Definitions

In a fixed-price contract, the definition of a “bug” versus a “feature change” becomes a battleground.

Why it’s a trap: You test the software and realize the checkout button doesn’t work on Safari browsers. You report it as a bug. The vendor looks at the original 50-page specification PDF, notes that “Safari compatibility” was not explicitly written, and categorizes it as a “Change Request”—charging you an exorbitant hourly rate to fix it. The Fix: Avoid rigid fixed-price contracts for complex, evolving software. Move to an Agile Time & Materials or Dedicated Team model where the team iterates with you continuously. If you must use fixed-price, mandate a clearly defined “Warranty Period” (e.g., 60 days post-launch) where all defects failing the original Acceptance Criteria are fixed at the vendor’s expense.

Red Flag 4: The “Bait and Switch” Seniority

During the sales process, the IT software development company introduces you to their brilliant, English-fluent Senior Systems Architect. You are impressed and sign the contract.

Why it’s a trap: On Day 1 of the project, that Senior Architect disappears. They were just a pre-sales engineer. Your actual project is handed off to a team of junior developers who just graduated from a bootcamp. The Fix: Your contract must include a “Key Personnel” clause. It should stipulate that specific named individuals (e.g., the Lead Architect) will be dedicated to your project for at least the first 3 months, and any replacement must possess equivalent or superior qualifications and be approved by you.

Red Flag 5: The Undisclosed Subcontractor Shuffle

You sign a Master Services Agreement with an IT software development company whose name, website, and sales team all present a single, cohesive organization. What the contract does not mention is that the agency has no intention of writing the code themselves.

Why it’s a trap: Many mid-market “IT software development companies” operate as brokers. They win the deal, then quietly farm the actual build out to a freelance marketplace, a loosely managed subcontractor in a third country, or a rotating cast of gig-economy developers who were never vetted, never signed your NDA, and have no direct contractual obligation to your company at all. If your source code, API keys, or customer data leak, you have no enforceable recourse against the individual who actually touched them, because your contract is only with the broker, and the broker’s agreement with its subcontractor may not even mention your project by name. Worse, if the broker goes bankrupt or simply stops responding, the actual engineers who hold institutional knowledge of your system are not a party you can contact directly.

This is not just a contract-drafting best practice — for any project touching EU personal data, it is a binding legal requirement. GDPR Article 28(2) explicitly prohibits a processor (your vendor) from engaging a sub-processor without your prior written authorization, either specific (naming the sub-processor upfront) or general (subject to advance notice and your right to object to any change). The same data-protection obligations you negotiated with the prime vendor must be passed down to that sub-processor in writing, and the prime vendor remains fully liable to you for the sub-processor’s failures. A vendor who subcontracts your project without following this notification chain is not merely being sloppy — if EU personal data is in scope, they are exposing you to a direct GDPR compliance gap that regulators can act on independently of any commercial dispute.

The Fix: Your MSA must contain either an outright prohibition on subcontracting, or, where subcontracting is a normal part of doing business (as it often is in legitimate offshore delivery), a mandatory disclosure and consent clause that mirrors the Article 28 standard even for non-EU-data engagements. At minimum, demand:

• Named-entity disclosure. The contract lists every legal entity and delivery location that will touch your codebase, updated whenever it changes.
• Flow-down obligations. Every subcontractor is contractually bound by the exact same IP assignment, confidentiality, and security terms as the prime agreement — not a weaker, locally-negotiated version.
• Right to audit. You retain the right to request a current roster of individuals with repository or infrastructure access, and to reject anyone who has not passed background screening.
• No open marketplace sourcing. Explicitly prohibit sourcing engineers for your project through open freelance platforms (Upwork, Fiverr, or similar), where identity verification and confidentiality enforcement are effectively unenforceable.

A legitimate offshore or hybrid vendor, including Manifera, will readily name its delivery entities and staff in the contract, because there is nothing to hide. A vendor who resists this clause is telling you, before the first sprint even starts, that the person actually writing your code is not someone they are willing to be held accountable for.

The SLA Due Diligence Framework: Six Clauses That Actually Protect You

Red flags 1 through 5 describe what can go wrong. This section is the checklist for preventing it: the specific Service Level Agreement (SLA) and contract clauses that should appear in any MSA with an IT software development company, mapped to the risk each one closes.

Why this level of contractual precision matters is not a matter of opinion. The Standish Group’s long-running CHAOS Report — which has tracked large samples of IT projects for over three decades — has consistently found that only around 31% of projects finish on time, on budget, and within the originally agreed scope. That figure has held roughly steady across waterfall, agile, and hybrid delivery models, which tells you the failure mode is not methodology — it is governance. A vague contract cannot fix a governance problem; a specific one at least gives you enforceable recourse when reality diverges from the plan, which the CHAOS data says happens roughly two times out of three.

The last row is worth calling out specifically because it is the clause most CEOs forget to ask for until they are already trying to leave. Even with perfect IP assignment and infrastructure ownership, migrating a codebase away from a vendor who built it takes real handover time — architecture walkthroughs, environment documentation, credential rotation. Without a contractual exit-assistance obligation, a vendor has no incentive to make that transition easy, and “technically we own the code” becomes cold comfort while your new team spends two months reverse-engineering a system that could have been explained to them directly.

How Manifera Protects Clients

We believe that vendor lock-in is unethical. At Manifera, our Dutch headquarters ensures that all contracts are governed by strict European Union IP laws.

When you hire our teams, you own the AWS root keys. You own the GitHub repositories from Day 1. We don’t use proprietary frameworks to trap you; we use open-source standards (React, Node, Laravel) so you always have the freedom to scale. We retain our clients not through legal handcuffs, but through the consistent delivery of high-velocity, European-standard engineering.

FAQs