How to prevent dependency on one supplier or developer

Your core business system runs on a custom application, and exactly one person truly understands it. That developer built it, knows every workaround, and holds the keys — and if they leave, get sick, or simply raise their rates, you have a serious problem. This article gives IT specialists a concrete, actionable plan to identify that dependency, reduce it structurally, and make sure it never sneaks back in.

Why is sole-developer dependency so dangerous?

It rarely feels dangerous — until it is. The developer is responsive, the system works, and there's no obvious reason to change anything. Then one day they go quiet. Or they deliver a quote for a small change that's three times what you expected, because they know you have no alternative. Or they retire and hand over a system with no documentation, no test environment, and no one else who can read the code.

This is called vendor lock-in at the human level — and it's more common in custom software environments than most IT managers want to admit. A survey-level observation from the field: organizations running FileMaker, low-code ERP, or legacy custom databases are especially exposed, because these platforms have smaller developer communities and the original builder often "grew" the system organically over years, carrying all the institutional knowledge in their head.

How do you know if you're already dependent?

Answer these questions honestly:

• Can anyone on your team — or any other developer you could hire tomorrow — open the system and understand its structure without a guided tour?
• Is there written documentation of the data model, business logic, and integration points?
• Do you have access to all credentials: server, database, hosting, licensing, third-party API keys?
• Have you received a source code backup in the last 90 days that you have actually tested?
• Could you get a meaningful quote from a second developer without your current one being involved?

If you answered "no" to two or more of these, you are dependent. Not at risk of becoming dependent — already dependent.

What are the structural causes of this dependency?

Dependency doesn't usually happen because of bad intentions. It happens because:

1. The system grew without governance. What started as a small database became a mission-critical application, but the process of building it was never formalized. No handover documentation, no architecture decisions recorded.
2. Access was never centralized. The developer manages the hosting, holds the FileMaker license, controls the server credentials. Convenience became control.
3. There was no second opinion. Because the developer was trusted and available, there was never a reason to bring in anyone else. Over time, internal knowledge atrophied.
4. Contracts didn't cover IP and escrow. The code was written for you but ownership was never explicitly transferred, or a source code escrow was never set up.

How do you reduce the dependency — step by step?

Step 1: Conduct a dependency audit

Before you can fix the problem, you need to map it. Spend one focused session listing:

• Every system the developer has built or maintains
• Every credential or license they hold on your behalf
• Every integration (APIs, data exports, email connectors) they manage
• What documentation currently exists and where it lives

This audit is uncomfortable but essential. It shows you the actual blast radius if the relationship ends tomorrow.

Step 2: Reclaim all credentials and licenses

This is non-negotiable and should happen before anything else. Your hosting account, your FileMaker license, your domain, your API keys — all of these should be registered to your organization, not to an individual developer or their agency. If they are not, request the transfer immediately. A professional developer will not resist this.

Step 3: Demand — and fund — living documentation

Documentation is not a luxury. Make it a contractual deliverable. At minimum you need:

• A data model overview (what tables exist, what they store, how they relate)
• A list of all scripts, automations, and scheduled processes with a plain-language description of what each does
• A description of every external integration and what breaks if it fails
• A deployment and restore procedure: if the server dies tonight, what are the exact steps to restore service?

If your current developer pushes back on documenting their own work, that resistance is itself a red flag worth taking seriously.

Step 4: Introduce a second developer — now, not when you need one

The worst time to find a backup developer is during a crisis. Introduce a second developer while the system is stable. Give them a small, real task — a report, a minor UI change, a new data export. This does three things: it tests whether the documentation is actually sufficient for an outsider to work from, it builds a relationship before there's urgency, and it sends a quiet signal that you are not captive.

Step 5: Establish a source code escrow or version control handover

If your custom software is business-critical, its source code should be in a version-controlled repository (Git is the standard) that you own. Every release should be committed. If a formal escrow isn't feasible, at minimum agree contractually that you receive a full source export at every major release and that you test it against a restore procedure.

Step 6: Write dependency prevention into future contracts

Once you've reduced your current exposure, lock in the right conditions for future work:

• IP ownership clause: all code written for you is your intellectual property upon payment
• Documentation deliverable: documentation is part of the definition of "done"
• Access policy: all credentials must be held in your organization's name
• Handover clause: at contract end, the developer is obligated to support a structured handover period
• Non-exclusivity: you explicitly retain the right to engage other developers on the same system

What if the developer is also your platform vendor?

Some organizations work with a single firm that both builds and hosts their custom software — a FileMaker partner, for example, who also manages the server and holds the license. This compounds the dependency. In this case, the same principles apply, but you need to be explicit: separate the platform licensing from the development relationship from the hosting relationship. These are three distinct things and can be sourced from three distinct providers if needed.

Asking your vendor to help you reduce dependency on them is an awkward conversation — but a trustworthy vendor will welcome it, because it signals a mature client relationship built on choice rather than captivity.

FAQ

What if I ask for documentation and my developer quotes me a huge amount of time for it? That quote is telling you something important: the system is more complex and less structured than you thought, and no one has been maintaining a knowledge base. Negotiate a phased documentation plan and treat it as essential infrastructure investment, not optional overhead.

Is it realistic to have two developers who both know our system? Yes — and the goal isn't that both know every line of code. The goal is that a competent second developer can pick up the system, orient themselves using documentation, and make a change without a guided tour. That's the bar to aim for.

What's the minimum viable version of this if we have no budget right now? Focus on three things first: reclaim all credentials and licenses, get a tested source code backup, and have one honest conversation with a second developer to find out if your system is legible to an outsider. Those three steps cost almost nothing and reveal everything.

Our developer has been with us for ten years and is completely trustworthy. Do we still need to do this? Yes — because this isn't about trust. It's about continuity. Your developer could fall ill, decide to retire, or simply move on. The risk isn't that they'll act badly; it's that the knowledge leaves with them. Protecting against that is fair to both sides.

A short checklist to get started this week

• List every system and credential your developer currently holds
• Confirm that all licenses and hosting accounts are in your organization's name
• Request a current source code export and test it against a restore procedure
• Ask your developer to provide or update system documentation
• Identify and brief a second developer on a small, real task
• Review your current contract for IP ownership and handover clauses

---

Dependency on a single developer is not a sign that something went wrong — it's a sign that something worked, for a long time, without enough governance around it. The good news is that it's entirely reversible with structured steps. Start with the audit, reclaim your access, and get a second set of eyes on the system before you need them urgently.