The Hidden Dangers of Building Your Own Frontend Component Library

Frontend Development and Component Libraries

Note: "small company" refers to teams with insufficient resources and technical capability.

In many small‑company projects we often hear ideas such as "our special requirements make existing component libraries insufficient, so we should build our own" or "the current library's style doesn't match our product, we need to develop a custom one."

Our special requirements make existing component libraries insufficient; we should encapsulate our own.

The current library's style doesn't fit our product, so we should develop a custom library.

Previously I naïvely supported these ideas, but now I would give the proposer a big slap! What seems visionary is actually a trap that can become a nightmare for the whole team.

A loading component caused a production incident

I will share a production incident caused by our component library.

Previously we had a table with a very fast API, so we did not add a loading style.

The implementation is very simple:

<template>
  <section class="table-section">
    <m-table :columns="columns" :data-source="tableData"></m-table>
  </section>
</template>
<script setup>
const tableData = ref([]);
const columns = [];
const getTableData = async () => {
  // ...interface call logic
  queryManageList();
};
// fetch data
getTableData();
onMounted(() => {
  // dynamically set header data
  columns = [];
});
</script>

m-table

is our internal table component; the code runs stably. As data grew, the API slowed, and the client wanted a loading indicator.

Our Loading component is modeled after Element Plus, with a very similar API.

Reference documentation makes the code change easy:

<template>
  <section class="table-section">
    <m-table :columns="columns" :data-source="tableData"></m-table>
  </section>
</template>
<script setup>
const tableData = ref([]);
const columns = [];
const getTableData = async () => {
  loadingInstance = Loading('.table-section');
  // ...interface call logic
  await queryManageList();
  loadingInstance.destroy;
};
getTableData();
onMounted(() => {
  // dynamically set header data
  columns = [];
});
</script>

After deployment we discovered that the columns disappeared.

Investigation showed that loadingInstance = Loading('.table-section') replaced all DOM elements inside the section tag, causing the Vue instance of the table to fail and the onMounted hook never executed.

In contrast, Element Plus creates the overlay under the section tag, avoiding this issue.

Small‑company component libraries often cause online problems because developers have varying skill levels.

Why small companies should not easily encapsulate component libraries

From the case above we can see that developers' skill levels vary, so component‑library quality cannot be guaranteed. Technology is not the main issue; the following problems are fatal.

Insufficient resources: double cost of manpower and time

Building a component library is not a simple development task; it requires a lot of manpower and time.

Developers : staff who normally write business code must divert effort to library development, delaying business progress.

Time cost : beyond writing a few buttons, it involves design systems, documentation, unit testing, performance optimization, and browser compatibility—a long‑term effort.

In our company we have to write business code and maintain the component library simultaneously, which is very time‑consuming.

We are constantly given more tasks, leading to a 996 work schedule.

High maintenance cost: building a wheel once, fixing it forever

Self‑built libraries are easy to create but hard to maintain long‑term. As projects evolve, the library needs constant updates.

Increasing requirements : business diversity inflates the library, making simple components complex.

Bug fixing : lack of large‑scale usage means hidden bugs surface in production, consuming much time.

Compatibility issues : adapting to new browsers or frameworks (Vue 3, React 18) is painful.

One upgrade introduced a severe bug that crashed many pages, causing a major production incident.

Component upgrades often cause hidden bugs; fixing one may introduce another, leading to multiple library versions for a single feature.

Because the component’s functionality is incomplete, a lot of communication cost is incurred.

Technical debt: short‑term convenience, long‑term burden

Initially a self‑built library feels convenient, but as the project scales its flaws become technical debt.

Lack of standardization : different developers write inconsistent code for the same feature.

Insufficient documentation : limited time leads to poor docs, making onboarding hard.

Upgrade difficulty : each upgrade may affect existing business, increasing testing cost.

Employee turnover risk: the library becomes an island

If the developer responsible for the library leaves, the library may become unmaintained, threatening project sustainability.

Our company has laid off many staff, leaving some components without owners and delaying progress.

Conclusion

Encapsulating a component library for a small company is a high‑risk, high‑cost, low‑return choice.

Prefer mature open‑source libraries such as Ant Design or Element Plus.

Customize rather than rebuild: if an open‑source library lacks some features, perform a secondary encapsulation instead of starting from scratch.

Focus on business: the primary goal is to deliver features, and component libraries should be a bonus, not a burden.

Technical work should serve business; forcing a custom library only harms the team.