← The Adso Index

Borrowed Capability

How functionality and judgment developed elsewhere expand what an organization can build – and help it decide what to carry for itself.

August 18, 2026 12 min read

Systems CMS Technology Strategy Software Ecosystems Organizational Workflows

A desk covered with system diagrams, integration notes, dependency assessments, and competing software options.

An organization wants its website to do more than appear when someone searches for its name. It wants search engines and emerging answer systems to understand what it does, where it works, who provides its services, and what experience or authority supports them.

Much of that information is already on the website. Services have pages, staff members have biographies, locations have addresses, and publications have authors. What may be missing is a clear account of how those facts belong together.

Structured data provides a standardized way to describe and unify that information so other systems can interpret it. The SEO plugin already installed on the site offers to generate the necessary code, connect familiar fields, check for common errors, and adapt when search platforms change their requirements. It presents those capabilities through settings that let someone identify the information being described and connect it to content the site already maintains. Some of those settings, however, are available only after a paid upgrade.

The organization could pay for the feature, install another plugin, commission a small custom solution, or use a free library that handles part of the work. None of those choices begins at zero. Schema.org develops the shared vocabulary; plugins and libraries provide ways to apply it; and custom development can connect it more closely to the organization’s information. Each approach borrows a different portion of the solution and leaves a different portion for the organization to carry.

Borrowed capability is that portion of a solution gained from work developed elsewhere. It may come from a platform, plugin, library, public standard, hosted service, or an earlier project. Whatever the source, the larger advantage is the same: an organization can begin with something useful, informed by experience it did not have to accumulate alone.

The Advantage of Starting Somewhere Else

Nearly every modern website depends on borrowed capability. A content management system handles publishing. A service accepts payments. A library processes images. A plugin manages forms. A public standard allows unrelated systems to understand the same information. Even heavily customized applications depend on languages, frameworks, security practices, and conventions maintained by other people.

This is not a compromise in the ordinary sense of settling for less. It is how a project concentrates its attention. An organization that borrows a dependable payment system can focus on what it sells. One that adopts a mature publishing platform can focus on what it needs to communicate. A small team can benefit from built-in support for keyboard and screen-reader use, editorial tools, infrastructure, and years of development it would struggle to reproduce or maintain on its own.

Preassembled systems such as Squarespace, Wix, Weebly, and Webflow carry a large portion of the solution within one service. WordPress offers a foundation that can be assembled from its own capabilities, commercial products, community projects, and custom work. Neither model is inherently more serious. Each provides a different place to begin and a different range of decisions that remain.

The important word is capability. A project is not merely borrowing a button, a block, or a line in a feature list. It is borrowing functionality and accumulated judgment: the work that makes the visible feature possible, the decisions behind it, and sometimes the attention required to keep it useful.

Following the Requirement

The available product is often where the conversation starts because it is the part everyone can see. The requirement may be somewhere underneath it.

In the opening example, the organization does not fundamentally need a premium structured-data feature. It needs its services, people, credentials, locations, and publications to form a clearer and more useful account of what the organization knows about itself. The structured-data settings unlocked by the paid upgrade are one possible way to carry that requirement.

For a small organization with a straightforward site, the basic structured-data support already included with its website platform or plugin may be entirely sufficient. It may identify the organization, connect its social and professional profiles, describe its location, and produce the search features that matter. Accepting that boundary can be a fair compromise: the implementation does not express everything the underlying standard permits, but it meets the known need while sparing the organization work it has little reason to assume.

Another organization may find that even the settings unlocked by the paid upgrade stop early. Its people need to be connected with qualifications, publications, services, professional profiles, and one another. The paid product may still provide the strongest foundation because its interface is familiar, its routine output is dependable, and someone continues to maintain it. A developer can then add the relationships particular to the organization rather than replacing the whole product.

If the product cannot be extended at the necessary point, a free library may provide a better foundation for a custom implementation. The project still borrows the shared vocabulary and the technical work already contained in the library, but supplies its own interface and connections. An older project may offer an even stronger starting point if its underlying model remains sound and the organization is prepared to bring it up to current expectations.

These approaches are not ranked by how much custom work they contain. They are different paths through the same requirement. The useful path may be preassembled, extended, combined, revived, or built more directly from common foundations. What matters is how much of the real problem each piece carries and whether the remainder lands somewhere sensible.

Deciding What Each Part Carries

By the time several plausible paths are visible, trade-offs are already part of the work. Budget, time, available skills, editorial effort, future maintenance, and the importance of the requirement all influence how much of a solution should be borrowed and how much the organization should carry. There is no untouched ideal waiting outside those conditions; even a completely custom system reflects choices about where effort will be spent and where established work will be trusted.

The price of a product and the cost of a capability are therefore related, but they are not the same thing. A paid subscription may carry compatibility testing, documentation, support, interface improvements, security work, and continued attention to changes in the surrounding systems. For an editorial team managing hundreds of pages, a dependable interface used by several employees may be worth considerably more than the code it produces. Its value depends on how much of that work the organization would otherwise need to assume.

Free and open-source software presents another balance. The capability may be available without a purchase price, while configuration, integration, testing, and future maintenance remain with the project using it. That can be an excellent exchange when the foundation is strong and the organization has access to the skills needed to carry the rest.

Custom development changes the balance again. It can supply the portion no general product could reasonably anticipate while leaving mature, routine work with the platform, plugin, or library already handling it well. A developer may extend a paid product, place a free library beneath an organization-specific interface, or connect several specialized services without asking any one of them to become the entire system.

The most useful arrangement is not the one that removes every limitation. It is the one that places each responsibility with someone equipped to carry it and keeps the limitations that remain proportionate to their consequences.

Negotiating Depth

Structured data makes this negotiation unusually visible because the underlying vocabulary is much broader than any general-purpose interface can comfortably expose. A no-code product may describe a person with a name, image, biography, and links to social or professional profiles. A more connected treatment may also relate that person to their work, qualifications, publications, affiliations, services, and education.

The shallower implementation is not necessarily defective. It may be exactly right for the people expected to maintain it and the outcomes the organization needs. Adding every relationship the vocabulary permits would create its own cost in editorial work, governance, and maintenance. The decision is not between shallow and complete so much as between different levels of depth and the obligations attached to each.

The newer language surrounding search makes this judgment more important. Products may present AEO or GEO as another capability to add, while Google describes generative search as an extension of its existing search systems and says no special AI markup is required. That does not make structured data unimportant. It means structured data should improve the clarity and usefulness of the organization’s information rather than serve as a ceremonial admission ticket to AI results.

The same negotiation occurs beyond search. A form builder may collect information without supporting every part of the process that follows submission. A page builder may display articles while leaving a growing publication to define relationships among authors, topics, and recurring series. A hosted service may perform a difficult operation well while limiting how its results return to the rest of the organization. Each can remain part of a sound solution if the uncovered portion is understood and addressed where it matters.

Depth is not a contest to implement everything a tool or standard permits. It is the point at which the borrowed capability meets the organization’s actual use of it. That point may move as the work develops, which is why the surrounding decisions need room to move with it.

Carrying More When It Matters

As the requirement becomes clearer during development, evaluation may confirm that a prepared feature is sufficient or expose a missing relationship important enough to justify custom work. The project can retain what the existing product does well and assume responsibility only for the portion it cannot carry.

Occasionally, the best available foundation is an older open-source project whose model remains more suitable than current alternatives. Bringing it up to modern standards can be more sensible than recreating the capability or forcing the requirement into a poorer fit. Reviving it for one organization creates a defined maintenance obligation; returning that work to public use adds documentation, compatibility, contribution review, and the needs of people beyond the original project.

Whether extending a current product or renewing an older project, the organization is choosing to carry more because the value of the capability justifies the responsibility. What began as borrowed work may become a custom extension or shared stewardship. That progression is not evidence that the original choice was mistaken. It shows that the boundary was reconsidered as the requirement became clearer.

This is where a developer’s judgment becomes valuable. The role is not to pursue purity by replacing every prepared solution with custom code. It is to recognize what has already been solved well, determine where the borrowed solution’s assumptions fit, and help the organization take responsibility for the portion that deserves closer attention.

Keeping Change Bounded

No borrowed component needs to be treated as temporary, but neither should it become indistinguishable from the organization’s purpose. A form product may collect an application, but it is not the application process. An SEO plugin may produce structured data, but it is not the organization’s understanding of its people and services. A page builder may present articles, but it is not the publication’s editorial structure.

Keeping those distinctions clear makes earlier choices easier to revisit. A known limitation provides a starting point when the organization needs more; a hidden limitation tends to become visible only after it has constrained the work. The goal is not to predict every future requirement, but to preserve enough understanding that a change in one part of the machinery remains a bounded problem.

That agility depends on preserving the information, relationships, and decisions that belong to the organization. Important information remains identifiable. Connections to outside services have visible boundaries. Custom additions use the extension points a product provides instead of quietly rebuilding its internal machinery. The project understands which responsibilities it would need to resume if the outside party stopped carrying them.

With that groundwork in place, changing the implementation becomes more manageable. If the structured-data plugin no longer fits, the organization still knows which people, services, credentials, locations, and publications need to remain connected. A new plugin, custom extension, or different platform can be evaluated against those relationships rather than against the menus and field names of the product being replaced.

That clarity also allows a reasonable compromise to evolve without turning every change into a rebuild. A limited feature can remain in place while it meets the need, be extended when a missing relationship becomes important, or be replaced when the work required to accommodate it outweighs the value it provides. The earlier decision does not need to be defended as permanent. It only needs to have been reasonable under the conditions in which it was made and to leave enough understanding for the next decision.

Choosing the Useful Head Start

Borrowing well does not mean selecting the tool with the longest feature list or assembling every product a tutorial recommends. It means finding the portion of the problem that has already been solved at the right depth.

No solution is free of compromise. The useful distinctions are whether its limitations are understood, whether its responsibilities are carried by people equipped to handle them, and whether the arrangement can change as the organization learns more. A prepared platform may be the true solution when its assumptions fit. Several borrowed pieces may need to be joined. Custom work may provide the last important relationship rather than replace everything that came before it.

Borrowed capability gives organizations access to more functionality, accumulated judgment, infrastructure, and development than most could build alone. Its value does not come from avoiding responsibility altogether. It comes from placing responsibility deliberately – borrowing what others already carry well, accepting limitations that do no meaningful harm, and preserving the organization’s effort for the part only it can define.