Product : Talk2Notion

**Lifetime: **talk2notion.com/lifetime

2025 ခုနှစ် June လကုန်ပိုင်းမှာ ဒီ project ကို ပထမဆုံးစတင်ခဲ့တဲ့အချိန်တုန်းက ကျနော့်ရဲ့စိတ်ထဲမှာ ရှိတာက ရိုးရှင်းပါတယ်။

Burmese language နဲ့ ပြောလိုက်တဲ့အကြောင်းအရာတွေကို စာသားအဖြစ် ပြောင်းပေးနိုင်မယ်၊ ပြီးရင် ကိုယ်အသုံးပြုနေတဲ့ knowledge system ထဲကို အလွယ်တကူ သိမ်းဆည်းနိုင်မယ်ဆိုတဲ့ product idea တစ်ခုပဲ ဖြစ်ပါတယ်။

ဒါပေမဲ့ တကယ်တည်ဆောက်သွားတဲ့အခါမှာတော့ AI API တစ်ခုကို ခေါ်သုံးရုံ၊ user interface လေးတစ်ခုရေးရုံနဲ့ product တစ်ခု မဖြစ်လာဘူးဆိုတာ သိလာရပါတယ်။

AI model integration ကနေစပြီး backend architecture, authentication, database security, native iOS development, payment system, App Store review, deployment, testing, product pricing နဲ့ cross-platform design အထိ အလွှာပေါင်းများစွာကို တစ်ခုချင်းစီ လေ့လာဖြေရှင်းခဲ့ရပါတယ်။

GitHub မှာ မြင်ရတဲ့ commit history, ပြန်ပြင်ခဲ့ရတဲ့နေရာတွေ၊ bug တက်ခဲ့တဲ့ flow တွေနဲ့ product ထဲမှာ အကြိမ်ကြိမ်ပြန်ထိတွေ့ခဲ့ရတဲ့ engineering hotspots တွေကို ပြန်ကြည့်တဲ့အခါ ဒီ project က ကျနော့်ကို သင်ပေးခဲ့တာဟာ coding syntax တစ်ခုချင်းထက် ပိုကြီးပါတယ်။

ဒီ journey ကနေ ကျနော်လေ့လာခဲ့ရတဲ့ အဓိကအရာတွေကို ပြန်မျှဝေချင်ပါတယ်။

1. AI API Integration ဆိုတာ API ကို ခေါ်တတ်ရုံမဟုတ်ဘူး

အစပိုင်းမှာ AI API Integration ဆိုတာ audio file တစ်ခုကို model ဆီပို့လိုက်မယ်၊ model က စာသားပြန်ပေးမယ်၊ အဲဒီစာသားကို user ဆီပြမယ်လို့ ရိုးရိုးရှင်းရှင်း ယူဆခဲ့ပါတယ်။

Prototype အဆင့်မှာတော့ ဒီလိုတွေးတာ မှန်ပါတယ်။

Production product ဖြစ်လာတဲ့အခါမှာတော့ AI provider တစ်ခုချင်းစီရဲ့ request format, response structure, file upload process, supported file size, model capability, timeout, rate limit နဲ့ error behavior တွေက မတူကြပါဘူး။

တစ်ခါတလေ response ပြန်လာပေမဲ့ expected text field မပါဘူး။ တစ်ခါတလေ model က success status ပြပေမဲ့ content က empty ဖြစ်နေတတ်တယ်။ တစ်ခါတလေ file upload က အောင်မြင်ပေမဲ့ processing မပြီးသေးခင် transcription request လုပ်မိတတ်တယ်။

ဒါကြောင့် AI API Integration မှာ အရေးကြီးတာက happy path တစ်ခုတည်းကို ရေးထားတာ မဟုတ်ပါဘူး။

Model က ဘာမှပြန်မပေးရင် ဘာလုပ်မလဲ၊ provider တစ်ခု unavailable ဖြစ်ရင် fallback ဘယ်လိုသုံးမလဲ၊ user က model ပြောင်းလိုက်ရင် configuration ဘယ်လိုလိုက်ပြောင်းမလဲ၊ rate limit ဖြစ်လာရင် user ကို ဘာပြောမလဲဆိုတာတွေကိုပါ စဉ်းစားရပါတယ်။

အဲ့ဒီကနေ ကျနော်သိလာတာက AI feature တစ်ခုရဲ့ quality ဟာ model ဘယ်လောက်ကောင်းလဲဆိုတာတစ်ခုတည်းနဲ့ မဆုံးဖြတ်ဘူးဆိုတာပါ။

Model နဲ့ product ကြားမှာ ရှိနေတဲ့ integration layer က အားနည်းနေရင် ကောင်းတဲ့ model ကိုသုံးထားလည်း user experience က မကောင်းနိုင်ပါဘူး။

2. Transcription Pipeline တစ်ခုတည်းနဲ့ Use Case အားလုံးကို မဖြေရှင်းနိုင်ဘူး

Audio transcription ဆိုတဲ့ feature ကို အပြင်ကကြည့်ရင် flow တစ်ခုတည်းလို မြင်ရပါတယ်။

Record လုပ်မယ်၊ upload လုပ်မယ်၊ transcription ထုတ်မယ်၊ သိမ်းမယ်။

ဒါပေမဲ့ user က app ထဲမှာ စက္ကန့်ပိုင်းလောက် voice note ပြောတာနဲ့ နာရီဝက်၊ တစ်နာရီကြာ lecture တင်တာ မတူပါဘူး။

Phone shortcut ကနေ ချက်ချင်း capture လုပ်တာနဲ့ messaging bot ကနေ audio file ပို့တာ မတူပါဘူး။ Personal note တစ်ခု save လုပ်တာနဲ့ business workflow တစ်ခုအနေနဲ့ process လုပ်တာလည်း မတူပါဘူး။

Short audio တွေမှာ speed နဲ့ immediacy က အရေးကြီးပါတယ်။

Long audio တွေမှာ file size, upload stability, processing duration, background execution နဲ့ progress feedback က ပိုအရေးကြီးပါတယ်။

တချို့ flow တွေမှာ user က result ကို စောင့်နေပါတယ်။ တချို့ flow တွေမှာတော့ background မှာ process လုပ်ပြီး အဆင်သင့်ဖြစ်တဲ့အခါ ပြန်ပေးတာ ပိုသင့်တော်ပါတယ်။

ဒီလိုနဲ့ transcription ဆိုတဲ့ feature တစ်ခုအောက်မှာ pipeline အမျိုးမျိုး ရှိလာပါတယ်။

ဒီ experience ကနေ သင်ယူခဲ့တာက shared logic ရှိတာနဲ့ flow အားလုံးကို function တစ်ခုထဲမှာ အတင်းထည့်ထားလို့ မရဘူးဆိုတာပါ။

Common foundation ကို reuse လုပ်ရပေမဲ့ use case တစ်ခုချင်းစီရဲ့ constraints နဲ့ user expectation ကိုလည်း လေးစားရပါတယ်။

3. Prompt Engineering ကို ခံစားချက်နဲ့မပြင်ဘဲ Test-Driven နည်းနဲ့ ပြင်ရတယ်

Burmese transcription အတွက် prompt ပြင်တဲ့အခါမှာ အစပိုင်းက “ဒီ prompt က ပိုကောင်းမယ်ထင်တယ်” ဆိုတဲ့ intuition နဲ့ ပြင်ဖြစ်ခဲ့ပါတယ်။

ဒါပေမဲ့ mixed-language audio တွေကို စမ်းကြည့်တဲ့အခါ prompt တစ်ခုက sentence structure ကို ပိုကောင်းစေပေမဲ့ လူနာမည်တွေ မှားသွားနိုင်တယ်။ English technical term တွေမှန်ပေမဲ့ နံပါတ်၊ ရက်စွဲနဲ့ negation တွေ မှားသွားနိုင်တယ်။

အထူးသဖြင့် Burmese နဲ့ English ကို တစ်ကြောင်းတည်းမှာ ရောပြောတဲ့အခါ context ကို မသိမ်းနိုင်ရင် product meaning တစ်ခုလုံး ပြောင်းသွားတတ်ပါတယ်။

“လုပ်မယ်” နဲ့ “မလုပ်ဘူး” ကို မှားတာက spelling error သေးသေးလေးမဟုတ်ပါဘူး။

Business note, meeting record သို့မဟုတ် personal reminder မှာတော့ ဆုံးဖြတ်ချက်တစ်ခုလုံးကို ပြောင်းသွားစေနိုင်ပါတယ်။

ဒါကြောင့် prompt ပြင်တဲ့အခါ sample audio set တစ်ခုထားပြီး names, numbers, dates, English terms, negation နဲ့ sentence completeness စတဲ့ category တွေနဲ့ နှိုင်းယှဉ်စမ်းသပ်ဖို့လိုလာပါတယ်။

ဒီနေရာမှာ ကျနော်သိလာတာက Prompt Engineering ဟာ creative writing တစ်မျိုးတည်းမဟုတ်ဘဲ evaluation problem လည်းဖြစ်တယ်ဆိုတာပါ။

ကောင်းတယ်ထင်တဲ့ prompt မဟုတ်ဘဲ ထပ်တလဲလဲစမ်းသပ်တဲ့အခါ consistent ဖြစ်တဲ့ prompt ကို ရွေးရပါတယ်။

4. Backend Routing က Product ရဲ့ Invisible Backbone ဖြစ်တယ်

Frontend ကို user တွေမြင်ရတဲ့အတွက် product development စလုပ်တဲ့အခါ UI ကို ပိုအာရုံစိုက်မိလေ့ရှိပါတယ်။

ဒါပေမဲ့ product ကြီးလာတာနဲ့အမျှ backend routes တွေက ပိုအရေးကြီးလာပါတယ်။

User authentication စစ်တာ၊ file ကိုလက်ခံတာ၊ transcription service ဆီပို့တာ၊ result ကိုပြန်စီစဉ်တာ၊ external workspace ထဲသိမ်းတာ၊ payment status စစ်တာနဲ့ agent tools တွေကို အလုပ်လုပ်စေတာအားလုံးဟာ backend မှာ ဖြစ်ပါတယ်။

Route တစ်ခုက responsibility များလွန်းသွားတဲ့အခါ debug လုပ်ရခက်လာတယ်၊ security boundary မရှင်းတော့ဘူး၊ error တက်ရင် ဘယ်အပိုင်းမှာဖြစ်တာလဲ မခွဲနိုင်တော့ပါဘူး။

ဒါကြောင့် auth, upload, processing, data saving နဲ့ billing-related logic တွေကို concern အလိုက် ခွဲဖို့ လေ့လာခဲ့ရပါတယ်။

Backend architecture က user မမြင်ရတဲ့အရာဖြစ်ပေမဲ့ product ရဲ့ reliability, security နဲ့ maintainability ကို အများဆုံး သက်ရောက်စေတဲ့အပိုင်းဖြစ်ပါတယ်။

ကောင်းတဲ့ UI က user ကို ပထမဆုံးစွဲဆောင်နိုင်ပေမဲ့ ကောင်းတဲ့ backend ကတော့ product ကို ရေရှည်အသုံးပြုနိုင်အောင် ထိန်းထားပေးပါတယ်။

5. Authentication မှာ “Login ဝင်လို့ရပြီ” ဆိုတာ အဆုံးမဟုတ်ဘူး

Authentication ကို စလုပ်တဲ့အချိန်မှာ login button နှိပ်လိုက်ပြီး account ထဲဝင်သွားရင် အလုပ်ပြီးပြီလို့ ထင်မိနိုင်ပါတယ်။

တကယ်တမ်းမှာ authentication flow တစ်ခုရဲ့ အခက်အခဲက login screen ထက် token lifecycle, callback handling, redirect configuration, session persistence နဲ့ platform differences တွေမှာ ပိုရှိပါတယ်။

Web browser ထဲက OAuth flow နဲ့ native mobile app ထဲက flow က မတူနိုင်ပါတယ်။ App တစ်ခုက browser ကိုဖွင့်ပြီး login ဝင်ပြီးနောက် app ထဲပြန်လာဖို့ deep link နဲ့ callback ကို မှန်မှန်ကန်ကန် ကိုင်တွယ်ရပါတယ်။

User က app ကိုပိတ်ပြီး ပြန်ဖွင့်တဲ့အခါ session ဆက်ရှိသင့်လား၊ token သက်တမ်းကုန်သွားရင် ဘယ်လို refresh လုပ်မလဲ၊ external service တစ်ခုနဲ့ချိတ်ထားတဲ့ authorization ကို ဘယ်လိုပြန်အသုံးချမလဲဆိုတာတွေကိုပါ စဉ်းစားရပါတယ်။

Google, Apple, email, external workspace OAuth နဲ့ agent-facing OAuth flow တွေကို အတူတူတစ်မျိုးတည်းလို့ ယူဆလို့မရပါဘူး။

ဒီလို flow မျိုးစုံကို ကိုင်တွယ်ရင်း Authentication ဆိုတာ login page တစ်ခုရေးခြင်းမဟုတ်ဘဲ identity နဲ့ session lifecycle ကို စီမံခြင်းဖြစ်တယ်ဆိုတာ နားလည်လာပါတယ်။

6. Authentication နဲ့ Authorization မတူဘူး

User တစ်ယောက် login ဝင်ထားတယ်ဆိုတာ သူက feature အားလုံးကို အသုံးပြုခွင့်ရှိတယ်လို့ မဆိုလိုပါဘူး။

ဒီကွာခြားချက်ကို product monetization နဲ့ feature gating စတင်ထည့်သွင်းတဲ့အချိန်မှာ ပိုသိလာရပါတယ်။

တချို့ user တွေက lifetime plan ဖြစ်နိုင်တယ်။ တချို့က cloud credit ကိုသုံးနေတာ ဖြစ်နိုင်တယ်။ တချို့က ကိုယ့် API key ကိုယ်သုံးနိုင်တယ်။ တချို့ feature တွေက mobile app ထဲမှာပဲရနိုင်ပြီး တချို့က admin အတွက်ပဲ ဖြစ်နိုင်ပါတယ်။

ဒီလို access rules တွေကို UI မှာ button ဖျောက်ထားရုံနဲ့ မလုံလောက်ပါဘူး။

Frontend validation ကို ကျော်ပြီး backend route ကို တိုက်ရိုက်ခေါ်နိုင်တာကြောင့် permission ကို server side မှာ ပြန်စစ်ရပါတယ်။

ဒီနေရာကနေ authentication က “ဘယ်သူလဲ” ဆိုတာကို အတည်ပြုတာဖြစ်ပြီး authorization က “ဘာလုပ်ခွင့်ရှိလဲ” ဆိုတာကို ဆုံးဖြတ်တာဖြစ်တယ်ဆိုတာ လက်တွေ့သဘောပေါက်လာပါတယ်။

Product က ပိုရှုပ်လာလေ feature-level permission system က ပိုအရေးကြီးလာပါတယ်။

7. Database Security ကို Application Code တစ်ခုတည်းနဲ့ မယုံသင့်ဘူး

Database ကို စတင်အသုံးပြုတဲ့အချိန်မှာ application code ထဲမှာ user ID စစ်ထားရင် လုံလောက်မယ်လို့ ယူဆမိနိုင်ပါတယ်။

ဒါပေမဲ့ production system မှာ client request တစ်ခုချင်းကို ယုံကြည်လို့မရပါဘူး။

Row Level Security နဲ့ database policies တွေကို အသုံးပြုရင်း database layer ကိုယ်တိုင်က user တစ်ယောက် ဘယ် row ကိုဖတ်နိုင်သလဲ၊ ဘယ် row ကိုပြင်နိုင်သလဲဆိုတာကို ဆုံးဖြတ်ပေးသင့်တယ်ဆိုတာ သိလာပါတယ်။

Application code မှာ bug ရှိသွားရင်တောင် database policy က နောက်ဆုံး security boundary အဖြစ် ကာကွယ်ပေးနိုင်ပါတယ်။

တစ်ချိန်တည်းမှာ product က version အမျိုးမျိုး ဖြတ်သန်းလာတာကြောင့် schema အဟောင်းနဲ့အသစ်၊ optional field တွေ၊ migration မပြီးသေးတဲ့ account တွေကိုလည်း ထည့်စဉ်းစားရပါတယ်။

Database design ဆိုတာ table တည်ဆောက်တာတစ်ခုတည်းမဟုတ်ဘဲ ownership, access rule, migration နဲ့ backward compatibility ကို အတူတကွ စီမံရတဲ့အလုပ်ဖြစ်ပါတယ်။

8. Security Hardening ကို Product ပြီးမှ ထည့်လို့မရဘူး

အစပိုင်းမှာ feature အလုပ်လုပ်ဖို့ကို အဓိကထားမိတာ သဘာဝပါပဲ။

ဒါပေမဲ့ user များလာတာ၊ AI processing cost မြင့်တဲ့ routes တွေပေါ်လာတာနဲ့ security ကို နောက်မှထည့်မယ်ဆိုတဲ့နည်းလမ်းက အန္တရာယ်များလာပါတယ်။

Upload endpoint တစ်ခုကို abuse လုပ်နိုင်သလား၊ expensive AI operation တစ်ခုကို အကြိမ်ပေါင်းများစွာခေါ်နိုင်သလား၊ agent tool တစ်ခုက user မရသင့်တဲ့ data ကို ရယူနိုင်သလား၊ private integration token တွေ browser ထဲပေါ်နိုင်သလားဆိုတာတွေကို စဉ်းစားရပါတယ်။

Security hardening ဆိုတာ hacker movie ထဲကလို dramatic attack တွေကိုပဲ ကာကွယ်တာမဟုတ်ပါဘူး။

Authentication စစ်တာ၊ permission စစ်တာ၊ request size ကန့်သတ်တာ၊ rate limiting လုပ်တာ၊ sensitive credential ကို server side မှာထားတာ၊ internal request ကို validate လုပ်တာနဲ့ error message ထဲမှာ လျှို့ဝှက်အချက်အလက် မထွက်အောင်ထိန်းတာတွေဟာ နေ့စဉ် engineering work ပါ။

ကျနော်လေ့လာခဲ့ရတာက security ဆိုတာ feature တစ်ခုမဟုတ်ဘဲ feature အားလုံးကို ဖြတ်သန်းနေတဲ့ design constraint တစ်ခုဖြစ်တယ်ဆိုတာပါ။

9. External Workspace API တစ်ခုကို Product Flow ထဲထည့်ခြင်း

External workspace API တစ်ခုနဲ့ ချိတ်ဆက်တာကို ပထမမြင်ရင် page create လုပ်ပေးရုံလိုထင်ရပါတယ်။

ဒါပေမဲ့ real product flow ထဲမှာ database ကိုရှာတာ၊ schema ကိုနားလည်တာ၊ properties mapping လုပ်တာ၊ page body blocks တည်ဆောက်တာ၊ category ရွေးတာ၊ preview text ဖန်တီးတာ၊ duplicate template ကို support လုပ်တာနဲ့ OAuth authorization ကို ကိုင်တွယ်ရပါတယ်။

User တစ်ယောက်ချင်းစီရဲ့ workspace structure ကလည်း မတူနိုင်ပါဘူး။

တချို့ user တွေမှာ field မရှိနိုင်ဘူး၊ field name ပြောင်းထားနိုင်တယ်၊ template ကို duplicate မလုပ်ရသေးတာ ဖြစ်နိုင်တယ်။

API integration က technical connection တစ်ခုသာမဟုတ်ဘဲ ကိုယ့် product data model နဲ့ အခြား product တစ်ခုရဲ့ data model ကြား ဘာသာပြန်ပေးရတဲ့အလုပ်ဖြစ်ပါတယ်။

ဒီအတွေ့အကြုံကနေ integration design မှာ “API ကဘာလုပ်နိုင်လဲ” ဆိုတာထက် “User ရဲ့ workflow ထဲမှာ ဘယ်လိုသဘာဝကျကျ ဝင်မလဲ” ဆိုတာကို ပိုစဉ်းစားတတ်လာပါတယ်။

10. Telegram Bot Development က Chat Interface တစ်ခုထက်ပိုတယ်

Messaging bot တစ်ခုတည်ဆောက်တဲ့အခါ command လက်ခံပြီး response ပြန်ပေးတာပဲဖြစ်မယ်လို့ ထင်ရလွယ်ပါတယ်။

တကယ်လုပ်တဲ့အခါ webhook configuration, duplicate update handling, media download, long audio processing, background task, inline button, model selection, user setting နဲ့ data saving flow တွေ ပါလာပါတယ်။

Messaging app ထဲမှာ user behavior က web app နဲ့ မတူပါဘူး။

User က command format ကို မမှတ်ထားချင်ဘူး။ Button ကိုနှိပ်ပြီး ဆက်သွားချင်တယ်။ Audio ပို့ပြီးနောက် bot က ဘာဖြစ်နေလဲဆိုတာ သိချင်တယ်။ Processing ကြာရင် response မရတော့ဘူးလို့ ထင်နိုင်ပါတယ်။

ဒါကြောင့် bot development မှာ backend engineering နဲ့ conversation design နှစ်ခုလုံးလိုပါတယ်။

မှန်ကန်တဲ့ result တစ်ခုပေးရုံမဟုတ်ဘဲ interaction တစ်ဆင့်ချင်းမှာ user မပျောက်သွားအောင် guidance ပေးရပါတယ်။

11. Native iOS Development က Web App ကို Wrapper ထည့်တာထက်ပိုတယ်

Web product ကို iOS app အဖြစ် ရယူချင်တဲ့အခါ အစမှာ wrapper approach က လျင်မြန်တဲ့နည်းဖြစ်နိုင်ပါတယ်။

ဒါပေမဲ့ native experience တစ်ခုလိုချင်လာတဲ့အခါ native authentication, audio recording permission, local file handling, settings interface, deep links, App Intents, Shortcuts, Share Extension, widgets နဲ့ wearable device integration အထိ ဝင်လာပါတယ်။

Web မှာအလုပ်လုပ်နေတဲ့ flow တစ်ခုက iOS မှာ တူညီစွာ အလုပ်လုပ်မယ်လို့ မယူဆနိုင်ပါဘူး။

Background behavior, permission dialog, app lifecycle, file access နဲ့ system UI convention တွေက မတူပါဘူး။

SwiftUI နဲ့ native feature တွေကို လေ့လာရင်း platform တစ်ခုကို support လုပ်တယ်ဆိုတာ screen size ပြောင်းလိုက်တာမဟုတ်ဘဲ အဲဒီ platform ရဲ့ interaction model ကို လက်ခံရတာဖြစ်တယ်ဆိုတာ သဘောပေါက်လာပါတယ်။

12. StoreKit နဲ့ In-App Purchase မှာ Purchase Button က အလွယ်ဆုံးအပိုင်းဖြစ်တယ်

In-App Purchase ထည့်တဲ့အခါ product ID တစ်ခုဖန်တီးပြီး purchase function ခေါ်လိုက်ရင် အလုပ်ပြီးပြီလို့ ထင်နိုင်ပါတယ်။

ဒါပေမဲ့ lifetime purchase ကိုပဲ ကြည့်မယ်ဆိုရင်တောင် product loading, purchase state, cancellation, pending transaction, restore purchase, sandbox testing, local testing နဲ့ server verification တွေ ရှိပါတယ်။

User က device အသစ်ပြောင်းသွားရင် သူဝယ်ထားတာကို ပြန်ရယူနိုင်ရပါမယ်။

Purchase အောင်မြင်သွားပေမဲ့ app database update မဖြစ်ရင် ဘယ်လို reconcile လုပ်မလဲဆိုတာလည်း ရှိပါတယ်။

Payment feature မှာ UI က သေးသေးလေးပေမဲ့ ယုံကြည်မှုက အလွန်ကြီးပါတယ်။

User က ငွေပေးပြီးသားဖြစ်တဲ့အတွက် state မမှန်တာ၊ restore မရတာ၊ access မပွင့်တာတွေက ပုံမှန် bug ထက် ပိုပြင်းထန်ပါတယ်။

ဒါကြောင့် monetization system ကို feature တစ်ခုလိုမဟုတ်ဘဲ financial state machine တစ်ခုလို စဉ်းစားဖို့ သင်ယူခဲ့ရပါတယ်။

13. App Store Review ကို Reviewer နားလည်နိုင်အောင် Evidence နဲ့ ဆက်သွယ်ရတယ်

App Store submission အတွေ့အကြုံက code အလုပ်လုပ်ရုံနဲ့ distribution အဆင်ပြေမသွားဘူးဆိုတာ သင်ပေးခဲ့ပါတယ်။

Reviewer က product ကို ကျနော်တို့လို နေ့တိုင်းသုံးနေသူမဟုတ်ပါဘူး။

Feature တစ်ခု ဘယ်နေရာမှာရှိလဲ၊ purchase ကိုဘယ်လို restore လုပ်မလဲ၊ test account ဘယ်လိုသုံးမလဲ၊ product ID ဘာကြောင့် ဒီလိုဖြစ်လဲ၊ guideline တစ်ခုကို ဘယ်လိုလိုက်နာထားလဲဆိုတာ ရှင်းပြရပါတယ်။

“Feature ရှိပါတယ်” လို့ပြောတာထက် reviewer ကို အဲဒီ feature ဆီ တိတိကျကျရောက်အောင် လမ်းညွှန်ပေးရပါတယ်။

Build notes, reviewer-facing copy နဲ့ screenshots တွေကို concrete evidence အဖြစ် သုံးတတ်ဖို့လိုပါတယ်။

ဒီလိုနဲ့ App Store review က technical compliance သာမဟုတ်ဘဲ clear communication problem လည်းဖြစ်တယ်ဆိုတာ သိလာပါတယ်။

14. Cross-Platform Product Design မှာ Platform အများကြီးလုပ်ခြင်းထက် Product တစ်ခုတည်းဖြစ်နေရမယ်

ဒီ product က web app ကနေစပြီး PWA, iOS, wearable device, desktop environment, messaging bot, browser extension နဲ့ conversational agent integration အထိ တဖြည်းဖြည်း တိုးလာပါတယ်။

Platform အများကြီး support လုပ်နိုင်တာက အားသာချက်ဖြစ်ပေမဲ့ platform တစ်ခုချင်းကို သီးခြား product လို ဖြစ်သွားရင် complexity တက်လာပါတယ်။

အရေးကြီးတာက user ရဲ့ core intent မပြောင်းဖို့ပါ။

သူက idea တစ်ခု capture လုပ်ချင်တာလား၊ note တစ်ခုရှာချင်တာလား၊ lecture တစ်ခု process လုပ်ချင်တာလားဆိုတဲ့ intent ကို platform အလိုက် အလွယ်ဆုံးနည်းနဲ့ ဖြည့်ဆည်းပေးရပါတယ်။

Phone မှာ voice capture က အကောင်းဆုံးဖြစ်နိုင်ပြီး browser မှာ text selection save လုပ်တာက အကောင်းဆုံးဖြစ်နိုင်ပါတယ်။ Watch မှာတော့ interaction ကို အလွန်တိုအောင်လုပ်ရပါတယ်။

Cross-platform architecture ဆိုတာ feature အားလုံးကို platform အားလုံးမှာ တူတူထည့်တာမဟုတ်ပါဘူး။

Core product identity တစ်ခုတည်းကို platform တစ်ခုချင်းရဲ့အားသာချက်နဲ့ ဖော်ပြတာဖြစ်ပါတယ်။

15. Frontend Refactoring ကို UI ပျက်မှ စလုပ်တာ နောက်ကျတတ်တယ်

Product feature တွေမြန်မြန်ထည့်နေတဲ့အခါ component ကြီးတစ်ခုထဲမှာ state, API calls, dialogs, recording logic နဲ့ layout တွေအားလုံး တဖြည်းဖြည်းစုလာတတ်ပါတယ်။

အစပိုင်းမှာတော့ code တစ်နေရာတည်းရှိတာကြောင့် ရှာရလွယ်သလို ထင်ရပါတယ်။

အချိန်ကြာလာတာနဲ့ change တစ်ခုလုပ်တိုင်း မဆိုင်တဲ့နေရာကို ထိခိုက်လာတယ်။ UI block တူတာတွေ duplicate ဖြစ်လာတယ်။ State flow ကို နားလည်ဖို့ file တစ်ခုလုံးဖတ်ရတယ်။

ဒီလိုဖြစ်လာတဲ့အခါ component extraction, helper separation, shared hook, reusable UI နဲ့ concern-based organization လိုလာပါတယ်။

Refactoring ရဲ့အဓိကရည်ရွယ်ချက်က line count လျှော့ဖို့မဟုတ်ပါဘူး။

Developer တစ်ယောက် feature တစ်ခုကို ပြင်ချင်တဲ့အခါ ဘယ်နေရာကိုကြည့်ရမလဲဆိုတာ ရှင်းနေဖို့ဖြစ်ပါတယ်။

Code readability ဆိုတာ aesthetic preference မဟုတ်ဘဲ future development speed နဲ့ bug risk ကို သက်ရောက်စေတဲ့ operational advantage ဖြစ်ပါတယ်။

16. UI/UX Iteration မှာ ပထမ Version က အဖြေမဟုတ်ဘူး

Recorder UI, settings dialog, onboarding flow, mobile layout, dark mode နဲ့ error message တွေကို တစ်ကြိမ်တည်းနဲ့ ပြီးသွားတာမျိုး မရှိခဲ့ပါဘူး။

Feature က technically အလုပ်လုပ်ပေမဲ့ user က ဘာနှိပ်ရမလဲ မသိတာ ဖြစ်နိုင်ပါတယ်။

Error message ပြပေမဲ့ user နားမလည်တာ ဖြစ်နိုင်ပါတယ်။ Mobile screen မှာ button ရှိပေမဲ့ လက်နဲ့နှိပ်ဖို့ခက်တာ ဖြစ်နိုင်ပါတယ်။

UI polish ဆိုတာ shadow နဲ့ color လှအောင်လုပ်တာတစ်ခုတည်း မဟုတ်ပါဘူး။

Information hierarchy, button priority, loading feedback, empty state, error recovery နဲ့ screen တစ်ခုရဲ့ next action ကို user က မစဉ်းစားဘဲ သိနိုင်အောင်လုပ်ခြင်းဖြစ်ပါတယ်။

Iteration လုပ်ရင်း သင်ယူခဲ့တာက UX problem တွေကို developer တစ်ယောက်ရဲ့ logic နဲ့ပဲ ကြည့်လို့မရဘူးဆိုတာပါ။

Product ကို ပထမဆုံးမြင်တဲ့ user တစ်ယောက်ရဲ့ confusion ကို လိုက်ကြည့်ရပါတယ်။

17. Error Handling က Edge Case မဟုတ်ဘဲ Main Product Experience ဖြစ်တယ်

Development အစပိုင်းမှာ error handling ကို နောက်မှထည့်ရမယ့် edge case လို့ တွေးမိတတ်ပါတယ်။

Production မှာတော့ network unstable ဖြစ်တာ၊ API rate limit ဖြစ်တာ၊ file type မမှန်တာ၊ external service timeout ဖြစ်တာ၊ empty result ပြန်လာတာနဲ့ session သက်တမ်းကုန်တာတွေဟာ အမြဲဖြစ်နိုင်ပါတယ်။

User အတွက်တော့ system success ဖြစ်တဲ့နေ့ထက် error ဖြစ်တဲ့နေ့မှာ product quality ကို ပိုဆုံးဖြတ်ပါတယ်။

Error ဖြစ်တဲ့အခါ data ပျောက်သွားသလား၊ retry လုပ်လို့ရသလား၊ ဘာဖြစ်နေတာလဲ နားလည်သလား၊ support ကို ဆက်သွယ်ဖို့လိုသလားဆိုတာတွေက ယုံကြည်မှုကို သတ်မှတ်ပေးပါတယ်။

ဒါကြောင့် fallback, retry, friendly error message, safe debug information နဲ့ recoverable state တွေကို design လုပ်ရပါတယ်။

ကောင်းတဲ့ error handling ဆိုတာ error မဖြစ်အောင်လုပ်နိုင်တာမဟုတ်ဘဲ error ဖြစ်လာတဲ့အခါ user ကို တစ်ယောက်တည်းမထားခဲ့တာဖြစ်ပါတယ်။

18. Deployment Workflow ကို နားမလည်ရင် Local မှာအလုပ်လုပ်တာ မလုံလောက်ဘူး

Local development environment မှာ အလုပ်လုပ်နေတဲ့ feature တစ်ခုက preview deployment သို့မဟုတ် production မှာ အတူတူအလုပ်လုပ်မယ်လို့ မဆိုနိုင်ပါဘူး။

Environment variable မတူတာ၊ callback URL မကိုက်တာ၊ preview domain ကို external service က မသိတာ၊ webhook behavior မတူတာနဲ့ build-time configuration ပြဿနာတွေ ရှိနိုင်ပါတယ်။

Preview deployment က code review အတွက်အသုံးဝင်ပေမဲ့ external integration အားလုံး preview environment မှာ အတူတူမရနိုင်ပါဘူး။

Production deployment အတွက် environment separation, secret management, build verification နဲ့ rollback mindset လိုလာပါတယ်။

ဒီ journey ကနေ deployment ကို “code ကို internet ပေါ်တင်ခြင်း” လို့ မမြင်တော့ဘဲ development environment ကနေ real user environment ဆီ safe transition လုပ်ခြင်းလို့ မြင်လာပါတယ်။

19. Dependency Management က Feature မဟုတ်ပေမဲ့ Product Health ဖြစ်တယ်

Project ကြီးလာတဲ့အခါ package တစ်ခုစမ်းပြီး မသုံးတော့တာ၊ UI library နှစ်ခုတူတူရှိနေတာ၊ framework version အဟောင်းနဲ့အသစ် ရောနေတာတွေ ဖြစ်လာတတ်ပါတယ်။

Unused dependency တစ်ခုက harmless လို့ထင်ရပေမဲ့ install time, build size, security surface နဲ့ version conflict ကို တိုးစေနိုင်ပါတယ်။

Migration လုပ်တဲ့အခါလည်း package update button နှိပ်လိုက်ရုံနဲ့ မပြီးပါဘူး။

Framework behavior ပြောင်းတာ၊ API deprecation ဖြစ်တာ၊ styling system ပြောင်းတာနဲ့ database client usage ပြောင်းတာတွေကို လိုက်ပြင်ရပါတယ်။

Dependency cleanup လုပ်ရင်း သင်ယူခဲ့တာက package အများကြီးရှိတာက capability အများကြီးရှိတာနဲ့ မတူဘူးဆိုတာပါ။

Project တစ်ခုမှာ တကယ်လိုအပ်တဲ့ dependency နည်းနည်းကို နားလည်စွာသုံးနိုင်တာက မလိုအပ်တဲ့ package အများကြီးစုထားတာထက် ပိုတည်ငြိမ်ပါတယ်။

20. Testing Mindset က “အလုပ်လုပ်တယ်” ဆိုတဲ့အဓိပ္ပာယ်ကို ပြောင်းပေးတယ်

Developer ကိုယ်တိုင် feature တစ်ခုကို စမ်းပြီး အလုပ်လုပ်သွားရင် ပြီးပြီလို့ ယူဆမိလေ့ရှိပါတယ်။

ဒါပေမဲ့ ကိုယ်သုံးတဲ့ account, ကိုယ်သုံးတဲ့ device, ကိုယ်သိပြီးသား flow နဲ့ စမ်းတာက system ရဲ့ scenario အနည်းငယ်ပဲဖြစ်ပါတယ်။

Security-related behavior, transcription accuracy, route-level validation, payment restore, build configuration နဲ့ production integration တွေကို စနစ်တကျစမ်းဖို့ လိုပါတယ်။

Testing ဆိုတာ bug မရှိကြောင်း သက်သေပြတာမဟုတ်ပါဘူး။

ဘယ်အခြေအနေတွေကို စမ်းပြီးပြီ၊ ဘယ်အခြေအနေတွေကို မစမ်းရသေးဘူးဆိုတာကို သိစေတဲ့ confidence system ဖြစ်ပါတယ်။

Transcription မှာ benchmark sample ရှိတာ၊ backend route မှာ expected error test ရှိတာ၊ release မတင်ခင် build verification လုပ်တာတွေက “ကျနော့်စက်မှာ အလုပ်လုပ်တယ်” ဆိုတာထက် ပိုယုံကြည်ရပါတယ်။

21. Product Strategy က Code ထက်ပိုခက်တဲ့ Decision တွေကို သင်ပေးတယ်

Technical project တစ်ခုနဲ့ real product တစ်ခုကြားကွာခြားချက်က feature အလုပ်လုပ်ခြင်းတစ်ခုတည်း မဟုတ်ပါဘူး။

User က ဘာအတွက်ငွေပေးမလဲ၊ infrastructure cost ကိုဘယ်လိုထိန်းမလဲ၊ lifetime plan နဲ့ recurring usage cost ကို ဘယ်လိုညှိမလဲ၊ ကိုယ့် API key သုံးချင်သူနဲ့ managed cloud သုံးချင်သူကို ဘယ်လိုခွဲပေးမလဲဆိုတာတွေ ရှိပါတယ်။

Agent mode, browser extension နဲ့ platform expansion တို့ကို ထည့်ချင်တိုင်း “လုပ်လို့ရသလား” ဆိုတာတစ်ခုတည်း မမေးတော့ပါဘူး။

“ဒီ feature က core product ကို ပိုကောင်းစေသလား၊ user အတွက် အမှန်တကယ် အသုံးဝင်သလား၊ maintenance cost ဘယ်လောက်တိုးမလဲ” ဆိုတာကိုပါ စဉ်းစားရပါတယ်။

Engineering skill က possibility ကိုဖွင့်ပေးပေမဲ့ Product Strategy က ဘာကိုမလုပ်သင့်သလဲဆိုတာ ဆုံးဖြတ်ပေးပါတယ်။

ဒီကနေ feature များများရှိတာထက် product direction ရှင်းတာ ပိုအရေးကြီးတယ်ဆိုတာ သိလာပါတယ်။

22. Repo Hygiene က သေးငယ်တဲ့ကိစ္စမဟုတ်ဘူး

Project တစ်ခုကို ကြာကြာတည်ဆောက်လာတဲ့အခါ generated files, temporary output, local configuration, abandoned experiments, worktree data, uncommitted changes နဲ့ merge history တွေ စုပြုံလာပါတယ်။

Cleanup လုပ်ချင်တဲ့အခါ မသုံးတော့ဘူးထင်တဲ့ file ကို တန်းဖျက်လိုက်လို့ မရပါဘူး။

Generated file လား၊ source file လား၊ local-only state လား၊ production flow တစ်ခုက အသုံးပြုနေသေးလားဆိုတာ classify လုပ်ရပါတယ်။

Dirty local state ရှိနေချိန်မှာ refactor သို့မဟုတ် branch cleanup လုပ်ရင် ကိုယ်ရေးထားတဲ့အလုပ်ကို မတော်တဆဆုံးရှုံးနိုင်ပါတယ်။

Repo hygiene ဆိုတာ folder တွေသန့်အောင်လုပ်တာမဟုတ်ပါဘူး။

Project history ကို နားလည်လွယ်အောင်၊ contributor အသစ်တစ်ယောက်ဝင်လာတဲ့အခါ မရှုပ်အောင်၊ deploy လုပ်တဲ့အခါ မလိုအပ်တဲ့အရာတွေ မပါအောင်ထိန်းခြင်းဖြစ်ပါတယ်။

ကောင်းမွန်တဲ့ repo တစ်ခုက code သာမက project တည်ဆောက်ခဲ့တဲ့ decision တွေကိုပါ ဖတ်လို့ရသင့်ပါတယ်။

ဒီ Project က ကျနော့်ကို တကယ်သင်ပေးခဲ့တာ

ဒီ project ကို စတင်ခဲ့တဲ့အချိန်မှာ ကျနော်က AI feature ပါတဲ့ application တစ်ခုကို တည်ဆောက်နေတယ်လို့ ထင်ခဲ့ပါတယ်။

အခု ပြန်ကြည့်တဲ့အခါမှာတော့ AI feature တစ်ခုထက် အများကြီးပိုပါတယ်။

AI provider တွေနဲ့ integrate လုပ်ရတယ်။

Audio processing pipeline တွေခွဲရတယ်။

Prompt ကို benchmark နဲ့ စမ်းရတယ်။

Backend boundaries သတ်မှတ်ရတယ်။

Identity, session နဲ့ permission ကို စီမံရတယ်။

Database policy နဲ့ user data ကိုကာကွယ်ရတယ်။

Native iOS feature, payment system နဲ့ App Store distribution ကို ဖြေရှင်းရတယ်။

Web, mobile, wearable, messaging နဲ့ browser environment တွေကြား product experience တစ်ခုတည်းဖြစ်အောင် ချိတ်ဆက်ရတယ်။

Deployment, testing, dependency cleanup နဲ့ repository health ကို ထိန်းရတယ်။

နောက်ဆုံးမှာ pricing, infrastructure cost, access model နဲ့ product roadmap ကိုပါ ဆုံးဖြတ်ရပါတယ်။

Technical term နဲ့ပြောရင် ဒီ journey က ကျနော့်ကို AI integration, Next.js backend, OAuth, Supabase RLS, native iOS, StoreKit, security hardening, deployment, testing, product monetization နဲ့ cross-platform architecture တွေကို လက်တွေ့သင်ပေးခဲ့ပါတယ်။

ဒါပေမဲ့ အဲဒီ technical terms အားလုံးရဲ့နောက်မှာ ပိုကြီးတဲ့ lesson တစ်ခုရှိပါတယ်။

Product တစ်ခုတည်ဆောက်ခြင်းဆိုတာ ကိုယ်သိပြီးသားအရာတွေနဲ့ တည်ဆောက်တာမဟုတ်ပါဘူး။

ကိုယ်မသိသေးတဲ့ ပြဿနာတွေကို တစ်ခုချင်းတွေ့လာပြီး၊ အဲဒီပြဿနာတွေကို နားလည်အောင်လေ့လာပြီး၊ product မပျက်စေဘဲ တဖြည်းဖြည်းဖြေရှင်းသွားတဲ့ process ဖြစ်ပါတယ်။

အစကတည်းက အားလုံးသိထားဖို့ မလိုပါဘူး။

ဒါပေမဲ့ problem တစ်ခုတွေ့တိုင်း patch လုပ်ပြီးကျော်သွားတာထက် ဘာကြောင့်ဖြစ်တာလဲ၊ system design မှာ ဘာပြောင်းသင့်လဲ၊ နောက်ထပ်တစ်ခါမဖြစ်အောင် ဘာသင်ယူရမလဲဆိုတာကို မေးဖို့လိုပါတယ်။

ဒီ project တစ်ခုတည်းက ကျနော့်ကို developer တစ်ယောက်အနေနဲ့ code ပိုရေးတတ်အောင်ပဲ မသင်ပေးခဲ့ပါဘူး။

System တစ်ခုလုံးကို ပိုမြင်တတ်အောင်၊ user ရဲ့အမြင်ကနေ ပိုစဉ်းစားတတ်အောင်၊ security နဲ့ reliability ကို ပိုလေးစားတတ်အောင်၊ technical decision နဲ့ business decision တွေကြားက ဆက်စပ်မှုကို ပိုနားလည်တတ်အောင် သင်ပေးခဲ့ပါတယ်။

အခု ကျနော်ဆက်လေ့လာနေဆဲပါ။

Product ကလည်း ပြီးဆုံးသွားပြီမဟုတ်ပါဘူး။

ဒါပေမဲ့ commit တစ်ခုချင်း၊ bug တစ်ခုချင်း၊ rejected build တစ်ခုချင်းနဲ့ user feedback တစ်ခုချင်းစီက ကျနော့်ကို တဖြည်းဖြည်းပြောင်းလဲပေးခဲ့ပါတယ်။

ဒီလိုနဲ့ idea သေးသေးလေးတစ်ခုကို တည်ဆောက်ရင်း ကျနော်လေ့လာခဲ့တာက feature တစ်ခုရေးနည်းမဟုတ်တော့ဘဲ

Full-Stack AI Product Engineering ကို လက်တွေ့ဘယ်လိုသင်ယူရမလဲဆိုတဲ့ journey တစ်ခု ဖြစ်လာခဲ့ပါတယ်။

ဒီ project က ကျနော့်အတွက် AI bill $2,000 ကျော်ကုန်ခဲ့ပါတယ်။ (ကြွားဝါတာမဟုတ်ပါ Ai တွေမကောင်းသေတဲ့အချိန်မှာ develop လုပ်ခဲ့တာဖြစ်တဲ့အတွက် token ဖို့တွေအများကြီး ကုန်ကျခဲ့ရပါတယ် အခုမှစပြီး ဒီလို project လုပ်မယ်ဆိုရင် ၁၀ ဆလောက် စျေးသက်သက်သာသာနဲ့ လုပ်နိုင်မယ်လို့လဲ ကျနော်ထင်ပါတယ်။)

ကံကောင်းတာတစ်ခုက Prompt to Production v0 မှာ award $1,000 ရခဲ့တာပါ။ နောက်ပိုင်းမှာလည်း v0 referral ကနေ တစ်လကို $200 ဝန်းကျင်ရလာတဲ့အတွက် development cost အများကြီးကို ပြန်ကာမိစေခဲ့ပါတယ်။

ဒီ project ရဲ့ coding journey က v0 နဲ့ စခဲ့ပါတယ်။ နောက်ပိုင်းမှာ Antigravity ကိုပြောင်းသုံးပြီး Claude model နဲ့ Gemini ကိုတွဲသုံးခဲ့တယ်။ အဆုံးပိုင်းမှာတော့ Codex ကိုပါ အသုံးပြုလာခဲ့ပါတယ်။

Back pain, eye strain (dry eye ), blood pressure, stress နဲ့ anxiety တွေပါ ခံစားခဲ့ရပါတယ်။

စာဖတ်ချိန်၊ exercise လုပ်ချိန်၊ podcast နားထောင်ချိန်တွေတောင် လျော့သွားတဲ့ကာလတွေရှိခဲ့ပါတယ်။ Content တွေတောင် အရင်လောက်မတင်ဖြစ်တော့ပါဘူး။

ဒါပေမဲ့ အဲဒီအရာတွေအကုန်ကြားမှာ ဒီ project က ကျနော့်ကို tremendous amount of pleasure နဲ့ lesson တွေ ပြန်ပေးခဲ့ပါတယ်။

ဒီ journey ကိုဖတ်နေတဲ့ vibe coder, founder နဲ့ product developer အားလုံးလည်း ကိုယ့်ရဲ့ dream product ဆီ တစ်ဆင့်ချင်း ရောက်နိုင်ပါစေလို့ ဆုတောင်းပါတယ်။

စေတနာများစွာဖြင့် @thelapyae

I Spent 2,200 Hours Building a Full-Stack AI App