কীভাবে LLM‑গুলো সরল ইংরেজি ধারণাকে ফুল-স্ট্যাক অ্যাপে রূপান্তর করে

আইডিয়া থেকে অ্যাপ: “রূপান্তর” আসলে কী বোঝায়

একটা “সরল ইংরেজি প্রোডাক্ট আইডিয়া” সাধারণত শুরু হয় উদ্দেশ্য আর আশা মিলিয়ে: কাদের জন্য, কোন সমস্যা সমাধান করে, এবং কীভাবে সাফল্য দেখা যাবে। এটা হতে পারে কয়েকটি বাক্য ("কুকুর হাঁটার জন্য সময় বুক করার অ্যাপ"), একটি অল্প ওয়ার্কফ্লো ("কাস্টমার রিকোয়েস্ট → ওয়াকার অ্যাকসেপ্ট → পেমেন্ট"), এবং কয়েকটি অপরিহার্য ফিচার ("পুশ নোটিফিকেশন, রেটিংস"). ইডিয়াটalking জন্য এইটুকু যথেষ্ট—কিন্তু ধারাবাহিকভাবে তৈরি করার জন্য যথেষ্ট নয়।

যখন কেউ বলে একটি LLM একটি আইডিয়া “translate” করতে পারে, ব্যবহারযোগ্য অর্থ হলো: অস্পষ্ট লক্ষ্যগুলোকে কনক্রিট, টেস্টযোগ্য সিদ্ধান্তে পরিণত করা। “রূপান্তর” শুধু পুনর্লিখন নয়—এটি এমনভাবে স্ট্রাকচার যোগ করা যাতে আপনি রিভিউ, চ্যালেঞ্জ, এবং ইমপ্লেমেন্ট করতে পারেন।

LLM কী দ্রুত তৈরি করতে পারে

LLM‑গুলি কোর বিল্ডিং ব্লকের প্রথম খসড়া তৈরি করতে ভাল:

• ইউজার রোল ও প্রধান জার্নি (যেমন কাস্টমার, প্রোভাইডার, অ্যাডমিন)
• ফিচার লিস্ট ও গ্রহণযোগ্যতা শর্ত ("একজন ব্যবহারকারী ইমেইলের মাধ্যমে পাসওয়ার্ড রিসেট করতে পারে")
• স্ক্রিন ইনভেন্টরি ও UI ফ্লো ওয়েব ও মোবাইলের জন্য
• প্রস্তাবিত আর্কিটেকচার (ফ্রন্টেন্ড অ্যাপ, ব্যাকএন্ড সার্ভিস, ইন্টিগ্রেশন)
• ডাটা মডেল (টেবিল/কলেকশন, সম্পর্ক)
• API আউটলাইন (এন্ডপয়েন্ট, রিকোয়েস্ট/রেসপন্স শেপ)

সাধারণ “ফলাফল” দেখতে পারে একটা ফুল-স্ট্যাক প্রোডাক্টের ব্লুপ্রিন্ট: একটি ওয়েব UI (অ্যাডমিন বা ডেস্কটপ-ওরিয়েন্টেড টাস্কের জন্য), একটি মোবাইল UI (গতি-ভিত্তিক ব্যবহারকারীদের জন্য), ব্যাকএন্ড সার্ভিস (অথ, বিজনেস লজিক, নোটিফিকেশন), এবং ডাটা স্টোরেজ (ডাটাবেজ + ফাইল/মিডিয়া স্টোরেজ)।

কোন জিনিসগুলোতে মানুষের সিদ্ধান্ত দরকার

LLM গুলো আপনার প্রোডাক্টের ট্রেড-অফ স্থায়ীভাবে নির্ধারণ করতে নির্ভরযোগ্যভাবে পারবে না, কারণ সেগুলো নির্ভর করে কনটেক্সটের উপর যা আপনার লিখে না দেয়া থাকতে পারে:

• কী গণ্য হবে “সাফল্য” হিসেবে, এবং কোন মেট্রিকগুলি গুরুত্বপূর্ণ?\n- কোন সীমাবদ্ধতা আছে (বাজেট, টাইমলাইন, কমপ্লায়েন্স, বিদ্যমান টুলস)?\n- কোন এজ-কেসগুলো আপনি গুরুত্ব দেন (আর কোনগুলো পরে রাখতে পারেন)?\n- ব্যবহারকারীরা কোন সিম্পল ভার্সনটিকে এখনও ভালো বলেব?

মডেলকে একটি সিস্টেম মনে করুন যা বিকল্প ও ডিফল্ট প্রস্তাব করে, চূড়ান্ত সত্য নয়।

সতর্কবার্তা (Key risks)

বড় ভ্যাকফেইলিওর মোডগুলো প্রেডিক্টেবল:

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

“রূপান্তর”-এর আসল লক্ষ্য হলো অনুমানগুলো দৃশ্যমান করা—তাই আপনি কোডে পরিণত হওয়ার আগে সেগুলো কনফার্ম, সংশোধন, বা প্রত্যাখ্যান করতে পারেন।

ধাপ 1: প্রোডাক্ট ব্রিফ স্পষ্ট করা

একজন LLMকে “আমাকে X-এর জন্য অ্যাপ বানাও” থেকে স্ক্রীন, API, ও ডাটা মডেলে রূপান্তর করতে হলে আপনার এমন একটি প্রোডাক্ট ব্রিফ দরকার যা ডিজাইন করার জন্য পর্যাপ্ত নির্দিষ্ট। এই ধাপটি অস্পষ্ট উদ্দেশ্যকে একটি শেয়ার করা টার্গেটে পরিণত করার বিষয়ে।

সমস্যাটি শুরু করুন ও কিভাবে আপনি সাফল্য মাপবেন জানুন

এক বা দুই বাক্যে সমস্যা বিবৃতি লিখুন: কে সমস্যায় আছে, কী সমস্যা, এবং কেন এটা গুরুত্বপূর্ণ। তারপর অবজার্ভ করা যায় এমন সাফল্য মেট্রিক যোগ করুন।

উদাহরণ: “এক ক্লিনিকে ফলো-আপ অ্যাপয়েন্টমেন্ট শিডিউল করার সময় কমানো।” মেট্রিক হতে পারে গড় শিডিউলিং সময়, নো-শো রেট, বা স্ব-পরিষেবা দিয়ে বুকিংয়ের শতাংশ।

টার্গেট ইউজার ও প্রধান ইউজকেস নির্ধারণ

প্রাইমারি ইউজার টাইপ(গুলো) তালিকা করুন (প্রতিটি ব্যবহারকারী যিনি সিস্টেমে স্পর্শ করবেন তাদের সব নয়)। প্রতিটি জন্য একটি টপ টাস্ক ও ছোট সিনারিও দিন।

একটি কার্যকর প্রম্পট টেমপ্লেট: “As a [role], I want to [do something] so that [benefit].” লক্ষ্য করুন 3–7টি কোর ইউজকেস যা MVP বর্ণনা করে।

সীমাবদ্ধতাগুলো আগে ধরুন (কারণ এগুলো সবকিছু গঠন করে)

সীমাবদ্ধতাগুলোই একটি ক্লিয়ান পাইলট এবং শিপযোগ্য প্রোডাক্টের মধ্যে পার্থক্য তৈরি করে। অন্তর্ভুক্ত করুন:

• প্ল্যাটফর্ম: ওয়েব, iOS, Android (এবং কোনো অফলাইন চাহিদা)\n- টাইমলাইন ও বাজেট: কোন ট্রেডঅফ গৃহীত হবে\n- কমপ্লায়েন্স/প্রাইভেসি: HIPAA, GDPR, ডাটা রেসিডেন্সি, অডিট লগ\n- ইন্টিগ্রেশন: পেমেন্ট, ক্যালেন্ডার, SSO, CRM, ইমেইল/SMS প্রোভাইডার

“ডান” কী: MVP বনাম পরবর্তী রিলিজ

প্রথম রিলিজে কী থাকবে এবং কী পরে থাকবে সেটি স্পষ্ট করুন। একটি সাধারণ নিয়ম: MVP ফিচারগুলোকে এনড-টু-এন্ড প্রধান ইউজকেসগুলো সাপোর্ট করতে হবে ম্যানুয়াল ওয়ার্কএর ছাড়াও।

ইচ্ছে থাকলে এটিকে এক পৃষ্ঠার ব্রিফ হিসেবে ধরে রাখুন এবং পরবর্তী ধাপগুলোর (রিকোয়ারমেন্ট, UI ফ্লো, আর্কিটেকচার) “সোর্স অফ ট্রুথ” হিসেবে ব্যবহার করুন।

ধাপ 2: সরল ইংরেজি → রিকোয়ারমেন্টে রূপান্তর

একটি সরল আইডিয়া সাধারণত লক্ষ্য ("মানুষকে ক্লাস বুক করতে সাহায্য করা"), অনুমান ("ব্যবহারকারীরা লগইন করবে"), এবং অনির্দিষ্ট স্কোপ ("সহজ করে দাও") মিশ্রিত করে। এখানে LLM কাজে লাগে কারণ এটি বিশৃঙ্খল ইনপুটকে রিকোয়ারমেন্টে রূপান্তর করতে পারে যা আপনি রিভিউ, সংশোধন, ও অনুমোদন করতে পারেন।

বিবৃতিগুলোকে ইউজার স্টোরিতে রূপান্তর করুন

প্রতিটি বাক্যকে ইউজার স্টোরি হিসেবে পুনঃরাওয়াইট করা শুরু করুন। এতে নিশ্চিত হয় কে কী চায় এবং কেন:

• As a new user, I want to sign up with email or Google so I can start quickly.\n- As a returning user, I want to see my upcoming bookings so I can plan my week.

যদি কোনো স্টোরি কোনো ইউজার টাইপ বা সুবিধা নাম না করে, তাহলে সেটি সম্ভবত এখনই খুব অস্পষ্ট।

ফিচার লিস্ট বানান এবং অগ্রাধিকার দিন

তারপর স্টোরিগুলোকে ফিচারে গ্রুপ করুন, এরপর প্রতিটিকে must-have বা nice-to-have লেবেল দিন। এটা ডিজাইন ও ইঞ্জিনিয়ারিং শুরু হওয়ার আগে স্কোপ ড্রিফট প্রতিরোধ করে।

উদাহরণ: “পুশ নোটিফিকেশন” হতে পারে nice-to-have, কিন্তু “বুকিং ক্যানসেল করা” সাধারণত must-have।

মডেল যে পরীক্ষাগুলো চেক করতে পারে এমন গ্রহণযোগ্যতা শর্ত লিখুন

প্রতিটি স্টোরির নিচে সহজ, টেস্টযোগ্য নিয়ম যোগ করুন। ভালো গ্রহণযোগ্যতা শর্ত নির্দিষ্ট ও অবজার্ভেবল:

• Given আমি একটি ভুল ইমেইল লিখি, যখন আমি ফর্ম সাবমিট করি, তখন আমি ইনলাইন ত্রুটির বার্তা দেখি এবং অ্যাকাউন্ট তৈরি হয় না।\n- Given আমি ২৪ ঘণ্টার মধ্যে ক্যানসেল করি, যখন আমি ক্যানসেল নিশ্চিত করি, তখন আমার স্লট মুক্ত হয় এবং আমি একটি কনফার্মেশন মেসেজ পাই।

শুরুতেই এজ-কেসগুলিও তালিকাভুক্ত করুন

LLM‑গুলি প্রায়ই “হ্যাপি পাথ” মানে ডিফল্টে চলে, তাই স্পষ্টভাবে এজ-কেস দাবি করুন:

• অফলাইন মোড বা খারাপ নেটওয়ার্ক (কিউ করা অ্যাকশন, রিট্রাই আচরণ)\n- ভুল ইনপুট (খালি ফিল্ড, অশ-supported ফাইল টাইপ)\n- ক্যানসেলেশন ও ডাবল-সাবমিট (আইডেমপটেনসি, কনফার্মেশন প্রম্পট)

এই রিকোয়ারমেন্ট বান্ডলটি তখন সোর্স অফ ট্রুথ হয়ে যাবে যা আপনি পরবর্তী আউটপুট (UI ফ্লো, API, টেস্ট) মূল্যায়নে ব্যবহার করবেন।

ধাপ 3: ওয়েব ও মোবাইলের জন্য UI ফ্লো ডিজাইন করুন

একটি সরল ইংরেজি আইডিয়া তখনই তৈরি করা যায় যখন এটি ইউজার জার্নি এবং স্পষ্ট ন্যাভিগেশন দ্বারা সংযুক্ত স্ক্রীনে পরিণত হয়। এই ধাপে আপনি রঙ নির্ধারণ করছেন না—আপনি সংজ্ঞায়িত করছেন মানুষ কী করতে পারবে, কোন ক্রমে, এবং সফলতা কীভাবে দেখাবে।

প্রধান ইউজার জার্নিগুলো মানচিত্র করুন

প্রথমে সবচেয়ে গুরুত্বপূর্ণ পথগুলো তালিকাভুক্ত করুন। অনেক প্রোডাক্টের জন্য আপনি সেগুলো এইভাবে গঠন করতে পারেন:

• অনবোর্ডিং: অ্যাকাউন্ট তৈরি, ইমেইল/ফোন ভেরিফিকেশন, প্রথম-বার সেটআপ\n- কোর টাস্ক: অ্যাপের প্রধান কাজ (তৈরি করা, খোঁজা, বুক করা, ট্র্যাক করা, শেয়ার করা)\n- পেমেন্ট: প্রাইসিং ভিউ, চেকআউট, রসিদ, সাবস্ক্রিপশন ম্যানেজমেন্ট (যদি প্রযোজ্য)\n- সাপোর্ট: FAQ, কন্ট্যাক্ট ফর্ম, ইস্যু রিপোর্ট করা\n- সেটিংস: প্রোফাইল, নোটিফিকেশন, প্রাইভেসি কন্ট্রোল, সাইন আউট, অ্যাকাউন্ট ডিলিট

মডেল এসব ফ্লো ধাপে ধাপে শ্রুতিবদ্ধ করতে পারে। আপনার কাজ হলো নিশ্চিত করা কী অপশনাল, কী আবশ্যক, এবং কোথায় ব্যবহারকারী নিরাপদে বের হয়ে আবার ফিরতে পারে।

ওয়েব + মোবাইলের জন্য স্ক্রিন লিস্ট (নেভিগেশন সহ) তৈরি করুন

দুটি ডেলিভারেবল চাইবেন: একটি স্ক্রিন ইনভেন্টরি ও একটি নেভিগেশন ম্যাপ।

• ওয়েব সাধারণত লেফট সাইডবার/টপ ন্যাভ পছন্দ করে যেখানে অপশন বেশি দৃশ্যমান।\n- মোবাইল সাধারণত ট্যাব ও স্ট্যাকেড স্ক্রিন ব্যবহার করে, প্রতি ভিউতে কম অপশন থাকে।

ভালো আউটপুট স্ক্রিনের নামগুলো ধারাবাহিকভাবে দেয় (যেমন “Order Details” বনাম “Order Detail”), এন্ট্রি পয়েন্ট নির্ধারণ করে, এবং খালি অবস্থা (no results, no saved items) যোগ করে।

ফর্ম ও ভ্যালিডেশন রুল

রিকোয়ারমেন্টগুলোকে ফর্ম ফিল্ডে রূপান্তর করুন: আবশ্যক/অপশনাল, ফরম্যাট, সীমা, ও বন্ধুত্বপূর্ণ ত্রুটি বার্তা। উদাহরণ: পাসওয়ার্ড রুলস, পেমেন্ট ঠিকানা ফরম্যাট, বা “তারিখ অবশ্যই ভবিষ্যতের হতে হবে।” নিশ্চিত করুন ভ্যালিডেশন ইনলাইন (টাইপ করার সময়) এবং সাবমিটের ওপর দুটোই ঘটে।

অ্যাক্সেসিবিলিটি বেসিকস

পাঠযোগ্য টেক্সট সাইজ, পরিষ্কার কনট্রাস্ট, ওয়েবে পূর্ণ কীবোর্ড সাপোর্ট, এবং ত্রুটি বার্তা যা কিভাবে সমাধান করতে হয় তা ব্যাখ্যা করবে—শুধু “Invalid input” নয়। প্রতিটি ফর্ম ফিল্ডে লেবেল থাকতে হবে এবং ফোকাস অর্ডার যুক্তিযুক্ত হওয়া উচিত।

ধাপ 4: অ্যাপ আর্কিটেকচার প্রস্তাব করুন

“আর্কিটেকচার” মানে অ্যাপের ব্লুপ্রিন্ট: কোন অংশগুলো থাকবে, প্রতিটি অংশ কী দায়িত্ব পালন করবে, এবং তারা কীভাবে একে অপরের সাথে কথা বলবে। যখন একটি LLM আর্কিটেকচার প্রস্তাব করে, আপনার কাজ হলো নিশ্চিত করা এটি এখনই তৈরি করার জন্য যথেষ্ট সরল এবং পরবর্তীতে বিকশিত করার জন্য পর্যাপ্ত পরিষ্কার।

ডিফল্ট দিয়ে শুরু: মনোলিথ না মডুলার?

অধিকাংশ নতুন প্রোডাক্টের জন্য একটি ব্যাকএন্ড (মনোলিথ) সঠিক শুরু: এক কোডবেস, এক ডিপ্লয়, এক ডাটাবেজ। এটি দ্রুত বানাতে, ডিবাগ করতে সহজ এবং অপারেট করতে সস্তা।

একটি মডুলার মনোলিথ প্রায়ই মিষ্টি জায়গা: এখনও এক ডিপ্লয়, কিন্তু মডিউলে ভাগ (Auth, Billing, Projects ইত্যাদি) করে পরিষ্কার বাউন্ডারি রাখা। সার্ভিস স্প্লিট করার সিদ্ধান্ত তখন নিন যখন বাস্তব চাপ আসে—যেমন উচ্চ ট্রাফিক, আলাদা টিমদের আলাদা ডিপ্লয় দরকার, বা সিস্টেমের কোনো অংশ আলাদা ভাবে স্কেল করলে ভালো হবে।

যদি মডেল তাড়াতাড়ি “মাইক্রোর্সার্ভিস” সুপারিশ করে, তখন এটি কি কংক্রিট প্রয়োজন দিয়ে জাস্টিফাই করছে কিনা জিজ্ঞেস করুন—ভবিষ্যৎকালীন অনুমান নয়।

কোর কম্পোনেন্টগুলো সংজ্ঞায়িত করুন (এবং সেগুলো সাদাসিধে রাখুন)

ভালো আর্কিটেকচার আউটলাইন মৌলিক জিনিসগুলো নাম দেয়:

• Auth & user management: সাইন-আপ/লগইন, রোল, সেশন/টোকেন।\n- Business logic layer: প্রোডাক্টের নিয়ম (প্রাইসিং, অ্যাপ্রুভাল, লিমিট)।\n- Data access: কিভাবে অ্যাপ ডাটাবেজ পড়ে/লিখে।\n- Background jobs: দীর্ঘ-চলমান কাজ (ইম্পোর্ট, রিপোর্ট জেনারেশন, নির্ধারিত টাস্ক)।\n- Notifications: ইমেইল/পুশ/ইন-অ্যাপ, টেমপ্লেট ও পছন্দসমূহ।

মডেলটিকে প্রতিটি অংশ কোথায় থাকবে (ব্যাকএন্ড বনাম মোবাইল বনাম ওয়েব) এবং ক্লায়েন্টগুলো সাধারণত ব্যাকএন্ডের সাথে কীভাবে ইন্টারঅ্যাক্ট করবে (সাধারণত REST বা GraphQL) তা উল্লেখ করা উচিত।

টেক স্ট্যাক অনুমানগুলো স্পষ্ট করুন

আর্কিটেকচার অস্পষ্ট থাকবে যদি আপনি বুনিয়াদি নির্ধারণ না করেন: ব্যাকএন্ড ফ্রেমওয়ার্ক, ডাটাবেজ, হোস্টিং, এবং মোবাইল পদ্ধতি (নেটিভ বনাম ক্রস-প্ল্যাটফর্ম)। মডেলকে এগুলো “Assumptions” হিসেবে লিখতে বলুন যাতে সবাই জানে কী ভিত্তিতে ডিজাইন হচ্ছে।

বেশি-ইঞ্জিনিয়ারিং ছাড়া স্কেলিং পরিকল্পনা

বড় রিফ্যাক্টরের বদলে ছোট “এস্কেপ হ্যাচ” পছন্দ করুন: হট রিডের জন্য ক্যাশিং, ব্যাকগ্রাউন্ড কাজের জন্য একটি কিউ, এবং স্টেটলেস অ্যাপ সার্ভার যাতে পরবর্তীতে আরও ইনস্ট্যান্স যোগ করা যায়। ভালো আর্কিটেকচার প্রস্তাবগুলো এই অপশনগুলো ব্যাখ্যা করে কিন্তু v1-কে সরল রাখে।

ধাপ 5: ডাটা মডেলিং

একটি প্রোডাক্ট আইডিয়া সাধারণত অনেক নামবাচক শব্দে ভরা: “users,” “projects,” “tasks,” “payments,” “messages.” ডাটা মডেলিং হলো সেই ধাপ যেখানে LLM ঐ নামগুলিকে এই সিদ্ধান্তে রূপান্তর করে যে অ্যাপকে কি রাখতে হবে—এবং কিভাবে জিনিসগুলো কনেক্ট হবে।

নামগুলোকে এন্টিটি ও সম্পর্কেতে রূপান্তর করুন

প্রথমে মূল এন্টিটিগুলো তালিকাভুক্ত করুন এবং জিজ্ঞেস করুন: কী কিছুর অধীন? উদাহরণ:

• একটি User অনেকগুলো Projects তৈরি করে\n- একটি Project অনেকগুলো Tasks ধারণ করে\n- একটি Task অনেকগুলো Comments থাকতে পারে

তারপর সম্পর্ক ও কনস্ট্রেইন্ট সংজ্ঞায়িত করুন: একটি টাস্ক কি প্রজেক্ট ছাড়া থাকতে পারে, কনমেন্ট এডিট করা যায় কি না, প্রজেক্ট আর্কাইভ হলে টাস্কগুলো কী হয় ইত্যাদি।

টেবিল/কলেকশন ও প্রয়োজনীয় ফিল্ডগুলো খসড়া করুন

পরবর্তীতে মডেল একটি ফার্স্ট-পাস স্কিমা প্রস্তাব করবে (SQL টেবিল/NoSQL কালেকশন)। সোজা রাখুন এবং সেই সিদ্ধান্তগুলোতে ফোকাস করুন যা আচরণ প্রভাবিত করে।

একটি সাধারণ খসড়া ভেবে দেখতে পারেন:

• users: id, email, name, password_hash/identity_provider_id, created_at\n- projects: id, owner_user_id, name, status, created_at\n- project_members: project_id, user_id, role\n- tasks: id, project_id, title, description, status, due_date, assignee_user_id

গুরুত্বপূর্ণ: “status” ফিল্ড, টাইমস্ট্যাম্প, এবং ইউনিক কনস্ট্রেইন্ট প্রথমেই ধরুন (যেমন ইউনিক ইমেইল)। এসবের উপর UI ফিল্টার, নোটিফিকেশন, ও রিপোর্টিং নির্ভর করে।

মালিকানা, পারমিশন, ও মাল্টি-টেন্যান্ট বিচ্ছিন্নতা

বহু বাস্তব অ্যাপ স্পষ্ট নিয়ম চাই—কে কি দেখতে পাবে। একটি LLM‑কে মালিকানা স্পষ্ট (owner_user_id) এবং অ্যাক্সেস মডেল (memberships/roles) বলে দিতে হবে। মাল্টি-টেন্যান্ট প্রোডাক্টের জন্য (একই সিস্টেমে বহু কোম্পানি), একটি tenant/organization এন্টিটি প্রবর্তন করুন এবং tenant_id সেই সব জিনিসে লাগান যা আলাদা থাকতে হবে।

এছাড়া পারমিশন কিভাবে চাপানো হবে তা সংজ্ঞায়িত করুন: রোল দ্বারা (admin/member/viewer), মালিকানা দ্বারা, না কি উভয়ই।

রিটেনশন, ডিলিশন, ও অডিট লগিং

শেষে নির্ধারণ করুন কী লগ করা হবে এবং কী মুছে ফেলা হবে। উদাহরণ:

• অডিট ইভেন্ট: “task created,” “permission changed,” “export performed”\n- রিটেনশন রুল: ব্যক্তিগত ডাটা অনুরোধে মুছে দিন, ইনভয়েস X বছর রাখুন\n- সফট ডিলিট বনাম হার্ড ডিলিট: রেকর্ড রিকভারেবল রাখবেন নাকি পুরো মুছে ফেলবেন

এই সিদ্ধান্তগুলো কনফর্মেন্স, সাপোর্ট, বা বিলিং সম্পর্কিত প্রশ্ন উঠলে পরে অস্বস্তিকর চমক প্রতিরোধ করে।

ধাপ 6: ব্যাকএন্ড API জেনারেট করা

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

ব্যবহারকারীর ক্রিয়াগুলো শুরু → CRUD + সার্চ

যে মূল বস্তুর সাথে ব্যবহারকারী ইন্টার‌্যাক্ট করে (যেমন Projects, Tasks, Messages) সেগুলো তালিকাভুক্ত করুন। প্রতিটির জন্য সংজ্ঞায়িত করুন ব্যবহারকারী কী করতে পারে:

• Create: নতুন আইটেম যোগ করা\n- Read: এক আইটেম বা তালিকা এনে দেখা\n- Update: ফিল্ড পরিবর্তন করা\n- Delete: মুছে ফেলা/ডিসেবল করা\n- Search/filter: কীওয়ার্ড, স্ট্যাটাস, তারিখ ইত্যাদি দিয়ে খোঁজা

সাধারণত এন্ডপয়েন্টগুলো নেমিং এ ছোঁ রেখে মিলিয়ে যায়, যেমন:

• POST /api/v1/tasks (create)\n- GET /api/v1/tasks?status=open&q=invoice (list/search)\n- GET /api/v1/tasks/{taskId} (read)\n- PATCH /api/v1/tasks/{taskId} (update)\n- DELETE /api/v1/tasks/{taskId} (delete)

রিকোয়েস্ট/রেসপন্স উদাহরণ (সাধারণ ভাষা + JSON)

Create a task: ব্যবহারকারী টাইটেল ও ডিউ ডেট জমা দেয়।

POST /api/v1/tasks
{
  "title": "Send invoice",
  "dueDate": "2026-01-15"
}

রেসপন্স সার্ভার-জেনারেটেড ফিল্ডসহ সেভ করা রেকর্ড রিটার্ন করে:

201 Created
{
  "id": "tsk_123",
  "title": "Send invoice",
  "dueDate": "2026-01-15",
  "status": "open",
  "createdAt": "2025-12-26T10:00:00Z"
}

(উপরের fenced JSON ব্লকগুলো অনুবাদ করবেন না — মূল অবস্থায় রেখে দিন।)

মোবাইল অ্যাপ যা সহ্য করতে পারে এমন ত্রুটি হ্যান্ডলিং

মডেলকে কনসিস্টেন্ট ত্রুটি স্ট্রাকচার দিবে:

• 400 ভ্যালিডেশন ত্রুটি (ফিল্ড-লেভেল মেসেজসহ)\n- 401/403 অথ/পারমিশন সমস্যা\n- 404 না পাওয়া\n- 409 কনফ্লিক্ট (ডুপ্লিকেট, আউটডেটেড আপডেট)\n- 429 অত্যাধিক অনুরোধ (ক্লায়েন্টকে কখন রিট্রাই করতে হবে বলুন)\n- 500 অপ্রত্যাশিত ত্রুটি (জেনেরিক মেসেজ + রিকোয়েস্ট আইডি)

রিট্রাইর জন্য, POST-গুলোর ওপর idempotency keys ব্যবহার এবং “5 সেকেন্ড পর রিট্রাই করুন”-এর মতো স্পষ্ট গাইডলাইন দিন।

ভার্শনিং ও ব্যাকওয়ার্ড কম্প্যাটিবিলিটি

মোবাইল ক্লায়েন্ট ধীরে আপডেট করে—একটি ভার্শনড বেস পাথ (/api/v1/...) ব্যবহার করুন এবং ব্রেকিং চেঞ্জ এড়ান:

• নতুন অপশনাল ফিল্ড যোগ করুন বদলে নাম/রিমুভ না করা\n- ডেপ্রিকেট করার উইন্ডো রাখুন পুরনো ফিল্ডগুলোর জন্য\n- ছোট চেঞ্জলগ এন্ডপয়েন্ট ডকুমেন্ট (উদাহরণ: GET /api/version)

ধাপ 7: ডিফল্ট হিসেবে সিকিউরিটি ও প্রাইভেসি

নিরাপত্তা হল “পরে করা হবে” কাজ নয়। যখন একটি LLM আপনার আইডিয়াকে অ্যাপ স্পেসিফিকেশনে রূপ দেয়, তখন নিরাপদ ডিফল্টগুলো স্পষ্ট করে দিতে চান—তাতে প্রথম জেনারেট করা ভার্সন ভুলবশত অ্যাবিউজ‑যোগ্য না হয়।

Authentication: ব্যবহারকারী কিভাবে নিজেকে প্রমাণ করে

মডেলকে একটি প্রাইমারি লগইন পদ্ধতি এবং একটি ফোলব্যাক প্রস্তাব করতে বলুন, সাথে কী হবে যখন প্রবেশাধিকারের সমস্যা হবে (লস্ট এক্সেস, সন্দেহজনক লগইন)। সাধারণ পছন্দ:

• Email + password (পরিচিত, কিন্তু পাসওয়ার্ড রিসেট, স্ট্রেন্থ রুল এবং ব্রিচ ঝুঁকি হ্যান্ডেল করতে হবে)\n- Magic links / one-time codes (পাসওয়ার্ড ঝুঁকি কমায়, কিন্তু ইমেইল ডেলিভারিবিলিটি ও টোকেনের স্বল্প মেয়াদ নিশ্চিত করতে হবে)\n- Social login (দ্রুত অনবোর্ডিং, কিন্তু তৃতীয় পক্ষের ওপর নির্ভরতা এবং অ্যাকাউন্ট-লিঙ্কিং রুল দরকার)

সেশন হ্যান্ডলিং (শর্ট-লিভড অ্যাক্সেস টোকেন, রিফ্রেশ টোকেন, ডিভাইস-লগআউট) এবং মাল্টি-ফ্যাক্টর সাপোর্ট সম্পর্কে নির্দিষ্টভাবে বলুন।

Authorization: ব্যবহারকারী কী করতে পারবে

Authentication ব্যবহারকারীকে শনাক্ত করে; authorization সীমাবদ্ধ করে। মডেলটিকে একটি পরিষ্কার প্যাটার্ন বেছে নিতে বলুন:

• Roles (Admin, Member, Viewer) সহজ অ্যাপের জন্য\n- Permissions (ফাইন-গ্রেইনড, যেমন project:edit, invoice:export) ফ্যালে আরও নমনীয়তার দরকার হলে\n- Object-level access (গুরুত্বপূর্ণ): ব্যবহারকারীরা শুধুমাত্র তাদের মালিকানাধীন বা এক্সপ্লিসিট শেয়ারকৃত আইটেম দেখতে/লিখতে পারবে

একটি ভালো আউটপুটে নমুনা রুল থাকবে: “শুধুমাত্র প্রজেক্ট মালিকরা একটি প্রজেক্ট ডিলিট করতে পারে; সহযোগীরা এডিট করতে পারে; ভিউয়াররা কমেন্ট করতে পারে।”

নিরাপত্তা চেকলিস্ট যা আপনি চান জেনারেটেড প্ল্যানে

মডেলকে জেনেরিক আশ্বাস নয়, কংক্রিট সুরক্ষা সাবলকগুলো তালিকাভুক্ত করতে বলুন:

• ইনপুট ভ্যালিডেশন ও স্যানিটাইজেশন প্রতিটি এন্ডপয়েন্টে (ক্লায়েন্ট বিশ্বাস করবেন না)\n- রেট লিমিটিং: লগইন, OTP/magic-link অনুরোধ, এবং ব্যয়বহুল এন্ডপয়েন্টগুলোর জন্য\n- সিক্রেট হ্যান্ডলিং: API কী কোডে রেখে না রাখা, ক্রেডেনশিয়াল রোটেশন, টোকেন লগ না করা

একটি বেসলাইন থ্রেট চেকলিস্টও চাইুন: CSRF/XSS সুরক্ষা, সিকিউর কুকি, এবং নিরাপদ ফাইল আপলোড।

প্রাইভেসি বেসিকস: কম সংগ্রহ, পরিষ্কার ব্যাখ্যা

কম ডিফল্টে ডাটা সংগ্রহ করুন: ফিচার সত্যিই যা প্রয়োজন শুধু তাই এবং যত ছোট সময়ের জন্য রাখুন।

মডেলকে প্লেইন‑ল্যাংগুয়েজ কপি খসড়া করতে বলুন:

• আপনি কোন ডাটা সংগ্রহ করেন (এবং কেন)\n- কতদিন রাখেন\n- ব্যবহারকারী কীভাবে ডিলিট বা এক্সপোর্ট করতে পারে

যদি আপনি অ্যানালিটিক্স যোগ করেন, একটি opt-out (বা যেখানে প্রয়োজন opt-in) রাখুন এবং সেটি সেটিংস ও পলিসি পৃষ্ঠায় স্পষ্টভাবে ডকুমেন্ট করুন।

ধাপ 8: মডেল-উৎপন্ন টেস্টিং স্ট্র্যাটেজি

ভালো একটি LLM আপনার রিকোয়ারমেন্টগুলোকে এমন একটি টেস্ট প্ল্যানে রূপান্তর করতে পারে যা আশ্চর্যজনকভাবে ব্যবহারযোগ্য—জদি আপনি এটি গ্রহণযোগ্যতা শর্তের ওপর ল্যাঁচ করেন, সাধারণ “কাজ করা উচিত” বিবৃতি নয়।

গ্রহণযোগ্যতা শর্তের সঙ্গে সরাসরি টেস্ট ম্যাপ করুন

প্রথমে মডেলকে আপনার ফিচার লিস্ট ও গ্রহণযোগ্যতা শর্ত দিন, তারপর বলুন প্রতিটি ক্রাইটেরিয়ার জন্য টেস্ট জেনারেট করো। একটি দৃঢ় আউটপুটে থাকবে:

• ইউনিট টেস্ট বিজনেস রুলের জন্য (প্রাইসিং ক্যালকুলেশন, ভ্যালিডেশন, পারমিশন চেক)\n- ইন্টিগ্রেশন টেস্ট API + ডাটাবেস আচরণের জন্য (উদাহরণ: অর্ডার তৈরি করলে সঠিক রোরা সেভ হয়)\n- এন্ড-টু-এন্ড টেস্ট ক্রিটিক্যাল জার্নিগুলোর জন্য (সাইন আপ → অনবোর্ডিং → প্রথম টাস্ক সম্পন্ন)

যদি কোনো টেস্ট কোনো নির্দিষ্ট ক্রাইটেরিয়ার সাথে লিংক না করে, সেটা সম্ভবত শব্দের অপচয়।

টেস্ট ডাটা ও ফিক্সচার বাস্তব সিনারিওর মতো

LLM‑গুলি এমন ফিক্সচার প্রস্তাব করতে পারে যা বাস্তবে মানুষ কিভাবে অ্যাপ ব্যবহার করে তার আভাস দেয়: ময়লা নাম, মিসিং ফিল্ড, টাইমজোন, লম্বা টেক্সট, এবং “প্রায়-ডুপ্লিকেট” রেকর্ড।

চাইতে পারেন:

• সিড ডেটা সেট (ছোট, মাঝারি) এজ-কেসসহ\n- রিউজেবল ফ্যাক্টরিজ/ফিক্সচার ব্যবহারকারীর, রোল, ও সাধারণ অবজেক্টের জন্য\n- E2E টেস্টের জন্য একটি “গোল্ডেন পাথ” ডাটাসেট

মোবাইল-নির্দিষ্ট চেক যেগুলো লোকেরা ভুলে যায়

মডেলকে একটি মোবাইল চেকলিস্ট যোগ করতে বলুন:

• অফলাইন মোড (রিড-ওনলি বনাম কিউ করা রাইট, কনফ্লিক্ট হ্যান্ডলিং)\n- ব্যাকগ্রাউন্ডিং/ফরগ্রাউন্ডিং (স্টেট রিস্টোরেশন, ইন-ফ্লাইট রিকোয়েস্ট)\n- পারমিশন প্রম্পট (ক্যামেরা, লোকেশন, নোটিফিকেশন) এবং প্রত্যাখ্যানের ফ্লো

LLM দ্বারা টেস্ট জেনারেটের ব্যবহার—কিভাবে রিভিউ করবেন

LLM টেস্ট স্কেলেটন দ্রুত লিখে দিতে পারে, কিন্তু আপনাকে রিভিউ করতে হবে:

• Assertion‑গুলো: কি তারা আউটকাম যাচাই করে, ইমপ্লিমেন্টেশন ডিটেইলে নয়?\n- কভারেজ: ফেলিওর কেসগুলো অন্তর্ভুক্ত (401/403, 422, টাইমআউট)?\n- ফ্লেকিনেস রিস্ক: টাইম-ভিত্তিক ওয়েইট, নেটওয়ার্ক নির্ভরতা, অস্থির সিলেক্টর?

মডেলকে দ্রুত টেস্ট অথর হিসেবে ধরুন—চূড়ান্ত QA সাইন-অফ নয়।

ধাপ 9: ডিপ্লয়মেন্ট, রিলিজ, ও মনিটরিং

মডেল অনেক কোড জেনারেট করতে পারবে, কিন্তু ব্যবহারকারীরা তখনই উপকৃত হবে যখন সেটা নিরাপদে শিপ করা হবে এবং লঞ্চের পর কী হচ্ছে দেখা যাবে। এই ধাপটি পুনরাবৃত্তিযোগ্য রিলিজের বিষয়ে: প্রতিবার একই স্টেপ, কম চমক নিয়ে।

CI বেসিকস (কি স্বয়ংক্রিয় করবেন)

প্রতিটি পুল রিকোয়েস্ট ও মেইন ব্রাঞ্চ মারে একটি সাদাসিধে CI পাইপলাইন চালান:

• লিন্টিং/ফরম্যাটিং কোডে অসামঞ্জস্য ও সাধারণ ভুল ধরতে\n- অটোম্যাটেড টেস্ট (ইউনিট + কিছু E2E “হ্যাপি পাথ” চেক)\n- প্রতিটি সারফেসের বিল্ড স্টেপ:\n - ওয়েব অ্যাপ বিল্ড\n - মোবাইল অ্যাপ বিল্ড (Android/iOS)\n - ব্যাকএন্ড বিল্ড/প্যাকেজ

যদি LLM কোড লিখে দিলেও, CI বলবে সেটা একটা পরিবর্তনের পরে এখনও কাজ করে কিনা।

পরিবেশ: dev, staging, production

তিনটি পরিবেশ ব্যবহার করুন স্পষ্ট উদ্দেশ্য নিয়ে:

• Dev: দ্রুত ইটারেশন, লোকাল ডাটাবেস, ডিবাগ লগিং\n- Staging: প্রোডাকশনের মতো সেটিংসে চূড়ান্ত যাচাইয়ের জন্য\n- Production: প্রকৃত ব্যবহারকারী, কড়া অ্যাক্সেস, কম লগ-নয়েজ

কনফিগারেশন এনভায়রনমেন্ট ভেরিয়েবল ও সিক্রেট দিয়ে হ্যান্ডেল করুন (কোডে হার্ডকোড না)। একটি নিয়ম: যদি মান পরিবর্তন করতে কোড বদলাতে হয়, সম্ভবত সেটি মিসকনফিগারড।

ডিপ্লয়মেন্ট আউটলাইন

একটি সাধারণ ফুল-স্ট্যাকের জন্য:

• ব্যাকএন্ড হোস্টিং: কন্টেইনার বা ম্যানেজড সার্ভিস ডিপ্লয় করুন, তারপর হেলথ চেক চালান\n- ডাটাবেজ মাইগ্রেশন: ভেটিসন মাইগ্রেশন, ডিপ্লয়ের সময় চালান, সম্ভব হলে রিভার্সিবল রাখুন\n- মোবাইল রিলিজ: প্রথমে ইনটার্নাল বিল্ড (TestFlight / internal testing), তারপর স্টেজড রোলআউট অ্যাপ স্টোর/প্লে স্টোরে

মনিটরিং ও ইস্যু ওয়ার্কফ্লো

তিনটি সিগন্যাল পরিকল্পনা করুন:

• লগস (কি ঘটেছে), মেট্রিক্স (কতবার), এবং অ্যালার্ট (এখানে এখন কি করতে হবে)।\n- একটি হালকা-ওজন on-call নিয়ম: অ্যালার্টগুলো অ্যাকশনেবল হওয়া উচিত, নয়তো জাঙ্ক হবে।\n- ব্যবহারকারী-ফেসিং রিপোর্টিং পথ (ইন-অ্যাপ লিঙ্ক বা /support), যা ট্রায়াজ কিউতে যায় severity, reproduction স্টেপ, এবং রোলব্যাক প্ল্যানসহ।

এখানেই এআই-সহায়তায় ডেভেলপমেন্ট অপারেশনাল হয়: আপনি শুধু কোড জেনারেট করছেন না—আপনি একটি প্রোডাক্ট চালাচ্ছেন।

LLM আউটপুটগুলো কোথায় ভুল হয় (এবং কিভাবে ঠিক করবেন)

LLM‑গুলো একটি অস্পষ্ট আইডিয়াকে এমন কিছুতে রূপ দিতে পারে যা দেখতে পুরো পরিকল্পনা—কিন্তু পলিশড প্রোজ়া ফাঁক লুকিয়ে রাখতে পারে। সবচেয়ে সাধারণ ব্যর্থতা প্রেডিক্টেবল, এবং আপনি কয়েকটি পুনরাবৃত্ত অভ্যাসে এগুলো প্রতিরোধ করতে পারেন।

কেন প্রম্পট ব্যর্থ হয়

সবার দুর্বল আউটপুট চারটি কারণে হয়:

• মিসিং কনটেক্সট: মডেল আপনার ব্যবহারকারী, সীমাবদ্ধতা (বাজেট, টাইমলাইন, টিম স্কিল), কমপ্লায়েন্স চাহিদা, বা বিদ্যমান কী আছে জানে না।\n- বিরোধী চাহিদা: “সহজ বানাও” সঙ্গে “প্রতিটি এজ-কেস সাপোর্ট করো” মিশলে স্পেসিফ অস্পষ্ট হবে।\n- লুকানো অনুমান: মডেল ধরে নিতে পারে লগইন ইমেইল/পাসওয়ার্ড, “রিয়েল-টাইম” মানে WebSockets, বা “অ্যাডমিন” মানে পূর্ণ ডাটা অ্যাক্সেস।\n- অঘোষিত অগ্রাধিকার: স্পষ্ট ট্রেড-অফ না থাকলে আপনি জেনেরিক উত্তর পাবেন যা আপনার পরিস্থিতিতে মানাবে না।

কিভাবে উন্নত আউটপুট চাইবেন

মডেলকে কাজ দেওয়ার সময় কংক্রিট ম্যাটেরিয়াল দিন:

• উদাহরণ: “Calendly-এর মত বুকিং, কিন্তু অন-সাইট সার্ভিসের জন্য” এবং 2–3টা sample ইউজ স্টোরি।\n- সীমাবদ্ধতা: “Postgres ব্যবহার করতে হবে, AWS-এ ডিপ্লয়, এবং 10k MAU সাপোর্ট করতে হবে।”\n- কার্যপ্রণালী ভাবতে বলুন: অনুমান, ওপেন প্রশ্ন, ও বিকল্প দেখান: “Show your work: decisions + why.”

রিওয়ার্ক কমানোর জন্য “Definition of Done” যোগ করুন

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

একক সোর্স অফ ট্রুথ রাখুন

LLM আউটপুট ভিন্ন জায়গায় ছড়িয়ে গেলে ড্রিফট হয়। একটি জীবন্ত ডকুমেন্ট (একটি সাধারণ মার্কডাউন ফাইলও চলবে) যেটা লিঙ্ক করে:

• প্রোডাক্ট স্পেক,\n- API কনট্রাক্ট (এন্ডপয়েন্ট + স্কিমা),\n- এবং ডিজাইন নোট (কী জার্নি ও এজ-কেস)

যখন আপনি আবার প্রম্পট দেবেন, লেটেস্ট এক্সার্পট পেস্ট করুন এবং বলুন: “Update only sections X and Y; keep everything else unchanged.”

যদি আপনি ইমপ্লিমেন্ট করতে করতে যেতে চান, এমন একটি ওয়ার্কফ্লো ব্যবহার করুন যা দ্রুত ইটারেশন সমর্থন করে এবং ট্রেসেবিলিটি রাখে—উদাহরণস্বরূপ Koder.ai-এর “planning mode” এই খাতে মানায়: আপনি স্পেস (assumptions, open questions, acceptance criteria) লক করতে পারেন, ওয়েব/মোবাইল/ব্যাকএন্ড স্ক্যাফোল্ডিং একই চ্যাট থ্রেড থেকে জেনারেট করতে পারেন, এবং স্ন্যাপশট/রোলব্যাক ব্যবহার করে পরিবর্তনগুলো যদি রিগ্রেশন আনে তবে ফিরে যেতে পারেন। সোর্স কোড এক্সপোর্ট বিশেষভাবে দরকারী যখন আপনি চান আপনার জেনারেটেড আর্কিটেকচার আর আপনার রেপো সঙ্গত থাকে।

একটি ব্যবহারিক ওয়াকথ্রু এবং মানব রিভিউ পয়েন্ট

এখানে কিভাবে “LLM রূপান্তর” এন্ড-টু-এন্ড দেখাতে পারে—প্লাস চেকপয়েন্ট যেখানে মানুষ ধীর হতে হবে ও বাস্তব সিদ্ধান্ত নেবে।

একটি সংক্ষিপ্ত উদাহরণ: আইডিয়া → স্ক্রিন, ডাটা, API

সরল-ইংরেজি আইডিয়া: “একটি পেট-সিটিং মার্কেটপ্লেস যেখানে মালিকরা রিকোয়েস্ট পোস্ট করে, সিটাররা আবেদন করে, এবং কাজ শেষে পেমেন্ট রিলিজ হয়।”

একটি LLM এটি প্রথম খসড়া করে দিতে পারে:

• স্ক্রীন: Sign up/login, Create Request, Request Details (with applicants), Apply to Request, In-App Chat, Checkout, Job Completion, Ratings/Reviews, Admin (disputes).\n- ডাটা মডেল: Users (role: owner/sitter), PetProfiles, Requests (dates, location, status), Applications, Messages, Payments, Reviews.\n- API: POST /requests, GET /requests/{id}, POST /requests/{id}/apply, GET /requests/{id}/applications, POST /messages, POST /checkout/session, POST /jobs/{id}/complete, POST /reviews.

এটি দরকারী—কিন্তু এটা “ডান” নয়। এটা একটি কাঠামোবদ্ধ প্রস্তাব যা যাচাই প্রয়োজন।

মানুষ কোথায় রিভিউ করবে (এবং কেন গুরুত্বপূর্ন)

প্রোডাক্ট সিদ্ধান্ত: একটি “application” কবে বৈধ? মালিক কি সরাসরি কাউকে আমন্ত্রণ করতে পারে? একটি রিকোয়েস্ট কখন “filled” ধরা হবে? এই নিয়মগুলো প্রতিটি স্ক্রীন ও API প্রভাবিত করে।

নিরাপত্তা ও প্রাইভেসি রিভিউ: রোল-ভিত্তিক এক্সেস নিশ্চিত করুন (মালিকরা অন্য মালিকদের চ্যাট পড়া পারবে না), পেমেন্ট সুরক্ষিত করুন, এবং ডাটা রিটেনশন নির্ধারণ করুন (উদাহরণ: চ্যাট X মাস পর মুছুন)। অ্যাবিউজ কন্ট্রোল যোগ করুন: রেট লিমিট, স্প্যাম প্রতিরোধ, অডিট লগ।

পারফরম্যান্স ট্রেডঅফ: কি দ্রুত ও স্কেলেবল হতে হবে (সার্চ/ফিল্টার, চ্যাট)? এটি ক্যাশিং, পেজিনেশন, ইনডেক্সিং, ও ব্যাকগ্রাউন্ড কাজ প্রভাবিত করে।

ইটারেশন লুপ: ফিডব্যাক → রিকোয়ারমেন্ট → কোড

একটি পাইলটের পরে ব্যবহারকারীরা চাইতে পারে “রিকোয়েস্ট রিপিট করুন” বা “পার্শিয়াল রিফান্ডের সঙ্গে ক্যানসেল”। এই আপডেটগুলোকে রিকোয়ারমেন্ট হিসেবে ফের উপস্থাপন করুন, প্রাসঙ্গিক ফ্লোগুলো পুনরায় জেনারেট/প্যাচ করুন, তারপর টেস্ট ও সিকিউরিটি চেকগুলো পুনরায় চালান।

মেইনটেনএবল হওয়ার জন্য কি ডকুমেন্ট করবেন

“কেন” ধরুন, শুধু “কী” নয়: মূল বিজনেস রুল, পারমিশন ম্যাট্রিক্স, API কনট্রাক্ট, এরর কোড, ডাটাবেস মাইগ্রেশন, এবং রিলিজ/ইনসিডেন্ট রেসপন্সের সংক্ষিপ্ত রানবুক। এটা সেই জিনিসগুলো যা জেনারেটেড কোডকে ছয় মাস পরে বোঝার যোগ্য রাখে।