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 11 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. Through its settings, someone can identify the organization, describe its services, and connect that information to existing pages. 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 search engines to understand how its services, people, credentials, locations, and publications relate to one another. The structured-data settings unlocked by the paid upgrade are one possible way to meet that need.

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. What matters is which needs the chosen tools meet, what remains to be done, and who will be responsible for it.

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. Custom development has to answer to those conditions too.

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 makes the remaining limitations clear enough to judge whether they are acceptable.

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 simpler 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 entering information, deciding who is responsible for it, and keeping it current. More detail is useful only when it serves a purpose worth that ongoing effort.

The newer language surrounding search makes this judgment more important. Products may present “answer engine optimization” or “generative engine optimization” 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.

The question is how far the capability needs to go to support the work. That answer may change as the organization uses it, discovers limitations, or takes on new responsibilities.

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 something the organization maintains itself or helps maintain for others. That progression is not evidence that the original choice was mistaken. It shows that the division of responsibility changed as the need 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 replacing one tool does not require rediscovering how the whole process works.

That agility depends on preserving the information, relationships, and decisions that belong to the organization. The organization needs to know where important information is held, how it moves between services, and what would need attention if a provider changed or withdrew its offering. Custom additions should use the supported ways of extending a product, so they can be maintained without quietly becoming a second version of the product itself.

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 can have served the organization well without needing to serve it forever.

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 well enough for the work at hand.

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.

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.