System NotesXendai / Technical publication
Build only the gap
Build only the gap means concentrating custom development on what available capabilities do not adequately resolve. The gap may be a function, an integration, or a control required to complete the work. Identifying it means assessing the whole system, rather than counting components that can be bought or lines of code that can be avoided.
An AI project can combine existing models, applications, tools, and services. Its value does not depend on every component being new. It depends on that combination resolving work and remaining maintainable within the company's conditions.
Assembling products is not sufficient either. Responsibilities can remain uncovered between their capabilities: information losing meaning between applications, decisions no component verifies, or exceptions falling outside the intended workflow.
Custom engineering should locate those gaps and decide which deserve development. The principle neither demands buying everything nor reduces development to an absolute minimum. It requires explaining what is built, why available capabilities are insufficient, and who will maintain it.
Building is not evidence of value by itself
Development produces visible results: an interface, an integration, a function that did not exist before. That visibility can encourage measuring progress by what has been created even when some of it duplicates available capabilities.
The relevant question is what prevented the problem from being resolved. If a standard function already meets the necessary conditions, rebuilding it needs another reason. Integration constraints, control requirements, or disproportionate adoption costs may provide one, but the reason should be explicit.
Familiarity should also be distinguished from suitability. A team may build a component because it knows how, underestimating later maintenance. Another may adopt a familiar platform without checking whether its configuration fits the particular use.
Neither preference replaces analysis of the work. The comparison must include the requirements of building and adopting: configuration, integration, review, training, and evolution. Initial delivery is only part of that comparison.
This changes the discussion about customization. A company's particular way of working does not imply a need for custom components in every layer. It may need a specific combination of common parts and a small intervention at a decisive boundary.
Engineering value lies in recognizing that boundary. A solution can contain little custom development and require considerable judgment. A substantial component can also be justified when it addresses a need the alternatives cannot meet maintainably.
Existing capabilities need testing in context
Before defining a gap, establish which capabilities are actually available. That includes applications already in use, configurable functions, and integration opportunities the company has not yet used.
A capability can exist without being enabled or fitting the current procedure. Some of the work may therefore involve configuring it or adjusting operation rather than creating another application.
Matching feature names do not establish fit. “Approvals,” “memory,” and “automation” can describe very different behaviors. The review should examine the conditions supported, the information retained, and what happens outside the simplest path.
Usage limits matter too. A feature may be useful for preparing work but insufficient for executing it. It may handle part of the volume or require intervention in situations the company considers routine.
The objective is not an exhaustive market inventory. It is to identify plausible alternatives and test them against requirements that could change the decision. Search should end when enough evidence exists to choose, rather than continue in pursuit of an apparently perfect tool.
Existing capabilities deserve the same scrutiny as custom ones. Adopting without testing can conceal integration work. Rejecting a function because it differs from the project's first imagined form can create unnecessary development. The criterion is the actual need, not fidelity to the first proposed implementation.
Describe the gap as an unmet condition
A development need becomes clearer when it can be expressed without naming the solution. Which outcome is missing, which condition is unmet, or which responsibility remains unresolved?
“We need our own platform” anticipates an answer. “Work loses its state between these applications” identifies a problem with several possible interventions. It may require integration, configuration, or a change in how work is organized.
The gap can also be a control. Existing tools may execute actions while none enforces an authorization condition specific to the process. Resolving that condition may be more valuable than placing a new interface over capabilities already available.
Not every particularity deserves preservation. Some differences arise from old decisions that no longer add value. Building around them can entrench complexity the organization could instead remove.
Analysis should distinguish justified needs, preferences, and habits. A preference may be accepted when its cost is reasonable, but should not be presented as a technical obligation. That distinction helps prevent scope from expanding through accumulated exceptions.
A well-defined gap has a completion criterion. It establishes when development has resolved the outstanding condition and when a new request belongs to another problem. Without that boundary, “build what is missing” can become an indefinite expansion of the system, with no clear point at which the original commitment has been fulfilled.
Integration and responsibility are work too
Two components can function correctly in isolation while their relationship remains problematic. They may interpret an identifier, cancellation, or completion state differently.
Integration is not a minor residue of the project. It can be the precise gap requiring custom engineering. Its value lies in preserving the meaning of work across components rather than introducing a conspicuous feature.
Some responsibilities also remain with the organization when managed services are used. AWS's shared responsibility model illustrates this in security: customer tasks vary with the service selected, and managed services do not remove every responsibility for data and permissions.
The lesson for project scope is specific: identify what remains with the organization using the solution. The word managed does not establish that an external party owns the complete outcome.
Evaluation can be part of that retained responsibility. A tool provides a capability, but someone must establish whether its combination with the rest of the system continues to resolve the work. Building that check may be necessary even when no visible functionality is original.
Building only the gap therefore does not mean delivering a connector and leaving operation unresolved. It means covering what the other parts do not cover, including the controls and evidence required to take responsibility for the whole. The boundary is defined by the work that remains necessary, not by what is most visible in a demonstration.
| Available capability | Adaptation to examine | Retained responsibility | Criterion for building |
|---|---|---|---|
| Document management | Access, classification, and connection to the work | Maintain suitable sources and permissions | A necessary condition cannot be met through configuration or existing integration |
| Model inference | Instructions, inputs, and output handling | Define and evaluate acceptable use | Specific logic connecting the capability to the required outcome is missing |
| Approval workflow | Roles, states, and review conditions | Identify who may decide and what the decision covers | The available workflow cannot express an essential process condition |
| Application connector | Identity, data meaning, and error states | Check exchange continuity and outcomes | The available connection leaves a necessary transition unresolved |
- Available capability
- Document management
- Adaptation to examine
- Access, classification, and connection to the work
- Retained responsibility
- Maintain suitable sources and permissions
- Criterion for building
- A necessary condition cannot be met through configuration or existing integration
- Available capability
- Model inference
- Adaptation to examine
- Instructions, inputs, and output handling
- Retained responsibility
- Define and evaluate acceptable use
- Criterion for building
- Specific logic connecting the capability to the required outcome is missing
- Available capability
- Approval workflow
- Adaptation to examine
- Roles, states, and review conditions
- Retained responsibility
- Identify who may decide and what the decision covers
- Criterion for building
- The available workflow cannot express an essential process condition
- Available capability
- Application connector
- Adaptation to examine
- Identity, data meaning, and error states
- Retained responsibility
- Check exchange continuity and outcomes
- Criterion for building
- The available connection leaves a necessary transition unresolved
Examples for analysis, not a product inventory. Before building, check whether configuration, integration, or simpler work can close the gap.
Documents, inference, approval, and connectors are examined through adaptation, retained responsibility, and conditions that could justify custom development.
Buying and building create different commitments
The comparison should examine the effort assumed under each option. Building introduces code and dependency maintenance. Adoption introduces configuration, integration, and decisions about living with another solution's evolution.
Neither option eliminates subsequent work. They distribute it differently and require different capabilities. One may be preferable because the team can maintain it, even when its initial cost is not the lowest.
It also matters how much development is genuinely specific and how much has been added for convenience. An integration can start with one need and expand into administration, permissions, and screens already offered by an existing component.
Excessive fragmentation creates the opposite problem. Selecting many small tools to avoid development can increase the number of relationships requiring maintenance. The solution with the least custom code is not necessarily the one with the least operational complexity.
The comparison unit should therefore be the complete service: what the business needs to use, check, and correct it throughout its life. Estimates should distinguish known costs from assumptions and avoid presenting usage-dependent savings as already demonstrated.
The decision can combine approaches. Adopting a standard capability, configuring another, and building a specific integration is not a compromise made for lack of ambition. It can be the most precise way to assign effort to what needs attention. The resulting mix should be judged by its contribution and maintainability rather than by the proportion of code owned.
Filling a gap does not require replacing everything
A new need can be addressed without rebuilding the existing foundation. Where boundaries permit, a limited intervention makes it easier to test value and learn before expanding the change.
Coexistence requires knowing which system owns each part of the work. Keeping two applications available is insufficient. The design must prevent them from acting on the same responsibility without clear rules.
Microsoft's Strangler Fig pattern describes gradual replacement of functionality while the previous system continues handling what has not migrated. It is a modernization pattern, not an obligation for every AI project. It illustrates that change can be bounded by function rather than assuming complete replacement from the outset.
For a smaller intervention, the decision may be to retain an application and address a particular limitation around it. What matters is understanding the ongoing relationship and the additional work that coexistence introduces.
Temporary components need retirement conditions too. A provisional integration can become permanent infrastructure when nobody retains the reason for its existence. Maintenance then consumes resources without an explicit decision that the component should remain.
Expansion should follow evidence about further needs. The first intervention succeeding does not establish that it should absorb the rest. Each increase in scope needs an explanation of the additional problem resolved and responsibility assumed. A useful first component does not automatically justify a broader platform.
The gap changes over time
What requires custom development today may later become adequately available elsewhere. The reverse can also happen: an adopted solution may cease to meet operating conditions and require adaptation.
Maintaining the principle means revisiting why each custom component exists. When its reason disappears, keeping it solely because it was expensive to build can perpetuate unnecessary work. Retirement is not free either; transition effort and behavior that must be preserved need consideration.
The question is not whether another tool has a similar feature. It is whether it resolves the same need under acceptable conditions with more appropriate total effort. That review avoids both constant replacement for novelty and permanent retention through inertia.
Each development should preserve a comprehensible justification: the condition it meets, the alternatives rejected, and the change that would make reconsideration reasonable. The record need not be lengthy, but its relationship to the work should remain visible after the original team has moved on.
Build only the gap is a discipline of scope across the system's life. It permits building when necessary, using what exists, and retiring what no longer contributes. Success is work resolved with clear responsibilities, not the amount of software carrying the team's authorship. That remains true whether the resulting intervention is a small integration or a substantial component.
The scope remains open to revision while the responsibility for maintaining it remains explicit.
KEY TAKEAWAY
Custom development should concentrate on conditions that existing capabilities do not adequately meet. The gap can include integration, controls, and operation as well as features. Defining its completion criteria makes adoption, configuration, and construction purposeful, and allows scope to be reviewed when either the work or the available alternatives change.
XENDAI CONNECTION
Xendai combines existing capabilities with specific engineering to resolve conditions left open between models, data, applications, and processes. Custom scope is defined by its contribution to the work and the responsibility of maintaining it, rather than the amount of software built.