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.

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, và mình định giữ lời. Bài này không phải bài đó.

Nhưng Prova khiến mình nhận ra một điều có ích hơn sớm hơn mình nghĩ:

Khi một thứ thôi là một cái tên và bắt đầu trở thành sản phẩm thật, bottleneck sẽ đổi.

Ít nhất, đó là cảm giác của mình trong đợt build này.

Phần khó không phải là để LLM generate code.

Phần khó, từ trải nghiệm của mình trong đợt này, 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.

Bài học hữu ích hơn là: điều gì bắt đầu quan trọng khi một sản phẩm thôi là demo.

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

Mình phải thừa nhận là đặt tên Prova là một trong những quyết định dễ hơn trong cả quá trình.

Cái tên khớp với chính sản phẩm.

Prova nghĩa là proof hay test. Và đó gần như đúng là công việc của sản phẩm. Nó không ở đây để vuốt ve ai đó và khiến họ cảm thấy mình đã là builder. Nó ở đây để buộc họ chứng minh công việc của mình. Tên đẹp, hữu dụng, dễ nhớ. Nói cách khác, đó là phần dễ.

Phần khó bắt đầu ngay sau đó. Bởi vì 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 AI builder program có cấu trúc dành cho marketers và advertising professionals muốn đi từ việc dùng AI tools sang việc build workflows, pilots, và operating systems thật. Trên thực tế, điều đó nghĩa là assessment và onboarding, một sản phẩm đi theo sprint 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 là soft launch: core production system đã live và chạy được, nhưng vẫn còn launch-readiness work đang nằm trong danh sách, bao gồm cleanup cho billing portal return path và coverage đầy đủ hơn cho MFA automation. Theo mình, chính điều đó lại khiến bài học này hữu ích hơn. 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

Đây có lẽ là bài học quan trọng nhất.

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, về cơ bản là 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 composition thêm một 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ới là real learning loop.

Nói đơn giản hơn, 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 rằng sprint đó grounded, đúng level, và vẫn review được bằng cùng standard như authored curriculum.

Không phải kiểu "model có trả JSON hay không?"

Mà là:

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 đó.

Và đó là lý do mình nghĩ phần này quan trọng đến vậy.

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.

Rất nhiều learning thật diễn ra trong một vòng lặp chặt từ April 8 tới April 10:

schema groundwork
composed sprint lifecycle
tagged knowledge rebuild
retrieval gate
composition calibration
full eval pass
integration coverage
browser QA trên live flow

Sequence đó quan trọng.

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 và confirmation 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 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:

17 Supabase migrations đã được apply trong production schema bootstrap hiện tại
4,390 production knowledge-base rows đã được publish và tag cho composition retrieval
38 downloadable resources đã được publish
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

Mình không liệt kê những con số này để nghe như mình bận rộn.

Đ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. Nó 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.

Nhưng Prova đẩy mình tới một kết luận quan trọng hơn:

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.

Chat interface 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.

Đây Là Bài Học Tháng 4 Hữu Ích Hơn

Mình vẫn còn nợ bài full 30-day Codex verdict vào May 2, 2026, và mình định đăng đúng lúc đó.

Bài đó sẽ là nơi phù hợp để nói về cost timeline, câu chuyện limits, những gì mình nhớ ở Claude, và những gì thay đổi trong day-to-day working model của mình.

Nhưng Prova đã dạy mình một điều bền hơn cả tool comparison:

phần thú vị nhất của AI product building hiếm khi nằm ở demo.

Nó nằm ở khoảnh khắc hệ thống của bạn bắt đầu đưa ra lời hứa thật với users, và bạn nhận ra có bao nhiêu lời hứa trong số đó sống bên ngoài generated code.

Đó là phần mình tôn trọng hơn bây giờ.

Và thật lòng mà nói, 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 là một structured AI builder program dành cho marketers và advertising professionals muốn đi từ việc dùng AI tools sang build workflows, pilots, và operating systems thật. Ở cấp độ sản phẩm, 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 tất cả.

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