Tại sao tôi build JARVIS — và nó chốt 4 deals trong 37 ngày

1 đêm tháng 3/2026, tôi đã rất bực

Tôi vận hành nhiều mảng đồng thời:

• AIC — kiến trúc + nội thất + xây dựng (10+ năm, B2B)
• OKG — công ty công nghệ mới mở 2025, đang triển khai HRMS hợp đồng đầu cho 1 khách enterprise
• 1 công ty thương mại đang R&D — sẽ thương mại vật liệu ngành cho AIC + partners
• Cá nhân — gia đình, tài chính, đầu tư

Mỗi mảng có context riêng, luật vận hành riêng, người liên quan riêng.

Trước JARVIS, tôi dùng Gemini, Claude, ChatGPT — cả 3 đều nghiêm túc. Chúng giúp tôi giải quyết nhiều việc thật:

• Làm BOQ
• Research
• Vẽ hình ảnh làm concept
• Tìm ý tưởng
• Rà soát số liệu
• Phân tích dữ liệu
• Giải quyết các conflict nội tại

Nhưng có cái dở chung: context limit. Nói trước quên sau. Rất bực.

Cái ngu là dùng còn phân mảnh

Tôi đã có Claude Code từ năm 2025 — dùng để code HRMS cho 1 khách enterprise. Code trên VSCode có. Google Antigravity cũng có (xài từ bản beta đầu tiên — đâu đó tháng 9-10/2025, không nhớ chính xác).

Nhưng cái ngu là tôi nghĩ Claude Code chỉ để code. Việc khác đi tool khác:

• ChatGPT cho 1 nhóm việc
• Gemini cho 1 nhóm khác
• Banana để vẽ đồ
• Mỗi lần switch → nhồi context lại từ đầu

Phân mảnh đến mức không sustain được.

Eureka moment — 24/03/2026, 16:46 UTC

1 ngày tôi chợt nghĩ:

Làm sao để khi nói AI việc A, nó tự link các context liên quan và xử lý đúng theo luồng workflow, không quên?

Lúc đó đang dùng Gemini là chính, Claude chỉ để code HRMS.

Pattern tôi nhớ ngay: giống y mình code HRMS vậy ta. HRMS có repo, có structure, có luật, có context full. Khi code, Claude Code đọc toàn bộ repo → hiểu được toàn bộ business logic → handle được mọi case.

Tại sao không làm thế cho mọi việc khác?

Tôi quyết build JARVIS như 1 repo. Đưa toàn bộ context vào:

• AIC (dự án kiến trúc/nội thất/xây dựng, BOQ, pricing, debtor)
• OKG (HRMS stack, đang build cho khách enterprise đầu)
• Công ty thương mại R&D (catalog vật liệu, partner)
• Personal
• Các luật vận hành tùm lum

Redesign ra JARVIS 1.0 — 4 layers.

Git log xác nhận commit đầu tiên: 2026-03-24 16:46:30 UTC. Đêm Khai Sinh.

37 ngày sau — 4 deals chốt, AIC team WOW

Tôi build trên Mac chủ yếu. Thành tựu lớn nhất: BOQ Pipeline.

Trước đây làm BOQ tốn 2-3 ngày. Pipeline này:

• Cực kỳ nhanh
• Nội dung đầy đủ
• Chuyên nghiệp

Khách khen thẳng. Cả team AIC WOW khi thấy báo giá ra đúng format pro.

Đến hôm nay (30/04/2026) — chính xác 37 ngày sau commit đầu — JARVIS 1.0 đã giúp chốt 4 deals.

Đó là outcome ngắn gọn nhất. Một insight + 37 ngày + 1 pipeline = 4 deals.

Bài học từ 37 ngày này

Tôi sẽ không nói sang VPS journey, JARVIS 2.0, hay Sprint 6 hiện tại trong bài này — đó là chuyện cho các bài tiếp theo. Bài này focus 1 thứ thôi: eureka moment.

3 thứ tôi rút ra sau 37 ngày:

1. Pattern recognition cao hơn frame — tôi đã code HRMS bằng Claude Code rất thuần thục, nhưng vẫn nghĩ Claude Code “chỉ để code”. Frame “dùng AI” của tôi đã giới hạn việc apply pattern. 1 đêm chợt nhận ra → đập frame.

2. Founder VN đa entity cần personal agent, không phải SaaS chung — tôi không build cái sẽ scale ra triệu user. Tôi build cái duy nhất phục vụ AIC + OKG + cá nhân của tôi. Top 1 niche.

3. Velocity 6.6× pure code là thật, nhưng đắt khi sai — 37 ngày ra 14 skill, nhưng cũng đốt tiền gấp đôi vì sai embedded text 4 lần. Đó là chuyện của bài tiếp.

Bài tiếp theo

Tôi sẽ viết theo chủ đề cụ thể, không kể 1 lèo:

• “Đốt tiền gấp đôi vì sai embedded text — Ollama → Gemini → OpenAI re-embed” (VPS journey)
• “BOQ Pipeline — pattern tôi copy từ HRMS code, AIC team đã WOW như thế nào” (build technique)
• “JARVIS 1.0 vs 2.0 — đập đi xây lại 4 layers thành 7 layers, học gì?” (architecture)
• “Velocity 6.6× baseline — tôi đo bằng cách nào, đáng tin tới đâu” (process)

Subscribe RSS hoặc theo LinkedIn để nhận bài mới.

Founder VN đa entity hoặc đang tự build personal agent — ping [email protected]. Không trả lời nhanh nhưng đọc tất.