আমি এই প্রোডাক্টটি পুরোপুরি একাই বানিয়েছি—মূলত রাতে, সপ্তাহান্তে আর স্বীকার করতে চাই তার চেয়ে বেশি ছুটির দিন খরচ করে। অনেক দিন পর্যন্ত ওয়েবে থাকা সত্ত্বেও এটা আমার কাছে ব্যক্তিগত একটা প্রজেক্টের মতোই লাগত।
পেমেন্ট চালু করার মুহূর্তে সেই অনুভূতি বদলে গেল। কোড হঠাৎ আরও sophisticated হয়ে যায়নি, কিন্তু প্রোডাক্টের প্রতি আমার দায়িত্ব বদলে গেছে। কেউ টাকা দিতে পারলে broken flow আর শুধু পরে ঠিক করার মতো অসম্পূর্ণ edge case থাকে না। onboarding, moderation, retention, trust আর reliability ভবিষ্যতের সমস্যা না থেকে তখনই প্রোডাক্টের প্রতিশ্রুতির অংশ হয়ে যায়।
লঞ্চ থেকে আমার সবচেয়ে গুরুত্বপূর্ণ শিক্ষা এটাই: অনেক feature-ওয়ালা solo project বানানো আর বাস্তব একটি product operate করা দুই রকম কাজ।
Solo development-এ attention-ই bottleneck হয়ে গেল
প্রোডাক্টটি বানানোর সময় আমি social media থেকে প্রায় অদৃশ্য হয়ে গিয়েছিলাম। এটা launch strategy ছিল না। product decision, implementation, edge case, flow testing আর release preparation একই সীমিত সময়ের জন্য প্রতিযোগিতা করছিল।
এখন solo development-এর এই অংশটা অনেক ভালো বুঝি। bottleneck সব সময় আমি কত দ্রুত code লিখি তা নয়। আসল সীমা হলো product-এর বাড়তে থাকা state, transition আর failure mode-এ কত attention দিতে পারি।
successful build এই প্রশ্নগুলোর উত্তর দেয় না। successful payment-ও দেয় না।
Payments bug-এর অর্থ বদলে দিয়েছে
payments-এর আগে কিছু rough edge-কে “পরে ঠিক করব” বলে ভাবতে পারতাম। payments live হওয়ার পর সেই mental model আর কাজে লাগেনি। paid product bug-free হতে হবে—এমন কথা বলছি না; সেটা বাস্তবসম্মত নয়। কিন্তু অন্য কেউ টাকা দিয়ে product-এ trust দেখানোর পর known problem ফেলে রাখার cost বদলে যায়।
onboarding আর moderation-এর ক্ষেত্রেও একই ব্যাপার। development-এর সময় এগুলো “main” feature-এর পাশের supporting system বলে মনে হতে পারে। production-এ user এগুলো সরাসরি experience করে, তাই এগুলো feature-এরই অংশ। retention-ও একই রকম: ভালো first session মানেই product ফিরে আসার কারণ দিয়েছে—এটা প্রমাণ হয় না।
payments প্রোডাক্টটি finished—এটা প্রমাণ করেনি। বরং “finished” শব্দটার পেছনে কত কাজ লুকিয়ে ছিল সেটা দেখিয়েছে।
Launch আমাকে অন্য ধরনের information দিয়েছে
release-এর পর শুরু হয়েছে কম photogenic কাজ: publish করার পরই দেখা যায় এমন bug, broken flow, user এলে বাস্তব হয়ে ওঠা moderation problem, আর ভালো first impression-এর চেয়ে অনেক কঠিন retention প্রশ্ন।
আমি এসব signal অতিরিক্ত interpret না করার চেষ্টা করি। release-এর পরে bug মানেই architecture খারাপ—এটা বলা যায় না। retention problem একাই product-market fit diagnose করে না। moderation issue মানেই পুরো system unsafe—এটাও প্রমাণ হয় না। symptom কোথায় investigate করতে হবে সেটা দেখায়; cause নিজে থেকে বলে দেয় না।
যেটা বদলেছে সেটা evidence-এর quality। launch-এর আগে আমি test করি মানুষ কী করবে বলে আমি আশা করি। launch-এর পরে আমাকে সামলাতে হয় তারা আসলে কী করে। release uncertainty মুছে দেয় না; বরং গুরুত্বপূর্ণ uncertainty-এর কিছু অংশ প্রথমবার observable করে।
এখন যে post-launch loop ব্যবহার করি
এখন launch story polish করার চেয়ে launch-এর পরের কাজ আমাকে বেশি আগ্রহী করে: payment lesson, broken flow, moderation challenge, user behavior, retention surprise আর product-কে ধীরে ধীরে dependable করে এমন ছোট fix।
- Real flow দেখি। আমি যে path design করেছি user-ও সেটাই নেবে—এটা ধরে নিই না।
- Symptom আর cause আলাদা করি। কোনো step fail করলে কোথায় সমস্যা হয়েছে বোঝা যায়; কেন হয়েছে তা নয়।
- Trust-sensitive failure আগে দেখি। payments, access, onboarding আর moderation cosmetic imperfection-এর চেয়ে urgent, কারণ failure cost বেশি।
- সবচেয়ে ছোট verified problem আগে ঠিক করি। অনুমান ধরে পুরো system redesign করার বদলে confirmed friction point দূর করতে চাই।
- Fix-এর পরে user experience আবার check করি। code change technically correct হলেও user-facing problem থেকে যেতে পারে।
এটা universal framework নয়। বানানো থেকে operate করার পর্যায়ে এসে এই discipline-টাই আমার কাছে সবচেয়ে যৌক্তিক লাগছে।
Launch আমার source of truth বদলে দিয়েছে
এখন আমার কাছে সবচেয়ে গুরুত্বপূর্ণ পার্থক্য হলো product বানিয়ে ফেলা আর product operate করার জন্য প্রস্তুত হওয়া। building জিজ্ঞেস করে system design অনুযায়ী কাজ করছে কি না। operating জিজ্ঞেস করে real মানুষ ব্যবহার করলে, ভুল বুঝলে, চলে গেলে, ফিরে এলে, pay করলে বা unexpected path-এ গেলে কী হয়।
তাই launch-কে আর finish line মনে করি না। launch-এর আগে evidence-এর বেশিরভাগ আসে আমার assumption আর test থেকে। launch-এর পরে product real behavior, failure আর repeat use-এর মাধ্যমে উত্তর দিতে শুরু করে।