[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fU3cY2vQF6JYgWmDur5xLsu8s904wlUCwMUBl0QDIYXE":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":25,"hasDownload":26,"fileName":27,"youtubeId":28,"domainCrumb":29,"clusterCrumb":32},"357","863D655B-E72F-D74D-8EDA-F5611F0830CE","8F2761C8-348C-C649-BC16-18822CE2D198","C55A9339-9E81-E64E-845A-DC9342ED468A","article","how-to-prevent-critical-knowledge-from-remaining-with-one-developer","How to prevent critical knowledge from remaining with one developer","What happens when the one person who understands your custom software leaves — and how to make sure that never becomes a crisis.","Your ERP runs on a FileMaker system that one developer built five years ago. He knows every script, every relationship, every weird workaround — and nobody else does. Now he's on holiday, or he's handed in his notice, or he's simply unreachable for two days, and suddenly a broken invoice script is a business emergency instead of a ten-minute fix.\n\nThis is one of the most common — and most avoidable — risks in custom software. It has nothing to do with the platform being fragile and everything to do with how the knowledge around it was (or wasn't) captured. This article walks through why it happens, how to spot it before it becomes a crisis, and what a realistic knowledge-transfer setup looks like.\n\n## Why does critical software knowledge end up with just one person?\n\nIt's rarely a deliberate choice. It happens gradually, for very ordinary reasons:\n\n- A solo developer or a small internal team builds the system iteratively, adding features as the business asks for them, with no time budgeted for documentation.\n- The person who understands the system best is also the busiest person, so nobody wants to \"waste their time\" writing things down.\n- The software works well, so there's no forcing function — nothing breaks, so nobody asks how it works until it does.\n- Freelance or contract developers are used for speed, and the relationship ends before proper handover happens.\n\nThe result is what's often called **tribal knowledge**: the logic of the system lives in one person's head, not in any document, diagram, or comment that a second person could pick up.\n\n## What does this actually cost a business?\n\nThe risk is concrete, not theoretical. A few real-world scenarios:\n\n- A FileMaker developer leaves the company. Three months later, a change in tax regulations requires an update to the invoicing module. Nobody can find where the tax calculation actually happens in the script, because it's buried inside a poorly named custom function with no comments.\n- A key developer is sick for two weeks during a product launch. A field in the order form needs a new validation rule, but nobody else on the team knows the naming convention used for scripts, so the change either doesn't happen or gets done wrong and breaks something else.\n- A company wants to connect its FileMaker solution to a new webshop via an API integration. The integration partner asks for a data model overview — and it doesn't exist. Two weeks of the project timeline disappear into reverse-engineering the database structure that already existed.\n\n\nIn every case, the software itself was fine. The knowledge around it was the single point of failure.\n\n## How do you know if your business already has this risk?\n\nRun through this checklist honestly:\n\n- [ ] Can you name, right now, who besides the original developer could open the solution and make a safe change to it?\n- [ ] Is there a written (or recorded) explanation of the overall data model — tables, relationships, and why they're structured that way?\n- [ ] Are scripts and custom functions named and commented well enough that someone unfamiliar with them could guess their purpose?\n- [ ] Is there a change log or version history showing what changed, when, and why?\n- [ ] Do you know where API keys, server credentials, and integration settings are stored — and is that list up to date?\n- [ ] If your current developer left tomorrow, could a new developer get productive within a week, or would they need a month just to understand the system?\n\nIf more than two of these make you uneasy, the risk is already live in your organization — it just hasn't cost you anything yet.\n\n[[IMAGE:left|one head icon holding all knowledge, versus knowledge spread across a team and documents]]\n\n## What does a good knowledge-transfer setup actually look like?\n\nThis isn't about forcing developers to write a 200-page manual nobody reads. It's about making the essential knowledge retrievable by someone who isn't the original author.\n\n### 1. Document the data model, not just the features\nA feature list tells you what the system does. A data model tells you *why* it's built that way — which is what a new developer actually needs. A simple entity-relationship diagram with notes on business logic (\"a Job can have multiple Invoices, but only one active Contract\") is worth more than pages of screenshots.\n\n### 2. Use naming conventions and comments as a rule, not a favor\nA script called `Process_Order_v3_FINAL_fixed` tells the next person nothing. A script called `Order: Calculate shipping cost (based on weight tier)` tells them almost everything. This costs seconds during development and saves hours during handover.\n\n### 3. Keep a living change log\nEvery non-trivial change — a new field, a changed calculation, a new integration — gets one line in a log: what changed, why, and who approved it. Tools like FileMaker's built-in Script Debugger and version comments help, but the discipline matters more than the tool.\n\n### 4. Separate business logic from tribal shortcuts\nMany long-running FileMaker systems accumulate one-off workarounds (\"if this field is empty, that means the record is archived\"). These undocumented conventions are exactly what strands with one developer. Whenever one is found, either formalize it as a real, documented field\u002Fstatus, or write it down explicitly.\n\n### 5. Build with modern, standards-based tools where possible\nThis is where tooling choices genuinely matter, not because one platform is inherently better, but because some approaches leave a clearer paper trail than others. For example:\n\n- **FmBetterForms** generates web-standard, responsive layouts inside FileMaker using a visual, structured approach rather than pixel-pushed custom layouts — which means a new developer can inspect the structure logically instead of reverse-engineering someone else's layout decisions.\n- **AI-assisted tools like Klai** (built specifically for the FileMaker ecosystem) can help a new developer or IT manager ask plain-language questions about an existing solution — \"what does this script do\" or \"where is the shipping cost calculated\" — and get a structured answer, effectively acting as a second-opinion documentation layer even when written docs are thin. This doesn't replace human documentation, but it dramatically lowers the cost of picking up an undocumented system.\n\n\n### 6. Cross-train deliberately, not accidentally\nEven a two-hour walkthrough every quarter, where the primary developer explains a recent change to a second team member or an outside partner, builds redundancy over time. It doesn't need to be a formal process — it needs to actually happen on a schedule.\n\n## What should you do if you're already in this situation?\n\nIf there's already a system with a single point of knowledge failure, don't panic-document everything at once — that usually stalls. Instead:\n\n1. Identify the two or three most business-critical processes in the system (usually: invoicing, order flow, and whatever touches money or compliance).\n2. Have the current developer walk through those specific processes first, recorded and written up.\n3. Get an outside developer or partner to do a short structural review — an independent \"what would I need to know to safely maintain this\" audit — even if you don't plan to switch providers. It surfaces gaps the original developer won't think to mention, precisely because they're second nature to them.\n4. Prioritize documenting anything tied to compliance, financial calculations, or external integrations first — these carry the highest cost if misunderstood.\n\n## FAQ\n\n**Does using FileMaker make this risk worse than other platforms?**\nNo — the risk is about process, not platform. FileMaker actually makes documentation easier than many alternatives, since the data model, scripts, and layouts are visible and inspectable in one file rather than spread across a codebase. The risk shows up wherever a system was built quickly by one person without a documentation habit — that happens with custom .NET apps, Excel-based systems, and low-code platforms just as often.\n\n**Should we insist every developer document everything before it ships?**\nInsisting on perfect documentation up front usually backfires — it slows delivery and gets skipped under deadline pressure. A lighter, consistent habit (naming conventions, a short change log, documenting the data model once and updating it) sustains itself much better than an ambitious policy nobody follows after month one.\n\n**Is AI a real solution here, or just a workaround?**\nAI tools that can read and explain an existing solution (like Klai for FileMaker) are genuinely useful as a safety net and a faster onboarding path — but they work best on top of at least minimal structure and naming discipline, not as a replacement for it. Think of it as a translator, not a substitute for the original source being reasonably organized.\n\n**How do we know if our current developer relationship carries this risk?**\nAsk directly: \"If you were unavailable for a month, what would break, and who could fix it?\" A confident, specific answer is a good sign. A vague answer, or one that only involves that same developer, is the signal to start building redundancy now.\n\nThis kind of risk rarely announces itself in advance — it just quietly determines how expensive your next change, integration, or emergency fix turns out to be. Loggix regularly steps into exactly this situation: reviewing an existing FileMaker solution, documenting its real structure, and rebuilding the fragile parts into something a team — not just one person — can safely maintain. Whether that means a structural audit, a tailored FileMaker or web application, an API integration between existing systems, or adding AI tooling like Klai to make an existing solution easier to understand, the starting point is the same conversation: what would happen to this system if the person who built it wasn't available tomorrow?","\u003Cp>Your ERP runs on a FileMaker system that one developer built five years ago. He knows every script, every relationship, every weird workaround — and nobody else does. Now he's on holiday, or he's handed in his notice, or he's simply unreachable for two days, and suddenly a broken invoice script is a business emergency instead of a ten-minute fix.\u003C\u002Fp>\n\u003Cp>This is one of the most common — and most avoidable — risks in custom software. It has nothing to do with the platform being fragile and everything to do with how the knowledge around it was (or wasn't) captured. This article walks through why it happens, how to spot it before it becomes a crisis, and what a realistic knowledge-transfer setup looks like.\u003C\u002Fp>\n\u003Ch2>Why does critical software knowledge end up with just one person?\u003C\u002Fh2>\n\u003Cp>It's rarely a deliberate choice. It happens gradually, for very ordinary reasons:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>A solo developer or a small internal team builds the system iteratively, adding features as the business asks for them, with no time budgeted for documentation.\u003C\u002Fli>\n\u003Cli>The person who understands the system best is also the busiest person, so nobody wants to "waste their time" writing things down.\u003C\u002Fli>\n\u003Cli>The software works well, so there's no forcing function — nothing breaks, so nobody asks how it works until it does.\u003C\u002Fli>\n\u003Cli>Freelance or contract developers are used for speed, and the relationship ends before proper handover happens.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>The result is what's often called \u003Cstrong>tribal knowledge\u003C\u002Fstrong>: the logic of the system lives in one person's head, not in any document, diagram, or comment that a second person could pick up.\u003C\u002Fp>\n\u003Ch2>What does this actually cost a business?\u003C\u002Fh2>\n\u003Cp>The risk is concrete, not theoretical. A few real-world scenarios:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>A FileMaker developer leaves the company. Three months later, a change in tax regulations requires an update to the invoicing module. Nobody can find where the tax calculation actually happens in the script, because it's buried inside a poorly named custom function with no comments.\u003C\u002Fli>\n\u003Cli>A key developer is sick for two weeks during a product launch. A field in the order form needs a new validation rule, but nobody else on the team knows the naming convention used for scripts, so the change either doesn't happen or gets done wrong and breaks something else.\u003C\u002Fli>\n\u003Cli>A company wants to connect its FileMaker solution to a new webshop via an API integration. The integration partner asks for a data model overview — and it doesn't exist. Two weeks of the project timeline disappear into reverse-engineering the database structure that already existed.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>In every case, the software itself was fine. The knowledge around it was the single point of failure.\u003C\u002Fp>\n\u003Ch2>How do you know if your business already has this risk?\u003C\u002Fh2>\n\u003Cp>Run through this checklist honestly:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Can you name, right now, who besides the original developer could open the solution and make a safe change to it?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Is there a written (or recorded) explanation of the overall data model — tables, relationships, and why they're structured that way?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Are scripts and custom functions named and commented well enough that someone unfamiliar with them could guess their purpose?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Is there a change log or version history showing what changed, when, and why?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Do you know where API keys, server credentials, and integration settings are stored — and is that list up to date?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> If your current developer left tomorrow, could a new developer get productive within a week, or would they need a month just to understand the system?\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>If more than two of these make you uneasy, the risk is already live in your organization — it just hasn't cost you anything yet.\u003C\u002Fp>\n\u003Cp>[[IMAGE:left|one head icon holding all knowledge, versus knowledge spread across a team and documents]]\u003C\u002Fp>\n\u003Ch2>What does a good knowledge-transfer setup actually look like?\u003C\u002Fh2>\n\u003Cp>This isn't about forcing developers to write a 200-page manual nobody reads. It's about making the essential knowledge retrievable by someone who isn't the original author.\u003C\u002Fp>\n\u003Ch3>1. Document the data model, not just the features\u003C\u002Fh3>\n\u003Cp>A feature list tells you what the system does. A data model tells you \u003Cem>why\u003C\u002Fem> it's built that way — which is what a new developer actually needs. A simple entity-relationship diagram with notes on business logic ("a Job can have multiple Invoices, but only one active Contract") is worth more than pages of screenshots.\u003C\u002Fp>\n\u003Ch3>2. Use naming conventions and comments as a rule, not a favor\u003C\u002Fh3>\n\u003Cp>A script called \u003Ccode>Process_Order_v3_FINAL_fixed\u003C\u002Fcode> tells the next person nothing. A script called \u003Ccode>Order: Calculate shipping cost (based on weight tier)\u003C\u002Fcode> tells them almost everything. This costs seconds during development and saves hours during handover.\u003C\u002Fp>\n\u003Ch3>3. Keep a living change log\u003C\u002Fh3>\n\u003Cp>Every non-trivial change — a new field, a changed calculation, a new integration — gets one line in a log: what changed, why, and who approved it. Tools like FileMaker's built-in Script Debugger and version comments help, but the discipline matters more than the tool.\u003C\u002Fp>\n\u003Ch3>4. Separate business logic from tribal shortcuts\u003C\u002Fh3>\n\u003Cp>Many long-running FileMaker systems accumulate one-off workarounds ("if this field is empty, that means the record is archived"). These undocumented conventions are exactly what strands with one developer. Whenever one is found, either formalize it as a real, documented field\u002Fstatus, or write it down explicitly.\u003C\u002Fp>\n\u003Ch3>5. Build with modern, standards-based tools where possible\u003C\u002Fh3>\n\u003Cp>This is where tooling choices genuinely matter, not because one platform is inherently better, but because some approaches leave a clearer paper trail than others. For example:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>FmBetterForms\u003C\u002Fstrong> generates web-standard, responsive layouts inside FileMaker using a visual, structured approach rather than pixel-pushed custom layouts — which means a new developer can inspect the structure logically instead of reverse-engineering someone else's layout decisions.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>AI-assisted tools like Klai\u003C\u002Fstrong> (built specifically for the FileMaker ecosystem) can help a new developer or IT manager ask plain-language questions about an existing solution — "what does this script do" or "where is the shipping cost calculated" — and get a structured answer, effectively acting as a second-opinion documentation layer even when written docs are thin. This doesn't replace human documentation, but it dramatically lowers the cost of picking up an undocumented system.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>6. Cross-train deliberately, not accidentally\u003C\u002Fh3>\n\u003Cp>Even a two-hour walkthrough every quarter, where the primary developer explains a recent change to a second team member or an outside partner, builds redundancy over time. It doesn't need to be a formal process — it needs to actually happen on a schedule.\u003C\u002Fp>\n\u003Ch2>What should you do if you're already in this situation?\u003C\u002Fh2>\n\u003Cp>If there's already a system with a single point of knowledge failure, don't panic-document everything at once — that usually stalls. Instead:\u003C\u002Fp>\n\u003Col>\n\u003Cli>Identify the two or three most business-critical processes in the system (usually: invoicing, order flow, and whatever touches money or compliance).\u003C\u002Fli>\n\u003Cli>Have the current developer walk through those specific processes first, recorded and written up.\u003C\u002Fli>\n\u003Cli>Get an outside developer or partner to do a short structural review — an independent "what would I need to know to safely maintain this" audit — even if you don't plan to switch providers. It surfaces gaps the original developer won't think to mention, precisely because they're second nature to them.\u003C\u002Fli>\n\u003Cli>Prioritize documenting anything tied to compliance, financial calculations, or external integrations first — these carry the highest cost if misunderstood.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Does using FileMaker make this risk worse than other platforms?\u003C\u002Fstrong>\nNo — the risk is about process, not platform. FileMaker actually makes documentation easier than many alternatives, since the data model, scripts, and layouts are visible and inspectable in one file rather than spread across a codebase. The risk shows up wherever a system was built quickly by one person without a documentation habit — that happens with custom .NET apps, Excel-based systems, and low-code platforms just as often.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Should we insist every developer document everything before it ships?\u003C\u002Fstrong>\nInsisting on perfect documentation up front usually backfires — it slows delivery and gets skipped under deadline pressure. A lighter, consistent habit (naming conventions, a short change log, documenting the data model once and updating it) sustains itself much better than an ambitious policy nobody follows after month one.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Is AI a real solution here, or just a workaround?\u003C\u002Fstrong>\nAI tools that can read and explain an existing solution (like Klai for FileMaker) are genuinely useful as a safety net and a faster onboarding path — but they work best on top of at least minimal structure and naming discipline, not as a replacement for it. Think of it as a translator, not a substitute for the original source being reasonably organized.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>How do we know if our current developer relationship carries this risk?\u003C\u002Fstrong>\nAsk directly: "If you were unavailable for a month, what would break, and who could fix it?" A confident, specific answer is a good sign. A vague answer, or one that only involves that same developer, is the signal to start building redundancy now.\u003C\u002Fp>\n\u003Cp>This kind of risk rarely announces itself in advance — it just quietly determines how expensive your next change, integration, or emergency fix turns out to be. Loggix regularly steps into exactly this situation: reviewing an existing FileMaker solution, documenting its real structure, and rebuilding the fragile parts into something a team — not just one person — can safely maintain. Whether that means a structural audit, a tailored FileMaker or web application, an API integration between existing systems, or adding AI tooling like Klai to make an existing solution easier to understand, the starting point is the same conversation: what would happen to this system if the person who built it wasn't available tomorrow?\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901676000,[19,20,21,22,23,24],"Knowledge transfer","FileMaker development","software documentation","business continuity","IT risk management","custom software maintainability","\u002Fapi\u002Fknowledge\u002Fimage\u002F357\u002F?v=b71c09b5abe4",false,"",null,{"title":30,"slug":31},"Modern Software Development","modern-software-development",{"title":33,"slug":34},"How to make custom business software reliable and transferable","how-to-make-custom-business-software-reliable-and-transferable"]