Code Là Phần Dễ Hơn Khi Đưa Prova Thành Sản Phẩm

Prova bắt đầu thấy thật với mình vào lúc sản phẩm không còn cho mình tự lừa mình nữa.

Một homepage có thể ở trạng thái aspirational rất lâu.

Một sản phẩm đang chạy thì không.

Khi người dùng có thể signup, xác nhận email, rơi vào nhầm state, chạm vào billing, nộp bài, rồi mong hệ thống nhớ chính xác chuyện gì đã xảy ra, bottleneck sẽ đổi.

Sản phẩm bắt đầu đưa ra những lời hứa thật. Và phần invisible work đột nhiên trở nên rất visible.

Cập nhật ngày 16 tháng 4, 2026: kể từ lúc tôi viết bản đầu tiên của bài này, Prova đã chuyển sang một split rõ hơn giữa Operator và Builder. Tôi giữ nguyên luận điểm chính, nhưng cập nhật các chi tiết cụ thể về sản phẩm bên dưới để bài này khớp với những gì đang live hiện nay.

Nếu bạn đã đọc ba bài mình viết trong tháng 3 và đầu tháng 4 về việc chuyển từ Claude Max sang Codex, thì experiment đó vẫn đang diễn ra. Mình đã hứa sẽ có một follow-up tử tế vào May 2, 2026. Bài này không phải bài đó.

Nếu bạn chưa từng nghe tới Prova: đây là coaching product của mình dành cho marketers và advertising professionals, với một Operator path cho việc redesign workflow và một Builder path cho việc ship một slice hữu ích đầu tiên.

Phần khó, từ trải nghiệm của mình trong đợt này, không phải là để LLM generate code. Phần khó là mọi thứ bao quanh code.

Nếu bạn đang build với AI lúc này, nhất là thứ gì đó liên quan đến real users, real money, hay real product state, thì đây rất có thể là phần chẳng mấy ai cảnh báo bạn.

Đặt Tên Là Phần Dễ

Mình phải thừa nhận là đặt tên Prova là phần dễ. Prova nghĩa là proof hay test, khớp với đúng công việc của sản phẩm: bắt người ta chứng minh work của mình, chứ không phải vuốt ve để họ cảm thấy đã là builder.

Phần khó bắt đầu ngay sau. Khi Prova thôi là một cái tên và một landing page, nó bắt đầu đòi hỏi tất cả những thứ không hào nhoáng mà sản phẩm thật luôn đòi hỏi:

assessment logic
onboarding state
authored progression
review visibility
billing flows
auth hardening
content publishing
release gates

Điều đó thay đổi cách mình nghĩ về cả AI tools lẫn product building.

Prova Thực Ra Phải Trở Thành Gì

Prova bây giờ là một sản phẩm opinionated hơn so với lúc mình mới bắt đầu viết bài này. Surface của nó đã split ra hai entry path rõ hơn: một Operator path cho những người đang redesign workflows và một Builder path cho những người đang cố ship một slice hữu ích đầu tiên. Ở phía builder, bây giờ điều đó có nghĩa là một Build Reality Check, một Build Brief, một Build Plan, một execution lane trong khi build đang chạy, và một launch gate trước khi show cho một real user.

Bên dưới cái surface gọn hơn đó, phần system work khó nhằn vẫn đúng là point mình đã làm khi viết bản đầu của bài này. Nó vẫn là assessment và onboarding, một sản phẩm sprint-first chứ không phải chat-first, progression dựa trên review, product state bền vững, và một mentor layer hoạt động giống office hours xoay quanh sprint hiện tại hơn là một AI chat box chung chung.

Để nói cho rõ, mình không hề bảo Prova là "xong rồi". Mình cũng ước mình có thể nói vậy và move on, nhưng như thế sẽ hơi quá tiện cho mình, và có lẽ không đúng. Cách framing đúng lúc này vẫn là controlled launch: billing portal và recovery flows đã live, nhưng open work đã chuyển từ phần product plumbing cơ bản sang việc làm cho Builder path, execution lane, và launch gate trở nên honest hơn dưới usage thật. Mình nghĩ chính điều đó lại khiến bài học này hữu ích hơn, chứ không kém đi. Product building ngoài đời thật là như vậy. Chưa xong. Không giả. Chỉ là đủ thật để sai lầm tiếp theo bắt đầu có giá.

Phần Việc Mà Mình Không Thể Chỉ Generate Ra

Phiên bản dễ nhất của một AI product luôn là demo version.

Bạn có thể làm nó trông như đang sống rất nhanh:

một homepage
một chat box
vài screenshot bóng bẩy
một câu product sentence nghe rất thuyết phục

Phiên bản đó hữu ích nếu bạn muốn teaser cho launch.

Nó không hữu ích nếu bạn muốn hiểu công việc thật nằm ở đâu.

Với mình, công việc thật bắt đầu lộ ra ở sáu chỗ.

1. Sprint system phải thôi giả vờ

Mình không muốn Prova trở thành một sản phẩm trông có cấu trúc trên landing page nhưng vào bên trong là generic ngay lập tức.

Fixed authored sprints hữu ích cho tới khi chúng không còn đủ nữa.

Vấn đề thật xuất hiện khi một learner pass một sprint, nhưng gap tiếp theo của họ lại không phải authored sprint tiếp theo trong catalog.

Phiên bản lười nhất sẽ là:

"Cứ để model invent sprint tiếp theo đi: title, rubric, review criteria, everything."

Mình không tin cách đó.

Vậy nên hệ thống phải nghiêm khắc hơn.

Bây giờ reviewer vẫn có thể recommend canonical next sprint khi authored path là đúng. Nó có thể assign một adaptive detour, tức là một sprint tạm thời giúp learner vá một foundation gap rồi quay lại main path, khi một lỗ hổng nền tảng quen thuộc xuất hiện. Và khi gap tiếp theo nằm ngoài authored catalog, nó có thể request một composed sprint.

Nghe trong blog thì nhỏ.

Nhưng trong một sản phẩm, nó không hề nhỏ.

Bởi vì composed sprint không chỉ là "dynamic text".

Nó phải tạo placeholder sprint, persist assignment, giữ được return path về canonical roadmap, fill sprint packet, rồi cho phần còn lại của hệ thống đối xử với sprint đó như real product state.

Constraint khiến chuyện này còn đáng tin là rất đơn giản:

model không được phép tự invent standard.

Composed sprint chỉ fill packet: title, summary, context, assignment, example.

Submission schema và review rubric vẫn lấy từ authored template sprint.

Đó là một trong những bài học lớn nhất của cả đợt build này.

Nếu bạn muốn thứ gì đó dynamic mà vẫn đáng tin, hãy giữ contract cố định và để model vận hành bên trong contract đó.

Đây cũng là chỗ Codex giúp mình rất nhiều. Không phải kiểu flashy "nhìn xem nó generate gì này". Mà ở kiểu hữu ích hơn nhiều: migrations, router logic, placeholder lifecycle, request state, integration tests, và tất cả phần contract work nhàm chán giúp một dynamic product bớt giả hơn.

Mình cũng phải thú nhận là mình đã từng bị cám dỗ bởi phiên bản lười đó, ít nhất trong chốc lát. Cứ để model thông minh. Cứ để hệ thống trông magical. Dọn sau. Ý tưởng đó nghe hay lắm cho tới khi bạn tự tưởng tượng mình phải giải thích một bad sprint assignment cho một paying user.

2. Retrieval phải mang tính curriculum, không chỉ semantic

Khi mình cho hệ thống compose sprints, retrieval quality thôi không còn là một backend detail nữa.

Nó trở thành curriculum quality.

Nếu sản phẩm sẽ compose một sprint về tooling, measurement, hay competitive intelligence, nó không thể chỉ kéo vài chunks "na ná liên quan" từ knowledge base rồi hy vọng packet sẽ coherent.

Vậy nên knowledge base phải thông minh hơn.

Mình rebuild nó từ corpus thật: blog posts, course modules, transcripts, companions, templates, và deep-dive resources.

Sau đó, mình chunk các nguồn này khác nhau tùy theo bản chất của chúng.

Narrative blog posts có thể để chunk lớn hơn.

Instructional modules cần heading-first instructional chunks.

Templates và reference assets cần structured chunking để giữ lại tables, checklists, slide references, và quick-reference sections thay vì flatten mọi thứ thành generic paragraphs.

Rồi tới tagging.

Không chỉ là "nó nói về cái gì?" mà còn là:

đây là loại chunk nào
topic tags nào hợp với nó
audience nào nên dùng nó
difficulty level nào phù hợp

Điều đó biến retrieval từ kiểu "nearest vector wins" thành thứ gì đó gần hơn với curricular matching.

Sản phẩm có thể hỏi kiểu:

"Hãy đưa cho tôi material đã grounded cho topic này, cho audience này, ở level này."

Đó là một hệ thống nghiêm túc hơn rất nhiều so với việc chỉ bolt RAG lên một demo.

3. Evals phải test cả pipeline, không chỉ model

Mình không muốn tuyên bố chiến thắng chỉ vì một composed sprint trông ổn trên UI. Vậy nên eval system phải lớn lên cùng sản phẩm.

Đầu tiên là sprint review eval harness. Sau đó composition thêm retrieval gate, một pass/fail check xem tagged retrieval có thật sự cải thiện grounded material trả về hay không, so với untagged baseline. Rồi tới full end-to-end harness: compose sprint packet, generate synthetic submissions vẫn hợp lệ với schema, chạy real reviewer trên các submission đó, judge kết quả qua grounding, audience differentiation, difficulty gradient, curriculum coherence, review quality, và comparison với authored work.

Mục tiêu là chặn chuyện "personalized progression" biến thành fake personalization. Nếu hệ thống định nói, "sprint tiếp theo này thật sự dành cho bạn", nó cần nhiều hơn một packet trông ổn. Nó cần bằng chứng:

packet có grounded không
track framing có thật sự làm thay đổi work product không
level 2 và level 5 có khác nhau rõ ràng không
reviewer có còn ra đúng pass/revise call không
composed sprint có còn cảm giác thuộc về curriculum hay chỉ lơ lửng bên ngoài

Loop này phơi ra những vấn đề thật. Synthetic revise submissions yếu mà vẫn còn quá mạnh. Audience framing bị collapse giữa các tracks. Measurement packets nghe có vẻ ổn nhưng thực ra không trả lời các trust questions khác nhau cho các learners khác nhau.

Một trong những khoảnh khắc khiến mình khiêm tốn hơn là nhận ra thứ gì đó có thể nhìn "khá ổn" trên UI mà vẫn fail ngay khi mình hỏi một câu khó hơn. Một packet có thể đọc mượt nhưng vẫn quá generic. Một revise case có thể nghe plausible nhưng vẫn quá dễ. Chuyện đó khá tốt cho cái tôi của mình, theo một cách nào đó.

Hệ thống không tốt lên vì mình có một prompt hay. Nó tốt lên vì sản phẩm có thể fail ở nơi public-to-me, bên trong eval harness, trước khi fail ở nơi public-to-users. Nó không phải một miracle. Nó là một loop có kiểm soát.

4. Trust surfaces phải là thật

Đây lại là một nơi nữa mà real products tách mình ra khỏi demos.

Không ai quan tâm AI layer của bạn elegant tới đâu nếu:

email confirmation bị hỏng
Google sign-in lúc được lúc không
user mắc kẹt trong auth loop
thiếu abuse controls
account hardening trông như được thêm cho có

Với Prova, credibility layer cuối cùng bao gồm:

email confirmation đưa người dùng quay lại đúng product flow
Google SSO
optional app-based two-factor auth (TOTP MFA)
Turnstile protection cho auth và assessment

Đó là kiểu việc mà người ta ít khoe vì nghe vừa operational vừa boring.

Theo mình, đó là một mistake.

Operational và boring chính là nơi sản phẩm kiếm được trust, hoặc âm thầm đánh mất nó.

5. Billing phải test được, không chỉ tưởng tượng được

Mình ngày càng hoài nghi với những product builders nói về monetization như thể chỉ cần một Stripe screenshot là xong.

Billing trở nên rất thật rất nhanh.

Nó không chỉ là:

"Về mặt kỹ thuật thì có trả tiền được không?"

Mà là:

chuyện gì xảy ra ở trial state
chuyện gì xảy ra khi webhook state tới muộn
làm sao test an toàn mà không diễn kịch trên chính revenue surface của mình
làm sao verify toàn bộ flow mà không invent những one-off exceptions làm hệ thống kém tin cậy hơn về sau

Prova bây giờ có real subscription flow cộng với internal QA checkout path dành riêng cho billing verification an toàn hơn. Nghe có thể nhỏ. Nhưng không hề. Càng nghiêm túc với sản phẩm, bạn càng cần cách test commercial logic mà không tự lừa mình về cái gì đã được verify và cái gì chưa.

6. Operations phải trở thành một phần của sản phẩm

Một trong những thứ khiến Prova thấy thật với mình là chuyện mình phải đối xử với nó như một operational system riêng, chứ không phải một feature nhét vào site hiện có: separate production system, separate Supabase project, separate Vercel project, separate auth configuration, separate billing setup, separate release gates.

Câu đó nghe không sexy. Nhưng nó có lẽ lại là câu quan trọng nhất.

Bởi vì sản phẩm không chỉ gãy ở UI layer. Nó gãy ở nơi các systems chạm nhau, nơi assumptions bị rò, nơi environments bị drift, nơi ai đó nói "launch xong mình sửa sau", rồi cái bản after-launch đó không bao giờ thật sự tới.

Càng làm Prova, mình càng tôn trọng những câu operational boring.

Nếu bạn muốn một pressure test nhanh cho chính AI product của mình, hãy tự hỏi:

standard nào vẫn phải giữ cố định khi model trở nên dynamic
retrieval nào giữ output grounded
eval nào bắt được fake personalization trước khi user bắt được
edge nào trong auth, billing, hay state sẽ khiến bạn xấu hổ vào ngày mai

Nếu các câu trả lời đó còn mờ, khả năng cao sản phẩm của bạn vẫn đang nghiêng về demo hơn là system.

Phần Proof Thật Sự Quan Trọng

Mình không muốn nói về productization chỉ bằng những abstraction, vì như vậy nó nghe triết lý hơn thực tế.

Proof quan trọng nhất không phải là "mình viết bao nhiêu migrations?"

Mà là thứ gì bây giờ thật sự chạy được cho một real user.

Ở soft-launch phase này, sản phẩm có thể nói một cách đủ credibly rằng:

email signup, confirmation, và password recovery chạy được
Google SSO chạy được
optional TOTP MFA chạy được
downloadable resources và signed downloads chạy được
sprint submission và AI review chạy được trên production
Stripe checkout handoff và billing portal access chạy được

Đó là buyer-facing layer của proof.

Bên dưới nó, vẫn có system proof từ repo và rollout work:

4,390 production knowledge-base rows đã được publish và tag cho composition retrieval
tagged retrieval gate đánh bại untagged baseline
full 18-case composition eval suite đã pass gate của nó
một internal QA checkout path an toàn hơn cho billing verification

Điều mình chưa có là broad external proof từ một nhóm users đủ lớn nói rằng, "thứ này đã thay đổi outcomes cho tôi." Còn quá sớm để nói vậy, và mình không muốn giả vờ.

Mình liệt kê các con số này vì rất dễ xem nhẹ việc "biến một ý tưởng thành sản phẩm" thật sự đòi hỏi gì, nếu bạn chỉ nói bằng launch language.

Điều quan trọng không nằm ở counts.

Mà nằm ở thứ chúng đại diện:

sprint system không còn mang tính trang trí
retrieval không còn fuzzy
evaluation không còn performative
product state đủ durable để người ta dựa vào

Invisible work vẫn là work.

Và thường nó là phần khó hơn.

Điều Này Thay Đổi Gì Trong Đầu Mình

Mình vẫn nghĩ AI tools quan trọng. Tất nhiên là vậy. Codex hữu ích trong đợt này vì nó cho cảm giác competent, careful, và methodical, giúp mình đi qua engineering work mà không có quá nhiều emotional theater. Claude, với mình, vẫn tốt hơn khi công việc trở nên taste-heavy và thiên về sáng tạo hơn. Bài full 30-day Codex verdict vẫn sẽ ra vào May 2, 2026, và đó mới là nơi phù hợp để nói về cost timeline, câu chuyện limits, và những gì thay đổi trong day-to-day working model của mình.

Nhưng Prova đẩy mình tới một kết luận quan trọng hơn bất kỳ tool comparison nào.

Mình nghĩ AI có thể tăng tốc implementation, nhưng nó không xóa được nhu cầu về judgment quanh product boundaries, sequencing, credibility, và operational truth. Judgment đó vẫn là công việc.

Landing page không phải sản phẩm. Một named concept không phải sản phẩm. Một generated component chắc chắn cũng không phải sản phẩm.

Với mình, điều khiến một thứ bắt đầu giống sản phẩm thật là invisible architecture quanh visible experience. Khoảnh khắc real users có thể vào, trả tiền, tiến bộ, bị block, recover, nộp bài, và tin vào state họ đang nhìn thấy, bạn không còn đang chơi với demo nữa. Bạn đang đưa ra lời hứa.

Và theo mình, chính promises là nơi product building trở nên nghiêm túc. Đó là phần mình tôn trọng hơn bây giờ, và mình nghĩ đó là phần mà nhiều builders nên nói tới hơn.

Câu Hỏi Thường Gặp

Prova là gì?

Prova bây giờ là một structured coaching product dành cho marketers và advertising professionals muốn có một con đường nghiêm túc hơn để đi vào AI work. Hiện tại nó có hai entry path rõ hơn. Operator path dành cho workflow redesign, measurement, và judgment về rollout. Builder path dành cho việc ship một slice hữu ích đầu tiên, và bây giờ đi qua một Build Reality Check, một Build Brief, một Build Plan, một execution lane, và một launch gate. Bên dưới cả hai path, sản phẩm thật sự vẫn là assessment, onboarding, sprint progression, review logic, resources, billing, auth, và product state hoạt động cùng nhau, thay vì một AI chat box giả vờ làm cả hệ thống.

Composed sprint trong Prova là gì?

Composed sprint là một sprint packet được generate cho một learner gap thật nằm ngoài authored catalog hiện tại. Constraint quan trọng nhất là model không được tự invent standard. Packet có thể dynamic, nhưng submission schema và review rubric vẫn đến từ một authored template sprint.

Vì sao AI product building lại khó hơn sau giai đoạn demo?

Bởi vì ngay khi real users có thể signup, trả tiền, recover từ lỗi, nộp bài, và tin vào state họ nhìn thấy, sản phẩm bắt đầu đưa ra lời hứa. Khi đó, những invisible systems quanh AI layer, như auth, retrieval quality, evals, billing, và operations, sẽ quan trọng hơn rất nhiều so với việc first output có trông ấn tượng trong demo hay không.

Nếu bạn đang build với AI lúc này, mình thật sự tò mò:

điều gì là thứ đầu tiên khiến dự án của bạn thấy "quá thật", khoảnh khắc một demo biến thành một lời hứa?

Đó là tất cả từ mình cho lúc này.

Thân mến, Chandler