যখন একটি প্রোডাক্ট দুটি হয়ে যায়: শুরু থেকে না বানিয়েই কীভাবে আপনার AI-built app আলাদা করবেন

আপনি শুরু করেছিলেন একটি আইডিয়া দিয়ে। সেটি আপনার AI app builder-কে বর্ণনা করলেন, এটিকে স্ক্রিনগুলো জেনারেট করতে দেখলেন, খসখসে কোণাগুলো এডিট করলেন, আর শিপ করলেন সত্যিকারের একটা কিছু। মানুষ ব্যবহার শুরু করল। আর তারপর, প্রথমে ধীরে ধীরে, ফিডব্যাকে একটা প্যাটার্ন ফুটে উঠল: আপনার অর্ধেক ইউজার একটা জিনিস চাইছেন, বাকি অর্ধেক চাইছেন অন্য কিছু। তারা একই ফিচার নিয়ে ঝগড়া করছিলেন না। তারা চাইছিলেন দুটি আলাদা প্রোডাক্ট।

এই মুহূর্তেই অনেক ফাউন্ডার ভড়কে গিয়ে শূন্য থেকে দ্বিতীয় একটি প্রজেক্ট শুরু করে দেন। সেটা করা উচিত নয়। আপনার একটি প্রোডাক্ট যখন আসলে দুটি হয়ে দাঁড়ায়, তখন একটি AI app আলাদা করার আরও পরিষ্কার একটা উপায় আছে — আর সেটি সাধারণত ইতিমধ্যে বানানো জিনিসের বেশিরভাগটাই রেখে দেয়। এই পোস্টটা হলো কীভাবে এই split চিনবেন, কখন করবেন, আর এই split যে তিনটি রূপ নেয় সেগুলো নিয়ে।

কীভাবে বুঝবেন আপনার দুটি প্রোডাক্ট আছে

সংকেতটা প্রায় কখনোই একটা ফিচার রিকোয়েস্টের মতো দেখায় না। এটা দেখায় ঘর্ষণের মতো।

এমন একটি productivity app আমি এই পথ পেরোতে দেখেছি, যার গল্পটা ছিল স্পষ্ট। এটি বিক্রি হতো “পার্সোনাল প্ল্যানার” হিসেবে। ইউজাররা দুই ধরনের হয়ে আসতে লাগলেন। একদল এটি ব্যবহার করতেন নিজের সপ্তাহের পরিকল্পনা সাজাতে, আর একে দেখতেন একটা ব্যক্তিগত নোটবুকের মতো। আরেকদল চালাতেন ছোট ছোট টিম আর চাইতেন অন্যদের কাজ অ্যাসাইন করতে। দুই দলই একই প্রোডাক্ট ব্যবহার চালিয়ে যাওয়ার মতো যথেষ্ট খুশি ছিলেন, কিন্তু প্রতিটি রিলিজে এক দল খুশি হতো আর অন্য দল বিরক্ত হতো। টিম ভেবেছিল তাদের একটা ফিচার প্রায়োরিটাইজেশনের সমস্যা আছে। আসলে তাদের ছিল একটা ব্র্যান্ডের সমস্যা। তাদের ছিল একটি পার্সোনাল app আর একটি team app, যারা একই কোডবেস, একই হোমপেজ আর একই প্রাইসিং পেজ ভাগ করে নিচ্ছে।

আপনি বুঝবেন যে আপনি সেই সীমা পেরিয়ে গেছেন, যখন এগুলোর কোনো একটা সত্যি হতে শুরু করবে:

• দুই দল অডিয়েন্স একই কথা বিশ্বাস করবে না বলে আপনার ল্যান্ডিং পেজকে তার আসল পিচটা সাধারণ ভাষার আড়ালে চাপা দিতে হচ্ছে।
• প্রতিটা নতুন ফিচারের সঙ্গে একটা “কিন্তু অন্য ধরনের ইউজারের জন্য এটা অন্যভাবে কাজ করা উচিত” শর্ত জুড়ে যাচ্ছে।
• আপনার সাপোর্টের জবাবগুলো শাখা-প্রশাখায় ভাগ হয়ে যাচ্ছে: “আপনি যদি নিজের জন্য ব্যবহার করেন…” বনাম “আপনি যদি একটা টিম ম্যানেজ করেন…”
• একটা উল্লেখযোগ্য সংখ্যক ইউজার দুটি মোড আলাদা রাখতে দুটি আলাদা অ্যাকাউন্ট রাখছেন।

এগুলোর দুটি বা তার বেশি যদি দেখেন, তাহলে আপনার ফিচারের সমস্যা নেই। আপনার আছে একটা product split, যেটা ঘটার অপেক্ষায়।

একটি split-এর তিনটি রূপ

প্রথম দিনেই আপনাকে একটা রূপ বেছে নিতে হবে না। সাধারণত আপনি প্রথমে সবচেয়ে হালকাটা চেষ্টা করে তারপর বাড়াতে পারেন। কিন্তু আপনার AI builder-কে বর্ণনা করা শুরু করার আগে এই মেনুটা জেনে রাখা কাজে দেয়, কারণ আপনি যে শব্দ ব্যবহার করবেন তা-ই ঠিক করে দেবে কী জেনারেট হবে।

রূপ ১: এক app, দুটি দরজা

সবচেয়ে হালকা সংস্করণ। আপনি একটাই কোডবেস রাখেন। প্রথমবার চালু হওয়ার সময় একটা প্রশ্ন যোগ করেন — “আপনি কি নিজের জন্য এসেছেন, নাকি একটা টিমের জন্য?” — আর সেই উত্তর কাজে লাগিয়ে আলাদা একগুচ্ছ পেজ আর আলাদা নেভিগেশন দেখান। একই ডেটা স্টোর। একই লগইন। একই বিলিং। শুধু আলাদা একটা পৃষ্ঠতল।

বেশিরভাগ AI app builder এটা ভালোভাবে সামলায় যদি আপনি এটিকে একটা “two-mode app” হিসেবে বর্ণনা করেন। যেটা খেয়াল রাখতে হবে তা হলো, দুটি মোড সর্বত্র কন্ডিশনাল দেখাও-আর-লুকাও দিয়ে স্ক্রিন ভাগ করবে না। তাতে শেষমেশ এটা দাঁড়ায় একটাই এলোমেলো app, যা দুটো হওয়ার ভান করছে। builder-কে বলুন যে দুটি দরজা আলাদা — আলাদা হোম পেজ, আলাদা সেটিংস পেজ, আলাদা empty state। যে কয়েকটা স্ক্রিন আসলেই ওভারল্যাপ করে (অ্যাকাউন্ট সেটিংস, বিলিং) সেগুলো ভাগ করা যেতে পারে।

কখন এটা কাজ করে: যখন দুই অডিয়েন্স আলাদা ফ্রেমিং চান কিন্তু একই অন্তর্নিহিত অবজেক্ট চান। planner-বনাম-team উদাহরণটা এখানে খাপ খায়। আপনি যেটা শিডিউল করছেন সেটা এখনো একটা task; শুধু অ্যাসাইন, শেয়ার আর নোটিফাই করার নিয়মগুলো বদলায়।

কখন এটা কাজ করে না: যখন দুই অডিয়েন্স পুরোপুরি আলাদা অবজেক্ট আশা করেন। একটা “client portal” আর একটা “internal admin tool”-এর প্রায় কোনো ওভারল্যাপই নেই, এমনকি যদি দেখতে মনে হয় দুটোই একই ব্যবসার ব্যাপার।

রূপ ২: দুটি app, একটি back end

মাঝামাঝি রূপ। আপনি প্রোডাক্টের সামনের অংশটাকে দুটি আলাদা app-এ ভাগ করেন — দুটি URL, দুটি ল্যান্ডিং পেজ, দুটি অনবোর্ডিং ফ্লো, দুটি প্রাইসিং টেবিল — কিন্তু নিচে দুটোই একই ডেটাবেস থেকে পড়ে। একজন কাস্টমার দুটোতেই অ্যাকাউন্ট রাখতে পারেন। একজন অ্যাডমিন দুটোর ডেটাই দেখতে পারেন।

এই ব্লগটা যে কোম্পানি চালায়, আমরা সম্প্রতি ঠিক এটাই করেছি। আমাদের একটা app দুটি অডিয়েন্সকে সেবা দেওয়ার চেষ্টা করছিল: যেসব ইঞ্জিনিয়ার আমাদের এজেন্ট প্ল্যাটফর্ম যাচাই করছিলেন, আর যেসব বিল্ডার আমাদের AI app builder ব্যবহার করছিলেন। একই ব্যাকএন্ড, একই auth, একই ডেটাবেস — কিন্তু সামনের অংশটা দুটি মাথা গজিয়ে ফেলেছিল, আর মেসেজিং তালগোল পাকিয়ে গিয়েছিল। আমরা এটাকে দুটি front-end app-এ ভাগ করলাম, প্রতিটি অডিয়েন্সের জন্য একটি করে। ব্যাকএন্ড একদম যেমন ছিল তেমনই থাকল।

এই রূপটাই সঠিক উত্তর যখন:

• দুই অডিয়েন্স আলাদা কারণে কেনেন।
• অন্য অডিয়েন্সের মার্কেটিং কপি দেখলে তারা বিভ্রান্ত বা বিরক্ত হতেন।
• তারা যে ডেটার ব্যাপারে চিন্তিত সেটার আকার মূলত একই, শুধু ফ্রেমিং আলাদা।
• আপনি দুটি ডেটাবেস বা দুটি বিলিং সেটআপ রক্ষণাবেক্ষণ করতে চান না।

আপনার AI builder-কে বলুন আপনি “বিদ্যমান API ভাগ করে নেয় এমন একটি second front-end app” চান। বেশিরভাগ আধুনিক AI builder একটি সমধর্মী প্রজেক্ট দাঁড় করিয়ে আপনার বিদ্যমান ব্যাকএন্ডের দিকে তাক করিয়ে দিতে পারে। যে ফাঁদটা এড়াতে হবে: প্রথম app-এর কম্পোনেন্ট হুবহু কপি-পেস্ট করা আর তারপর চিরকাল দুটো কপিই এডিট করে যাওয়া। builder-কে বলুন ভাগ করা অংশগুলো (auth স্ক্রিন, কমন ফর্ম উইজেট) একটা ছোট লাইব্রেরিতে বের করে আনতে, যা দুটো app-ই ব্যবহার করে। পরে কয়েক মাসের ডুপ্লিকেট ফিক্স থেকে নিজেকে বাঁচাবেন।

রূপ ৩: দুটি app, দুটি back end

সবচেয়ে ভারী split। আপনার আসলে দুটি প্রোডাক্ট আছে। তারা ডেটা ভাগ করে না, ইউজার ভাগ করে না, আর তাদের একটা রোডম্যাপও ভাগ করা উচিত নয়। সঠিক পদক্ষেপ হলো এগুলোকে পুরোপুরি আলাদা করা: আলাদা কোডবেস, আলাদা ডেটাবেস, আলাদা ডোমেইন।

মানুষ যতটা ভাবে, এই পদক্ষেপটা তার চেয়ে কম ক্ষেত্রেই সঠিক। এটা লোভনীয় কারণ এটা পরিষ্কার মনে হয়। বাস্তবতা হলো, পুরোপুরি আলাদা দুটি app মানে সবকিছুর দুটো করে চালু রাখা — দুটি ডিপ্লয় পাইপলাইন, দুটি অন-কল রোটেশন, দুটি বিলিং ইন্টিগ্রেশন, দুটি হেল্প ডক। প্রোডাক্ট দুটো যদি সত্যিই ওভারল্যাপ না করে, তবেই কেবল এই রূপের দিকে হাত বাড়ান। একটা ভালো পরীক্ষা: যদি প্রোডাক্ট A-এর একজন ইউজার কখনোই প্রোডাক্ট B-এর ইউজার না হতেন, তাহলে আপনার সম্ভবত রূপ ৩ দরকার। আর আপনার বেশিরভাগ ইউজার যদি যুক্তিসঙ্গতভাবে দুটোই চাইতে পারেন, তাহলে আপনি প্রায় নিশ্চিতভাবেই রূপ ২ চান।

AI builder দিয়ে এটা করার সময় সবচেয়ে সহজ পদক্ষেপ হলো দ্বিতীয়টির জন্য আপনার বিদ্যমান প্রজেক্টটা একটা শুরুর পয়েন্ট হিসেবে কপি করা, তারপর builder-কে বলা যেসব ফিচার এখানে মানায় না সেগুলো সরিয়ে দিতে আর যেগুলো মানায় সেগুলো যোগ করতে। দ্বিতীয় প্রজেক্টটা একটা সাদা ক্যানভাস থেকে শুরু করবেন না। প্রথমটা বানাতে গিয়ে আপনি অনেক কিছু শিখে ফেলেছেন, আর আপনি সুযোগ দিলে AI builder সেই কনটেক্সট ধরে ফেলবে।

কিছু আলাদা করার আগে কী করবেন

split-টা আপনার AI builder-কে বর্ণনা করার আগে তিনটে ছোট কাজ করুন। শুনতে যত তুচ্ছ লাগে, এগুলোর দাম তার চেয়ে বেশি।

প্রথমত, প্রতিটি দিকের জন্য নতুন হোম পেজটা লিখুন। প্রতিটির জন্য দুই প্যারাগ্রাফ। পিচ, অডিয়েন্স, আর আপনি তাদের দিয়ে যে একটা কাজ করাতে চান সেটা। আপনি যদি দুটি আলাদা হোম পেজ লিখতে না পারেন, তাহলে আপনার আসলে দুটি প্রোডাক্ট এখনো হয়নি — আপনার শুধু একটা প্রোডাক্টের দুটি সেগমেন্ট আছে, আর সেটা আপনার আর্কিটেকচার দিয়ে নয়, মেসেজিং দিয়ে সমাধান করা উচিত।

দ্বিতীয়ত, কোন স্ক্রিনগুলো ভাগ করা আর কোনগুলো নয়, তার তালিকা করুন। সৎ থাকুন। “লগইন ভাগ করা। অনবোর্ডিং আলাদা। ড্যাশবোর্ড আলাদা। সেটিংস বেশিরভাগই ভাগ করা। বিলিং ভাগ করা।” এই তালিকাটাই হয়ে দাঁড়ায় সেই brief, যেটা আপনি AI builder-কে হাতে ধরিয়ে দেন। এটা অনেক বাড়তি কথাবার্তা বাঁচিয়ে দেয়।

তৃতীয়ত, নিচে কী একই থাকবে তা ঠিক করুন। একই ইউজার? একই ডেটা? একই পেমেন্ট? প্রতিটা “হ্যাঁ” আপনাকে রূপ ১ বা ২-এর দিকে টানে। প্রতিটা “না” আপনাকে রূপ ৩-এর দিকে টানে। এর কোনো সঠিক উত্তর নেই — শুধু সেই উত্তরটাই আছে, যা আপনার প্রোডাক্ট আসলে কীভাবে কাজ করে তার সঙ্গে মেলে।

split-এর পরে কী বদলায়

দুটো জিনিস সহজ হয় আর একটা জিনিস কঠিন হয়।

মার্কেটিং সহজ হয়। প্রতিটি app পায় তার নিজস্ব পরিষ্কার পিচ। প্রতিটি ল্যান্ডিং পেজ একটাই অডিয়েন্সের সঙ্গে কথা বলতে পারে, কোনো রাখঢাক ছাড়া। সাধারণত অন্তত একটা দিকে আপনার কনভার্শন রেট বাড়ে, কখনো কখনো দুই দিকেই।

অনবোর্ডিং সহজ হয়। প্রথমবার আসা একজন ইউজার এমন একটা পেজে নামেন যা তাকে নিয়ে, সবাইকে নিয়ে হওয়ার চেষ্টা করা একটা পেজে নয়।

যেটা কঠিন হয় তা হলো ভাগ করা অংশগুলো সিঙ্ক রাখা। আপনি যদি লগইন ফ্লোতে একটা বাগ ঠিক করেন, আপনি চান সেটা দুটো app-এই ঠিক হোক। আপনি যদি বিলিং স্ক্রিন কেমন দেখায় তা বদলান, আপনি চান দুটো app-ই সেটা প্রতিফলিত করুক। যে শৃঙ্খলাটা আপনার দরকার — আর এটা সত্যি, আপনি AI builder দিয়ে vibe-coding করছেন কি মানুষ ডেভেলপারদের একটা টিম দিয়ে বানাচ্ছেন তা যা-ই হোক — তা হলো ভাগ করা অংশগুলো সত্যিকার অর্থেই ভাগ করা রাখা। ডুপ্লিকেট করবেন না। fork করবেন না। হয় ভাগ করা স্ক্রিনটা একটা ছোট লাইব্রেরিতে বের করে আনুন যা দুটো app-ই ব্যবহার করে, নয়তো মেনে নিন যে আপনার দুটো সত্যিকারের আলাদা app আছে আর সেটার দায়িত্ব নিন।

শেষ করার মতো একটা ছোট প্রশ্ন

আপনি যদি আপনার বর্তমান app-এর পিচ পাঁচজন অপরিচিত মানুষকে শোনান আর তারা প্রত্যেকে এটাকে আলাদাভাবে বর্ণনা করেন — কিন্তু দুটি স্পষ্ট ভাগে — তাহলে আপনি সম্ভবত ইতিমধ্যেই split-এর সঙ্গে বাস করছেন। একমাত্র প্রশ্ন হলো, আপনি কি একটা তালগোল পাকানো প্রোডাক্টের কর খেসারত দিয়ে যাবেন, নাকি দুটো হওয়ার ব্যাপারে সৎ হওয়ার কাজটা করবেন।

আজই সিদ্ধান্ত নিতে হবে না। কিন্তু পরের বার যখন আপনার AI app builder জিজ্ঞেস করবে “এরপর কী বানাব?”, তখন ভেবে দেখুন যে সবচেয়ে কাজের উত্তরটা একটা নতুন ফিচার নাও হতে পারে। সেটা হতে পারে একটা নতুন সদর দরজা।

এটা যদি আপনার মনে দাগ কাটে, তাহলে আমাদের আগের লেখাটাও আপনার ভালো লাগতে পারে — আপনার টিমের জন্য বানানো বনাম কাস্টমারদের জন্য বানানো — একই ধরনের সিদ্ধান্ত, আপনার প্রোডাক্টের জীবনে এক ধাপ আগে।