AI নির্মাণ খরচ সহজ করেছি: ফিচার অনুযায়ী ক্রেডিট ও টোকেন পূর্বাভাস করুন, প্রম্পটের পরিধি নির্ধারণ করুন, এবং পুনরায় কাজ এড়িয়ে অ্যাপকে বাজেটের মধ্যে রাখুন।

text\nFeature: Password login\n- Build: low 30 | typical 60 | high 120\n- Test: low 15 | typical 30 | high 60\n- Revise: low 10 | typical 20 | high 40\nSubtotal (typical): 110\n\nBuffer (15%): 17\nLater changes (held): 50\n\n\nপ্রতিটি ফিচারের জন্য এটি পুনরাবৃত্তি করুন (auth, CRUD, একটি ইন্টিগ্রেশন, UI রিফ্রেশ)। "Typical" নেবে আপনার পরিকল্পনার জন্য এবং worst-case চেকের জন্য "high" নেন।\n\n## সাধারণ ফিচার অনুমান: auth ও CRUD\n\nAuth ও CRUD দেখতে সাধারণ, কিন্তু স্কোপ অস্পষ্ট হলে খরচ বেড়ে যায়। এগুলোকে একটি মেনু ভেবে প্রতিটি অপশন যোগ খরচ বাড়ায়।\n\n### Auth: ঠিক কীভাবে কাজ করবে তা নির্দিষ্ট করুন, কেবল "login" বলবেন না\n\nলিখে রাখুন access control কতটা সম্পন্ন হবে। বড় চালকগুলো হল লগইন মেথডের সংখ্যা এবং পারমিশন পথের সংখ্যা।\n\nস্পষ্ট হন:\n\n- লগইন মেথড (ইমেইল/পাসওয়ার্ড, ম্যাজিক লিঙ্ক, Google, Apple, SSO)\n- রোল এবং পারমিশন (admin/editor/viewer, এবং প্রতিটির কি করতে পারবে)\n- পাসওয়ার্ড নিয়ম (লম্বা, জটিলতা, লকআউট, রিসেট ফ্লো)\n- সেশন নিয়ম (মেয়াদ, লগআউট, remember-me অ্যাকশন)\n- অ্যাকাউন্ট লাইফসাইকেল (ইনভাইট, ডিকটিভেট/মুছা, ইমেইল ভেরিফিকেশন)\n\nকেবল "add auth" বললে আপনি একটি জেনেরিক সলিউশন পাবেন এবং পরে এজকেস প্যাচ করতে খরচ বেশি হবে। আকার আগে নির্ধারণ করলে সস্তা হয়।\n\n### CRUD: টেবিল নয়, স্ক্রিন ও নিয়ম গোনুন\n\nCRUD খরচ নির্ধারিত হয় কতটি এনটিটি আছে এবং প্রতিটির জন্য কতটা আচরণ দরকার। একটি ব্যবহারিক মডেল: প্রতিটি এনটিটি প্রায় 3–6 স্ক্রিন বোঝায় (list, detail, create, edit, কখনো admin বা audit view), প্লাস API কাজ ও ভ্যালিডেশন।\n\nCRUD স্কোপ করার সময় এনটিটিগুলো নাম দিন এবং ফিল্ড, টাইপ, ভ্যালিডেশন নিয়ম অন্তর্ভুক্ত করুন (required, unique, range)। তারপর লিস্ট আচরণ নির্ধারণ করুন: ফিল্টার, সোর্টিং, পেজিনেশন, সার্চ। "সার্চ" বলতে একটি সহজ contains ফিল্টার বা অনেক ভারী কিছু বোঝাতে পারে।\n\nএডমিন স্ক্রিন কি ইউজার স্ক্রিন থেকে আলাদা হবে না—এটা ঠিক করুন। পৃথক লেআউট, অতিরিক্ত ফিল্ড, এবং বাল্ক অ্যাকশন কাজে দ্বিগুণ সময় লাগাতে পারে।\n\nযেসব এজকেস দ্রুত খরচ বাড়ায়: রো-লেভেল পারমিশন, অডিট লগ, CSV ইমপোর্ট/এক্সপোর্ট, soft delete, এবং approval workflow। সবকিছু করা যায়, কিন্তু বাজেট পূর্বাভাসযোগ্য থাকে যখন আপনি আগে থেকেই সুনির্দিষ্টভাবে বেছে নেন।\n\n## অনুমান করা ইন্টিগ্রেশনগুলো دونা অনুমান ছাড়া\n\nইন্টিগ্রেশনগুলো খরচ বাড়ায় কারণ তারা কাজ লুকিয়ে রাখে। সমাধান হল: এগুলোকে ছোট, পরীক্ষাযোগ্য অংশে ভাঙ্গা বরং "connect to X" বলার চেয়ে। এতে অনুমান আরও নির্ভরযোগ্য হয় এবং প্রম্পট পরিষ্কার হয়।\n\nএকটি মজবুত ইন্টিগ্রেশন স্কোপ সাধারণত অন্তর্ভুক্ত করে:\n\n- সংযোগ ও authentication (API key বা OAuth, টোকেন রিফ্রেশ)\n- একটি অবজেক্ট end-to-end (হ্যাপি-পাথ রিকোয়েস্ট)\n- সিঙ্ক আচরণ (ওয়েবহুক বা সময় ভিত্তিক, পেজিনেশন, রেট লিমিট)\n- ব্যর্থতা হ্যান্ডলিং (রিট্রাই, idempotency, পুনরায় চালানোর পথ)\n- টেস্টিং ও এজকেস (খারাপ ডেটা, মিসিং পারমিশন, টাইমআউট)\n\nপ্রম্পট করার আগে ডেটা কন্ট্রাক্ট লক করুন। অবজেক্ট ও ঠিক কোন ফিল্ড দরকার তা তালিকাভুক্ত করুন। "Sync customers" অস্পষ্ট। "Sync Customer{id, email, status} and Order{id, total, updated_at}" মডেলকে অতিরিক্ত টেবিল, স্ক্রিন, ও এন্ডপয়েন্ট উদ্ভাবন করা থেকে রোধ করে।\n\nপরবর্তী, দিক এবং ফ্রিকোয়েন্সি ঠিক করুন। একমুখী সিঙ্ক (শুধু ইম্পোর্ট) দ্বিমুখী সিঙ্কের চেয়ে অনেক সস্তা—কারণ দ্বিমুখীতে কনফ্লিক্ট নিয়ম ও বেশি টেস্ট লাগে। যদি দ্বিমুখী দরকার হয়, তখন আগে থেকেই বিজয়ী নিয়ম নির্ধারণ করুন (সোর্স-অফ-ট্রুথ, last-write-wins, বা ম্যানুয়াল রিভিউ)।\n\nব্যর্থতার জন্য পরিকল্পনা করুন যেন এটা নিশ্চয়ই ঘটবে। একটি লগ এন্ট্রি প্লাস অ্যালার্ট এবং একটি ম্যানুয়াল "re-run sync" বোতাম প্রায়ই যথেষ্ট। এটাকে মিনিমাল রাখলে আপনি এমন একটি ফুল-ফ্লেজড অপস সিস্টেমের জন্য টাকাহারা করবেন না যা আপনি চায়নি।\n\nশেষে, থার্ড-পার্টি কুইর্কস এবং টেস্টিংয়ের জন্য 20–40% বাফার যোগ করুন—এটি বাস্তবসম্মত।একটি রেঞ্জ বাজেট করুন কারণ আপনি নির্দিষ্ট ফিচারের জন্য নয়, চেষ্টা/অর্ডারের জন্য অর্থ দিচ্ছেন। খরচ বাড়ে যখন:\n\n- অস্পষ্ট স্কোপ (বেশি ব্যাক-অ্যান্ড-ফোর্থ)\n- দীর্ঘ কনটেক্সট (চ্যাট ইতিহাস + অনেক ফাইল)\n- বড় আউটপুট (পুরা ফাইল পুনর্লিখন)\n- প্রথম ড্রাফটের পরে টেস্টিং ও রিভিশন\n\nএকটি “ছোট” UI পরিবর্তনও ব্যয় বাড়তে পারে যদি সেটা লজিক, ডেটা বা ফ্লো পরিবর্তন করে।
টোকেন হল মডেল পড়ে/লিখে এমন টেক্সটের অংশ (আপনার প্রম্পট, মডেলের আউটপুট, এবং যে কোনো চ্যাট ইতিহাস যা মডেলকে আবার পড়তে হয়)।\n\nক্রেডিট হলো আপনার প্ল্যাটফর্মের বিলিং ইউনিট (সাধারণত মডেল ব্যবহারসহ প্ল্যাটফর্মের কাজগুলোকে কভার করে, যেমন এজেন্ট রান, ফাইল তৈরি, ফলাফল পরীক্ষা)।\n\nবিল্ড স্টেপ হলো প্রকল্পে এক অর্থপূর্ণ পরিবর্তন ("ইমেইল লগইন যোগ করা", "ইউজার টেবিল তৈরি করা", বা "এই স্ক্রিনকে একটি এন্ডপয়েন্টে ওয়্যার করা")। একটি ফিচারে সাধারণত অনেক স্টেপ লাগে এবং প্রতিটি স্টেপ একাধিক মডেল কল ট্রিগার করতে পারে।
ব্যবহারকারী যেভাবে নাম বলবে এমন ফিচারে অনুমান করুন ("পাসওয়ার্ড লগইন", "ইমপ্লয়িজ লিস্ট", "অ্যাসেট অ্যাসাইন")—"স্ক্রিন" বা "মেসেজ" গুনি estimate না করুন। প্রতিটি ফিচারের জন্য তিনটি অংশ বাজেট করুন:\n\n- Build: কোড জেনারেট করে অ্যাপে কানেক্ট করা\n- Test: ফ্লো চালানো ও স্পষ্ট বাগ/কী এজকেস ঠিক করা\n- Revise: কাজ চলাকালে দেখা পর পরিমার্জনা\n\nতারপর low/typical/high রেঞ্জ দিন এবং যোগ করুন।
দুটি স্পষ্ট লাইন যোগ করুন:\n\n- Unknowns buffer: সাধারণত 10–20%\n- Later changes requested: ফিচার স্বীকৃতির পর নতুন ধারণার জন্য আলাদা বালকেট\n\n"পরবর্তীতে চাওয়া" আলাদা রাখলে আপনি মূল অনুমানকে সাধারণ পরিবর্তনের জন্য দোষ দিতে পারবেন না।
লক্ষ্যপূর্ণভাবে লিখুন যে auth পূর্ণ হলে কি হবে। বড় খরচ-চালকগুলো হল:\n\n- লগইন পদ্ধতির সংখ্যা (ইমেইল/পাসওয়ার্ড বনাম ম্যাজিক লিঙ্ক বা SSO)\n- রোল/পারমিশনের পথ সংখ্যা\n- অ্যাকাউন্ট লাইফসাইকেল (ইনভাইট, নিষ্ক্রিয়/ডিলিট, ভেরিফিকেশন)\n- সেশনের নিয়ম (এক্সপায়ারি, লগআউট আচরণ)\n- পাসওয়ার্ড রিসেট ও লকআউট নিয়ম\n\nপ্রেডিক্টেবল খরচ চাইলে এক পদ্ধতি (ইমেইল/পাসওয়ার্ড) এবং 1–2 রোল ধরুন।
CRUD-র খরচ আচরণ নির্ধারণ করে, কেবল টেবিল নয়। প্রতিটি এনটিটির জন্য নির্ধারণ করুন:\n\n- প্রয়োজনীয় স্ক্রিন (list/detail/create/edit + admin/audit views)\n- ফিল্ড, টাইপ, ভ্যালিডেশন নিয়ম\n- লিস্ট আচরণ (ফিল্টার, সোর্ট, পেজিনেশন, সার্চ)\n- পারমিশন নিয়ম (কে কোন সারি দেখবে/সম্পাদনা করবে)\n\nCSV ইমপোর্ট/এক্সপোর্ট, অডিট লগ, অ্যাপ্রুভাল বা রো-লেভেল পারমিশন হলে এগুলো আলাদা ফিচার লাইনে বাজেট করুন।
“Connect to X”কে ছোট, পরীক্ষাযোগ্য টুকরোতে ভাঙুন:\n\n- auth (API key/OAuth + টোকেন রিফ্রেশ)\n- একটি অবজেক্ট end-to-end (হ্যাপি-পাথ)\n- সিঙ্ক আচরণ (ওয়েবহুক vs শিডিউল, পেজিনেশন, রেট লিমিট)\n- failure handling (রিট্রাই, idempotency, পুনরায় চালানোর পথ)\n- অদ্ভুত ডেটা ও টাইমআউট টেস্টিং\n\nডেটা কন্ট্রাক্ট লক করুন (নির্দিষ্ট ফিল্ড তালিকা) যাতে মডেল অতিরিক্ত টেবিল বা এন্ডপয়েন্ট না উদ্ভাবন করে। এক-মুখী সিঙ্ক সাধারণত দ্বিমুখী সিঙ্কের চেয়ে অনেক সস্তা।
UI কাজ হলো যেখানে বাজেট চুপচাপ লিক হয়। "Redesign" বলতে রং বদলানো বা পুরো ফ্লো পুনর্নির্মাণ—তাই কি বদলাচ্ছে তা নামুন: লেআউট, কম্পোনেন্ট, কপি, বা ইউজার স্টেপ।\n\nভিজ্যুয়াল-শুধু পরিবর্তন vs আচরণ-প্রভাবিত পরিবর্তন আলাদা করুন। যদি বোতামের আচরণ, ভ্যালিডেশন, বা ডেটা লোডিং বদলায়, সেটা ফিচার কাজ ধরা উচিত।
সংকীর্ণ প্রম্পট স্ট্রাকচার ব্যবহার করুন:\n\n- লক্ষ্য + ব্যবহারকারী\n- স্ক্রিন ও অ্যাকশন (ক্লিকযোগ্য আচরণ)\n- কোর টেবিল/ফিল্ড (শুধু অপরিহার্যগুলো)\n- প্রতিটি ফিচারের জন্য 2–4 অ্যাক্সেপ্ট্যান্স চেক\n- স্পষ্ট আউট-অফ-স্কোপ তালিকা\n\nতারপর ছোট টুকরো করে বিল্ড করুন (এক এন্ডপয়েন্ট বা এক স্ক্রিন) এবং প্রতিটি চঙ্কের পরে রি-এস্টিমেট করুন।
দুটি ব্যর্থ রিট্রাইয়ের পরে থামুন এবং কেবল শব্দপছন্দ না বদলে ইনপুট বদলান। সাধারণ সমাধানগুলো:\n\n- অভাবিত কনস্ট্রেইন্ট যোগ করা (রোল, নির্দিষ্ট ফিল্ড, নির্দিষ্ট স্ক্রিন)\n- দ্বন্দ্বপূর্ণ চাহিদা সরিয়ে ফেলা\n- ব্যর্থ কেস প্রদর্শন করা (আপনি কী করলেন, কী ঘটলো, কী হওয়া উচিৎ)\n- ছোট ডিফ চাইুন (একটিই জিনিস বদলান)\n\nপ্রতিটি ধাপের শেষে ফাইলগুলোর সংক্ষিপ্ত সারাংশ চাওয়া উচিত যাতে অনিচ্ছাকৃত পরিবর্তন দ্রুত ধরা যায়।