我們費了這麼大工夫搞出這麼一個 Boilerplate，要怎麼知道它不是紙上談兵，而是真的可以上線當做商業服務呢？最好的辦法當然就是拿它來實作商業應用！

現階段我正使用這個 Boilerplate 開發自己參與的新創團隊的網站服務 － Caserhub；一位好友目前的新創團隊也採用我們的 Boilerplate 來開發自己的商業應用；另外，我自己最先套用 Boilerplate 的應用是我的個人網站；日後我也打算拿這套 Boilerplate 開發實驗室的形象網站。

Case #1 - Caserhub

在這個應用中，非常著重表單的填寫，還有表單欄位的多元性，因此 Boilerplate 在表單處理上提供的大量彈性根本發揮地淋漓盡致啊！在此案例中，我需要客製化一個深度未知的巢狀 Select 欄位，也需要可以輸入標籤的 Input 欄位，多虧了 Boilerplate 先前規劃好的欄位寫法與架構，讓我可以在短時間內建出這兩種客製化的新欄位，而且很方便地直接使用在表單上。

Case #2 - 個人網站

我的個人網站其實目前是未完工的狀態，目前正在使用 Draft.js 開發 WYSIWYG 編輯器，打算做為個人部落格的發文工具。在這個案例中，我可以全心開發編輯器，而不必煩惱多國語系、後台管理系統等如何撰寫，因為 Boilerplate 都已經幫我完成了。

Boilerplate 的回饋補償機制

各位是否注意到，其實這些客製化專案中新增的 Feature 不只是能夠用在自己的專案裡，其實可以淬煉成獨立的模組再塞回 Boilerplate 中，而且這些新 Feature 是經過 Real World 的考驗，提供 Feature 的模組本身已經擁有適度的開發彈性（該有的 props 都有了，該有的 options 也都有了）。

因此從這幾個案例中，我歸納出了 Boilerplate 的生態中其實隱藏著回饋補償機制。

上游的 Boilerplate 提供基礎設施給下游不同的專案來進行客製化，客製化的過程中會開發出新的好用模組，這些模組為了適應客製化專案的需求而逐漸完善，最終這些好用的模組可以被加回 Boilerplate 中，未來就能提供更好用的 Boilerplate；而當上游的 Boilerplate 發現問題時，也可以透過 Git 的操作把 Patch 下載至下游的專案中。

下游專案把好用模組回饋給上游 Boilerplate，上游 Boilerplate 也把 Bug 的修正補償至下游的專案裡，這樣的機制我把它稱做回饋補償機制，由於它是一個正向的循環，所以我認為 Boilerplate 將會不斷進化，這也是為什麼我一直看好我們的 Boilerplate 的原因。