Nacho Coll

背景

我從 2007 年起就在 AWS 上開發——從 S3 與 EC2 的最早期開始，那時「雲端」還遠不是預設答案。作為 AWS 企業架構師，我為包括 LEGO、Nordea、Vueling 在內的一批財富 500 強級別的頂級企業客戶設計過正式規模的系統。我今天所做一切背後的營運直覺，正是在那裡錘鍊出來的：成本紀律、多區域可靠性，以及從第一天起就認真看待可觀測性，而不是事後再補上。

2019 年以來，我一直並行專注於兩件事：面向即時與訊息類產品的基礎設施，以及軟體交付的 AI 一側——把同樣的企業架構紀律帶到兩者之中。這正是今天 Blockchain Web Services (BWS) 賴以運轉的根基：一家 AI 原生的解決方案工廠，只有一句經營口號，Demand Becomes Product。我們把經過驗證的市場需求，變成可直接投產的軟體——由人來打造，由 AI 來加速，端到端有人負責。從 BWS 交付的每一行程式碼，都由一位具名工程師所擁有。

BWS 以同樣的紀律交付多款正式產品。WallaWhats 是其中之一，其他還包括：

• OpenAgile.AI — 面向 AI 輔助開發的工程紀律。
• Zellbox — 面向預約導向型中小企業的 CRM：把客戶、預約與 WhatsApp 提醒集於一個收件匣。
• Badges.ninja — 區塊鏈可驗證的數位徽章，配有視覺化設計器與 REST API。
• IPFS.NINJA — 最簡單的 IPFS 釘選與上傳 API，帶有專屬閘道與慷慨的免費額度。
• Blockchain Database — 用單一 API 把區塊鏈當作資料層來使用。
• NFT.zK — 無需 Web3 專業知識即可鑄造 NFT 的簡明 API。
• Telegram XBot — 一個追蹤 X 活動、並突出社群頂級貢獻者的 Telegram 機器人。

BWS 在 2025 年年中轉向 AI 原生。AI 不是我們添加的一項功能——而是我們所成為的一家公司。工程標準沒有變：變的是 AI 如今能承擔多少調查、鷹架搭建與測試，因而一支小團隊就能交付過去需要大得多的團隊才能做出的、同樣形態的正式產品。

我們日常在做什麼

我的日常橫跨整個 BWS 解決方案組合——為各產品把定路線圖，與團隊一起審查技術設計，收緊交付它們全部的那套 AI 輔助交付流程，並讓工程紀律在一款產品到下一款產品之間保持一致。每款產品都有自己每週的節奏；我的工作，是把它們連起來的結締組織。

具體到 WallaWhats，我們主要專注於一個承諾：當你追蹤的帳號在 X 上發文，你會在幾秒內收到一則 WhatsApp——每一則貼文，按順序，由你所選的帳號決定，而非由 X 的排序或通知演算法決定。團隊近來親手打磨的方面包括：

• 絕不漏抓 — 盯住你訂閱的帳號有無新貼文，確保任何內容都不會被丟棄或重複發送，即使某個帳號從沉默轉為一分鐘內連發一串貼文。
• WhatsApp 送達 — 把每則提醒又快又整潔地送到你手機上，附帶一張推文快照圖，並追蹤送達狀態，好讓我們確知提醒確實落地，而不是想當然地以為它到了。
• 提醒速率與摘要 — 當某個追蹤的帳號在短時間內發幾十則貼文時，我們把這陣風暴合併成一則摘要，而不是把你的手機炸響，從而讓高發文量的帳號依然好用。
• 功能涵蓋面 — 在核心提醒之外，產品還提供作為替代管道的電子郵件送達、按帳號訂閱、送達歷史、你可查看與管理的每月提醒上限，以及一個真正好用的免費額度。每一項功能都是一等公民，而非順帶之作。
• 成本工程 — 一款即時監控產品有著真實的每則提醒成本。把這些成本壓低，正是我們能提供貨真價實的免費額度與誠實付費定價、而非虧本引流花招的原因。
• 客戶支援 — 我們直接處理每一則工單。如果你寄信到 support@wallawhats.com，你會收到一位真人的回覆——而大多數日子裡，那個人就是我。

我撰寫或審校過的文章

本站大多數文章都署有我的名字。有些由 AI 助手起草（完整流程見編輯流程）並在發布前由我審校；另一些則由團隊從頭寫到尾。無論哪種方式，每一處產品細節都在發布前對照實際服務進行了驗證。

幾篇有代表性的文章：

• 透過 WhatsApp 提醒的免費 TweetDeck 替代方案 — 關於如何不必整天開著儀表板也能盯住 X 的實戰一覽。
• 電子郵件 vs WhatsApp 提醒：即時之爭誰勝出？ — 對兩種送達管道的誠實比較，以及各自適用的場景。
• 在 X 上監控競爭對手：即時 WhatsApp 提醒 — 追蹤那些左右你市場的帳號的實用指南。