AI-নির্মিত অ্যাপগুলির জন্য এক-পৃষ্ঠার স্পেস টেমপ্লেট

কেন Planning Mode গুরুত্বপূর্ণ যখন আপনার ধারণা এখনও অস্পষ্ট\n\nঅস্পষ্ট ধারণা দিন-কাটার জন্য ঠিক আছে। নির্মাণের জন্য তা ঝুটছাঁট।\n\nযখন আপনি AI বিল্ডারকে শুধু বলেন “একটা হ্যাবিট ট্র্যাক করার অ্যাপ” এবং বেশি কিছু বলেন না, তখন AI-কে অনুমান করতে হয় আপনি কী বলতে চেয়েছেন। সেই অনুমানগুলো প্রতিটি প্রম্পটে বদলায়, ফলে অ্যাপও বদলে যায়। ফলাফল: স্ক্রীনগুলো মিলেনা, ডাটা নির্মাণের মাঝেই নাম বদলে যায়, এবং ফিচারগুলো আসে, যায়, পরে ভিন্ন আকারে ফের দেখা দেয়।\n\nএই অসামঞ্জস্য সাধারণত কয়েকটি জায়গায় দেখা যায়:\n\n- ব্যবহারকারীর সম্পর্কে ভিন্ন ধারণা (ব্যক্তিগত ব্যবহারকারী বনাম টিম)\n- বিরোধী ওয়ার্কফ্লো (প্রথমে লগ করা না কি প্রথমে তৈরি করা)\n- ডেটার নাম পাল্টা (habit বনাম routine বনাম goal)\n- মিসিং এজ কেস (কিছু ডিলিট করলে কী হবে)\n\n“Planning Mode” হলো বিল্ডিং শুরু করার আগে একটি সহজ বিরতি। আপনি সেই সিদ্ধান্তগুলো লিখে রাখেন যেগুলো না লিখে দিলে AI নিজে থেকেই বানিয়ে ফেলত। উদ্দেশ্য হলো সামঞ্জস্য: UI, ব্যাকএন্ড ও ডাটাবেস একই সেট সিদ্ধান্ত অনুসরণ করবে।\n\nলক্ষ্য পারফেকশনে পৌঁছানো নয়। লক্ষ্য হলো এমন একটি বিল্ড যা বারবার অনুমানের উপর প্যাচ করতে হয় না। যদি পরে মনের পরিবর্তন হয়, আপনি এক ছোট স্পেস আপডেট করে একই লজিকে পুনর্নির্মাণ করবেন।\n\nএই কারণেই এক-পৃষ্ঠার অ্যাপ স্পেস টেমপ্লেট গুরুত্বপূর্ণ। এটা বড় PRD নয় এবং নয় সপ্তাহব্যাপী ডায়াগ্রাম। এটা এক পৃষ্ঠা যা চারটি কথা উত্তর দেয়: ব্যবহারকারী কাদের, তারা কী করতে চায়, কী ডেটা আছে (সরল ভাষায়), এবং কোন এজ কেস বা নন-গোলগুলো প্রথম সংস্করণকে বিস্ফোরিত হতে থেকে রোধ করে।\n\nউদাহরণ: “একটি বুকিং অ্যাপ” অনেকটা পরিষ্কার হয় যখন আপনি সিদ্ধান্ত নেন এটা কি একটি একক স্যালন মালিকের জন্য নাকি একটি মার্কেটপ্লেস, এবং গ্রাহকরা রিস্কেডিউল বা ক্যানসেল করতে পারবে কিনা।\n\n## এক মিনিটে ব্যাখ্যা: এক-পৃষ্ঠার স্পেস টেমপ্লেট কি\n\nএক-পৃষ্ঠার অ্যাপ স্পেস টেমপ্লেট হলো একটি ছোট নোট যা অস্পষ্ট ধারণাকে স্পষ্ট নির্দেশে বদলে দেয়। আপনি পুরো প্রোডাক্ট ডিজাইন করছেন না। আপনি AI বিল্ডারকে এতটা কাঠামো দিচ্ছেন যাতে সে প্রতি বার একই সিদ্ধান্ত নেয়।\n\nপাতাটি চারটি ব্লক ধারণ করে। যদি এক পাতায় না ফিট করে, সম্ভবত আপনার প্রথম বিল্ডের জন্য খুব বেশি ফিচার আছে।\n\n- Users: কে ব্যবহার করে (2–3 টাইপ) এবং তারা কীভাবে আলাদা।\n- Jobs-to-be-done: প্রতিটি ব্যবহারকারী কী অর্জন করতে চায়, আউটকাম হিসেবে লেখা।\n- Entities: আপনি কী কী স্টোর এবং ট্র্যাক করবেন (ডেটা নামগুলো)।\n- Edge cases + non-goals: কি ভাঙতে পারে এবং আপনি এখনই কী বানাবেন না।\n\nএক পৃষ্ঠা দরকারি সীমা আরোপ করে। এটা আপনাকে একটি প্রাথমিক ব্যবহারকারী নির্বাচন করতে প্ররোচিত করে, সবচেয়ে ছোট সফল ফ্লো নির্ধারণ করতে সাহায্য করে, এবং “সবকিছু সাপোর্ট করব” এর মতো অস্পষ্ট প্রতিশ্রুতিকে এড়ায়। এই সীমাগুলোই AI-নির্মিত অ্যাপকে এক বিল্ড থেকে পরের বিল্ডে মন পাল্টিয়ে ফেলতে বাধা দেয়।\n\n“পর্যাপ্ত” স্তরের ডিটেইল সাধারণ, টেস্টেবল বিবৃতির মত হওয়া উচিত। কেউ যদি পড়ে এবং জিজ্ঞেস করে, “এটা কিভাবে জানবো কাজ করেছে?” আপনি সঠিক স্তরে আছেন।\n\nএকটি দ্রুত মানদণ্ড:\n\n- নতুন ব্যবহারকারী প্রধান কাজ ২ মিনিটের মধ্যে সম্পন্ন করতে পারে।\n- প্রতিটি কাজের একটি স্পষ্ট শুরু ও শেষ আছে (কোনও অবিরত “কিছু ম্যানেজ করা” নয়)।\n- প্রতিটি সত্তার ৩–৭ ফিল্ড আছে যা আপনি এখনই ব্যবহার করবেন।\n- শীর্ষ ৫ এজ কেস নামকরণ করা আছে (ডুপ্লিকেট, পারমিশন, খালি স্টেট, ব্যর্থতা, ভুল ইনপুট)।\n\nভাষা সরল রাখুন। এমন লাইন লিখুন যেগুলো আপনি সরাসরি প্রম্পটে পেস্ট করতে পারবেন, উদাহরণ: “A manager can approve or reject a request, and the requester gets a status update.”\n\n## ধাপে ধাপে: ২০ মিনিটে টেমপ্লেট পূরণ করুন\n\n২০ মিনিট টাইমার সেট করুন এবং “বিল্ড করার জন্য যথেষ্ট পরিষ্কার” লক্ষ্য করুন, “পারফেক্ট” নয়। উদ্দেশ্য হলো অনুমান দূর করা যাতে আপনার AI বিল্ডার প্রতি বার একই সিদ্ধান্ত নেয়।\n\nএক বাক্যে শুরু করুন: এটা কার জন্য এবং তারা কী ফল পাবে?\n\nউদাহরণ: “A mobile app for dog owners to track walks and vet visits in one place.”\n\nযদি এক বাক্যে বলা না যায়, তাহলে ধারণাটা সম্ভবত দুইটি অ্যাপ।\n\nএরপর 1 থেকে 3 ব্যবহারকারী টাইপ নাম দিন প্রকৃত মানুষের মতো, বিমূর্ত রোল নয়। “Owner,” “Vet,” এবং “Family member” বলতে পারলে “User A”–র থেকে অনেক ভাল। প্রতিটির জন্য একটা ছোট লাইন যোগ করুন তারা সবচেয়ে কী নিয়ে চিন্তিত।\n\nতারপর 3 থেকে 7 টি Jobs-to-be-done লিখুন এই ফরম্যাটে: “When [situation], I want to [action], so I can [result].” টেস্টেবল রাখুন। “When I finish a walk, I want to log distance and notes, so I can spot patterns” এটা “track health”–এর চেয়ে অনেক পরিষ্কার।\n\nএখন আপনার সত্তাগুলো এবং মূল ফিল্ডগুলো ডাটাবেস কথায় না লিখে সংজ্ঞায়িত করুন। “অ্যাপ যে কী মনে রাখে” ভাবুন। কুকুর অ্যাপের জন্য: Dog (name, age), Walk (date, duration, notes), Visit (date, clinic, cost). যদি কোনো ফিল্ড স্ক্রিন বা জবে ব্যবহৃত না হয়, সেটি বাদ দিন।\n\nশেষে দুইটি ছোট ব্লক: এজ কেস এবং নন-গোল। এজ কেসগুলো বিরক্তিকর কিন্তু সাধারণ (“ইন্টারনেট নেই”, “একই নামের দুইটি কুকুর”)। নন-গোলগুলো হলো আপনি এখনই কী বানাবেন না (“পেমেন্ট নেই”, “সোশ্যাল ফিড নয়”)।\n\nশেষে প্রতিটি ব্লককে এমনভাবে প্রম্পটে রূপান্তর করুন যে আপনার বিল্ডার অনুসরণ করতে পারে। স্ট্রাকচারটি ধারাবাহিক রাখলে (উদ্দেশ্য, ব্যবহারকারী, কাজ, সত্তা, এজ কেস) সিস্টেম এমন স্ক্রীন, ডেটা ও ফ্লো জেনারেট করবে যা মিলে।\n\n## ব্যবহারকারী ও jobs-to-be-done যা AI বাস্তবে অনুসরণ করতে পারে\n\nযদি আপনার স্পেস বলে “সবার জন্য,” তাহলে AI-কে প্রথমে কী বানাতে হবে তা অনুমান করতে হবে। এক-পৃষ্ঠার স্পেস টেমপ্লেটে ব্যবহারকারীদের উদ্দেশ্য (intent) অনুযায়ী সংজ্ঞায়িত করুন, ডেমোগ্রাফিক নয়। উদ্দেশ্য স্পষ্ট পছন্দ দেয় স্ক্রীন, ডাটা ও পারমিশন নিয়ে।\n\n2–4 ব্যবহারকারী টাইপ নামুন, প্রতিটির একটি প্রধান লক্ষ্য। ভাল উদাহরণ: “Customer placing an order,” “Team member fulfilling orders,” “Manager reviewing performance.” অস্পষ্ট উদাহরণ: “18–35”, “busy professionals” বা “admins” (যদি আপনি বলে না যে তারা কী অ্যাডমিন করে)।\n\n### JTBD কঠোর ফরম্যাটে লিখুন\n\nপ্রতিবার একই বাক্য কাঠামো ব্যবহার করুন: “When..., I want to..., so I can...”. এটি অ্যাপকে আউটকাম-ফোকাস রাখে এবং AI বিল্ডারকে স্থায়ী, পরীক্ষা যোগ্য কন্ডিশন দেয়।\n\nনিচে বাস্তবসম্মত JTBD উদাহরণ যেখানে “ডান” স্পষ্টভাবে সংজ্ঞায়িত:\n\n- When I finish a client call, I want to log next steps in one place, so I can follow up on time. Done means: saved note, due date set, reminder scheduled.\n- When a new request arrives, I want to approve or reject it quickly, so I can keep work moving. Done means: decision recorded, requester notified, status updated.\n- When I am on mobile, I want to see only today’s tasks, so I can act without searching. Done means: tasks filtered to today, one-tap mark complete.\n- When I make a mistake, I want to undo the last change, so I can recover without support. Done means: previous state restored, audit note created.\n\nসাফল্যের মানদণ্ড মেশিনকে “বেশি ভালো লাগছে”–র অস্পষ্টতা দূর করে। এগুলো বিল্ডারকে বলে দেয় UI-কে কী করতে হবে এবং ব্যাকএন্ডে কী সংরক্ষণ করতে হবে।\n\n### উচ্চ স্তরে পারমিশন যোগ করুন\n\nপুরো সিকিউরিটি প্ল্যান লিখবেন না। শুধু বলে দিন কে কী করতে পারে, সরল ভাষায়।\n\nউদাহরণ: “Members can create and edit their own items. Managers can edit any item and change status. Owners can manage users and billing.”\n\nআপনি যদি Koder.ai–এর মত টুলে Planning Mode ব্যবহার করেন, এই ব্যবহারকারী টাইপ, JTBD লাইন এবং পারমিশন নির্ভরযোগ্য ইনপুটে পরিণত হয়। এগুলো AI-কে অতিরিক্ত রোল বানানো বা দায়িত্ব গুলোর মিশ্রণ থেকে রোধ করে।\n\n## Entities: প্রযুক্তিগত না হয়ে ডেটা সংজ্ঞায়িত করুন\n\nEntities হলো আপনার অ্যাপ যে “বস্তুগুলো” ট্র্যাক করে। যদি আপনি সেগুলো স্পষ্টভাবে নামেন, AI বিল্ডার স্ক্রিন, ফর্ম এবং এমন একটি ডাটাবেস তৈরি করতে পারবে যা সবখানেই মিলবে। এটাই মিসম্যাচড ফিল্ড ও র‍্যাকর্ডের অযাচিত ফিচার প্রতিরোধ করে।\n\nকোর নামগুলো তালিকাভুক্ত করে শুরু করুন। যদি অ্যাপ “প্রজেক্ট ম্যানেজ”–এর জন্য হয়, আপনার নামগুলো হতে পারে Project, Task, এবং Comment। যদি এটা “হেয়ারকাট বুকিং”–এর জন্য হয়, আপনি থাকতে পারেন Booking, Service, Customer, এবং Staff।\n\n### ৫ থেকে ১০টি ফিল্ড বেছে নিন যেগুলো মানুষ আসলে বলে\n\nপ্রতিটি entity–র জন্য ফিল্ড সাধারণ ভাষায় লিখুন, ডাটাবেস টার্মে নয়। ভাবুন মানুষ ফর্মে কী টাইপ করবে।\n\n- Task: title, description, status, due date, priority, assigned to, created by\n- Project: name, goal, start date, end date, owner, archived (yes/no)\n- Invoice: invoice number, client name, amount, currency, due date, paid (yes/no)\n\nযদি আপনি কোনো ফিল্ড এক বাক্যে ব্যাখ্যা করতে না পারেন, সম্ভবত সেটা প্রথম সংস্করণের জন্য বেশি ডিটেইল।\n\n### সম্পর্ক এবং নিয়ম সরল ভাষায়\n\nকীভাবে entities জড়িত তা সহজ বাক্যে লিখুন:\n\n"One user can have many projects." "Each task belongs to one project." "A comment belongs to a task and has one author."\n\nএটি বিল্ডারকে তালিকা, ডিটেইল পেজ এবং ফিল্টার তৈরি করার জন্য যথেষ্ট কাঠামো দেয়।\n\nকিছু ডেটা রুল যোগ করুন যা গণ্ডগোল এড়ায়:\n\n- Required: "Task title is required."\n- Unique: "Invoice number must be unique."\n- Limits: "Description max 500 characters."\n- Defaults: "New tasks start as status = Open."\n\nশেষে, আপনি কোনটা এখনও স্টোর করবেন না তা বলেই স্কোপ কমিয়ে দিন। উদাহরণ: “No file attachments in v1,” বা “Don’t track staff schedules yet, only bookings.” এই বাদ দেওয়া গুলো অ্যাপকে ভুল দিক থেকে বাড়তে বাধা দেয়।\n\n## Screens এবং ফ্লো: সরল ও পূর্বনির্ধারিত রাখুন\n\nএক-পৃষ্ঠার অ্যাপ স্পেস টেমপ্লেট সবচেয়ে ভাল কাজ করে যখন প্রথম ভার্শনে একটি ছোট, স্থির স্ক্রিন সেট থাকে। আপনি যদি প্রতিটি সম্ভাব্য স্ক্রিন আজ ডিজাইন করার চেষ্টা করেন, AI বিল্ডার ধারাবাহিকভাবে অনুমান করবে, এবং UI প্রতি বিল্ডে ভ্রমণ করবে।\n\nপ্রাথমিকভাবে সেই স্ক্রিনগুলো নাম দিন যা কেউ প্রধান কাজ সম্পন্ন করতে পারে। বেশিরভাগ MVP–এর জন্য 3 থেকে 6 স্ক্রিন যথেষ্ট:\n\n- Sign in\n- List (your main items)\n- Detail (view one item)\n- Create/Edit (a form)\n- Settings (optional)\n\nতারপর হ্যাপি পাথটাকে সংক্ষিপ্ত গল্পে লিখুন শুরু থেকে শেষ পর্যন্ত।\n\nউদাহরণ: “User signs in, lands on the list, searches, opens an item, edits one field, saves, and returns to the list.”\n\nপ্রতিটি স্ক্রিনের জন্য, মূল অ্যাকশনগুলো সরল ভাষায় নোট করুন। “সবকিছু করা”–র স্ক্রিন এড়ান। ২ থেকে ৪টি ক্রিয়া বেছে নিন যা সবচেয়ে গুরুত্বপূর্ণ, যেমন create, edit, search, export, বা archive।\n\nএছাড়াও সিদ্ধান্ত নিন কি দ্রুত হওয়া আবশ্যক, এবং কি “ভালো-এটুকু” হতে পারে। “দ্রুত” সাধারণত তালিকা ত্বরান্বিত খোলা, সার্চ দ্রুত সাড়া দেওয়া, এবং সেভ মুহূর্তে হওয়া বোঝায়। “ভালো-এটুকু” হতে পারে এক্সপোর্ট যে কয়েক সেকেন্ড নেয়, বেসিক অ্যানালিটিক্স, বা সীমিত সেটিংস।\n\nশেষে, প্রতিটি রোলে এক লাইনে এক্সেস ক্যাপচার করুন:\n\n- Viewer: can view and search\n- Editor: can create and edit\n- Admin (only if needed): can manage users and delete\n\nএটি স্ক্রিনগুলোকে পূর্বানুমেয় রাখে, পারমিশন সারপ্রাইজ কমায়, এবং পরে রিরাইট কমায়।\n\n## Edge cases এবং non-goals যা রিরাইট বন্ধ করে\n\nবেশি রিরাইট হওয়ার প্রধান কারণ: অ্যাপ হ্যাপি পাথ-এ ঠিক কাজ করে, কিন্তু বাস্তব জীবনে সমস্যা দেখালে ভেঙে যায়।\n\nএকটি ভাল এক-পৃষ্ঠার স্পেস টেমপ্লেট এজ কেস ও নন-গোলের জায়গা রাখে, এবং সেই ছোট স্পেস ঘন্টার সঞ্চয় করে।\n\nপ্রতিটি JTBD নিয়ে শুরু করে জিজ্ঞাসা করুন: কি ভেঙে যেতে পারে? সাধারণ ভাষায় রাখুন, প্রযুক্তিগত নয়। আপনি এখানে অস্পষ্টতা দূর করছেন যাতে বিল্ডার প্রতি বার একই সিদ্ধান্ত নেয়।\n\nলিখবার যোগ্য সাধারণ এজ কেসগুলো:\n\n- Missing or incomplete info (empty fields, unknown address, no profile photo)\n- Duplicates (same user signs up twice, same item added twice)\n- Conflicts (two people edit the same record, status changed while viewing)\n- Limits and timeouts (slow connection, upload fails, request takes too long)\n- Permission issues (user tries to view or edit something they should not)\n\nতারপর প্রতিক্রিয়া নির্ধারণ করুন। নির্দিষ্ট হন: “Block the action and show a clear message,” “Allow save as draft,” বা “Retry once, then show a button to try again.” এই নিয়মগুলো সরাসরি সংগত প্রম্পটে অনুবাদিত হয়।\n\nপ্রাইভেসি ও সেফটি প্রত্যাশা ১–২ লাইন দিন। উদাহরণ: “Collect the minimum data needed,” “Users can delete their account and all personal data,” এবং “Hide private items by default.” যদি আপনার অ্যাপ ইউজার-জেনারেটেড কনটেন্ট জড়িত করে, রিপোর্ট ও স্প্যামের ক্ষেত্রে কি করা হবে তা নোট করুন, যদিও v1-এ সেটা সরল হতে পারে।\n\nশেষে, নন-গোলগুলো লিখে স্কোপ ক্রিপ কমান। বড় প্রলুব্ধ ফিচারগুলো এখনই করবেন না বলে নির্দিষ্ট করুন।\n\nস্পষ্ট নন-গোল উদাহরণ:\n\n- No payments or subscriptions in v1\n- No social login (email-only for now)\n- No admin dashboard beyond basic list and delete\n- No offline mode\n\nএকটা দ্রুত উদাহরণ: যদি কাজটি “Create an event,” তাহলে সংজ্ঞায়িত করুন কখন তারিখ অতীত, টাইটেল খালি, বা একই ইভেন্ট দু’বার তৈরি হলে কী হবে। এই স্পষ্টতা পরের রিরাইট প্রতিরোধ করে।\n\n## এক-পৃষ্ঠার স্পেসকে এমন প্রম্পটে রূপান্তর করুন যা আপনার AI বিল্ডার চালাতে পারে\n\nসবচেয়ে দ্রুত পথ হলো প্রতিটি ব্লককে ছোট, সরাসরি নির্দেশে বদলে দেওয়া যা বিল্ডার রান করতে পারে। এটাকে মনে করুন বিল্ডারকে একগাদা কার্ড দেয়া হচ্ছে যাতে সেটি ক্রমানুসারে অনুসরণ করে, এক বড় অস্পষ্ট অনুরোধের বদলে।\n\nপ্রতিটি ব্লক (Users, Jobs, Entities, Screens, Edge cases, Non-goals) এক বাক্য নির্দেশে রূপান্তর করুন স্পষ্ট নাম ও ক্রিয়াসহ। “make it clean”–এর মত মতামত এড়ান যতক্ষণ না আপনি বলেন “clean” মানে কি।\n\n### একটি সহজ প্রম্পট প্যাটার্ন যা কাজ করে\n\nদুই-ধাপ চক্র ব্যবহার করুন: প্রথমে বানান, তারপর স্পেসের বিরুদ্ধে যাচাই করুন।\n\n1) Build: “Create the data model and API for these Entities: [paste Entities]. Support these roles: [paste Users].”\n2) Build: “Create screens and flows exactly for: [paste Screens/Flows].”\n3) Validate: “Now check your work against this spec. List any mismatches and fix them: [paste full one-page spec].”\n\nএকটি সংক্ষিপ্ত ডেফিনিশন অফ ডান যোগ করুন যাতে বিল্ডার জানে কখন থামতে হবে। পরিমাপযোগ্য রাখুন:\n\n- All listed roles can complete every job-to-be-done end to end\n- Each entity has create, view, edit, and archive (if the spec says so)\n- Screens match the named flows, with consistent field labels\n- Edge cases are handled with clear messages (no silent failures)\n\nশুধুমাত্র তখনই কনস্ট্রেইন্ট যোগ করুন যখন এগুলো সত্যিই গুরুত্বপূর্ণ: প্রয়োজনীয় ডিভাইস (mobile-first), প্রয়োজনীয় auth (admin-only actions), বা প্রয়োজনীয় স্ট্যাক (যেমন React frontend, Go backend, PostgreSQL) যদি আপনার প্ল্যাটফর্ম তা আশা করে।\n\n### পরিবর্তন চাওয়া ছাড়াই প্ল্যান অক্ষুন্ন রাখুন\n\nআপনি যখন এডিট চান, স্পেস ব্লক রেফার করুন, কোড নয়।\n\nউদাহরণ: “Update the Entities block: add ‘Subscription’ with fields X and Y. Then regenerate only the affected APIs and screens, and re-run the validation step.”\n\nএই পদ্ধতি প্ল্যানকে স্থিতিশীল রাখে একই সাথে আপনাকে নিরাপদে ইটারেট করতে দেয়।\n\n## বাস্তবসম্মত উদাহরণ: ধারণা থেকে Planning Mode প্রম্পট পর্যন্ত\n\nকল্পনা করুন আপনি একটি ছোট স্যালনের জন্য একটি সহজ অ্যাপয়েন্টমেন্ট রিমাইন্ডার ট্র্যাকার চান। লক্ষ্য পূর্ণ বুকিং সিস্টেম নয়। এটি হালকা-ওয়েট একটি জায়গা যেখানে অ্যাপয়েন্টমেন্ট সংরক্ষণ ও রিমাইন্ডার পাঠানো হয়।\n\nনিচে একটি পূরণকৃত এক-পৃষ্ঠার স্পেস টেমপ্লেট কেমন দেখায়।\n\n```text

APP: Appointment Reminder Tracker GOAL: Track appointments and send reminders. No payments, no online booking.

USERS

1. Owner/Staff: creates and manages appointments, wants fewer no-shows.
2. Client: receives reminders, wants an easy way to confirm.

JOBS TO BE DONE (JTBD)

1. As staff, I add an appointment in under 30 seconds.
2. As staff, I see today's schedule in time order.
3. As staff, I mark a client as confirmed or no-show.
4. As staff, I resend a reminder when asked.
5. As a client, I confirm from a message without creating an account.

ENTITIES (DATA)

• Client: id, name, phone, email (optional), notes
• Appointment: id, client_id, service, start_time, duration_min, status (scheduled/confirmed/canceled/no_show)
• Reminder: id, appointment_id, channel (sms/email), send_at, sent_at, result (ok/failed)
• StaffUser: id, name, role (owner/staff) Relationships: Client 1-to-many Appointment. Appointment 1-to-many Reminder.

EDGE CASES (WHAT BREAKS NAIVE BUILDS)

1. Duplicate client (same phone, different name)
2. Overlapping appointments for the same staff
3. Time zone changes (travel, daylight saving)
4. Client has no email, SMS only
5. Reminder send fails, needs retry and visible status
6. Appointment edited after reminder scheduled
7. Client cancels after confirmation
8. Same-day appointment created 10 minutes before start
9. Phone number format varies (+1, spaces, dashes)
10. Deleting a client with future appointments

\nএখন এটাকে Planning Mode–এর জন্য পেস্টযোগ্য প্রম্পট বানান। কঠোর রাখুন যাতে বিল্ডার প্রতি বার একই সিদ্ধান্ত নেয়।\n\n```text
PLANNING MODE PROMPT BUNDLE
1) Build an MVP web app with these entities and relationships exactly as written.
2) Required screens: Login (StaffUser), Today Schedule, Client List, Client Detail, Appointment Create/Edit.
3) Required flows: create client, create appointment for a client, confirm/cancel/no-show, schedule reminders, resend reminder.
4) Constraints: no payments, no public booking page, no client accounts.
5) Edge-case handling: implement validation and UI feedback for all 10 edge cases listed.
6) Output: database schema, API endpoints, and UI behavior notes per screen.

\n## AI-নির্মিত অ্যাপগুলিকে অসঙ্গত করে দেওয়া সাধারণ ফাঁদগুলো\n\nময়লা আউটপুট সাধারণত অস্পষ্ট স্পেস এবং ফিচার উইশলিস্ট থেকে শুরু হয়। AI ঠিক যা বলা হয়েছে তাই করবে, কিন্তু সেটা আপনার মন পড়তে পারে না। ছোট ফাঁকগুলো পরবর্তীতে বড় ভিন্নতার রূপ নেয়।\n\nএই ফাঁদগুলো সবচেয়ে বেশি সামঞ্জস্য ভেঙে দেয়, এবং এক-পৃষ্ঠার স্পেস টেমপ্লেট এগুলো ঠিক করে:\n\n- : “Add favorites” একটি ফিচার। একটি কাজ হলো “save items to review later.” কাজগুলো উদ্দেশ্য ও সফলতা ধরে রাখে, তাই AI বোঝে কোথায় বোতাম হবে, সেভের পরে কী হবে, খালি স্টেট কী বলবে।\n- : যদি আপনি প্রথম দিনে ১২টি টেবিল ডিফাইন করেন, লজিক ছড়িয়ে পড়ে। ছোট মডেল দিয়ে শুরু করুন যা শিপ করা যায়।\n- : যদি আপনি কখনই বলেন না কে এডিট বা ডিলিট করতে পারে, বিল্ডার অনুমান করবে। সহজ নিয়ম লিখুন যেমন “Only the owner can delete,” “Members can create and edit,” “Viewers can only read.”\n- : ডেফিনিশন অফ ডান না থাকলে আপনাকে অসীম iteration মেলে। ২–৪টি acceptance check যোগ করুন, যেমন “User can create a task in under 30 seconds” বা “Tasks show correctly after refresh.”\n- : “offline,” “duplicate emails,” বা “empty list” লেখা যথেষ্ট নয়। প্রতিটির জন্য বলুন অ্যাপ কি করবে। উদাহরণ: “If email already exists, show a friendly error and suggest sign-in.”\n\nআপনি যদি Planning Mode Koder.ai-এ ব্যবহার করেন, এই বেসিকগুলো আরো গুরুত্বপূর্ণ হবে কারণ প্ল্যানই বারবার ব্যবহারের সূত্র হয়। পরিষ্কার কাজ, ছোট ডেটা মডেল, স্পষ্ট পারমিশন, এবং টেস্টেবল সফলতা নিয়ম প্রতিটি নতুন স্ক্রীনকে বাকিগুলোর সাথে সঙ্গত রাখে।\n\n## দ্রুত চেকলিস্ট ও পরের পদক্ষেপ\n\nবিল্ড করার আগে আপনার এক-পৃষ্ঠার স্পেস টেমপ্লেট দ্রুত চেক করুন। উদ্দেশ্য হলো সেই গর্তগুলো দূর করা যা AI বিল্ডকে অনুমান করতে বাধ্য করে। সেই অনুমানগুলো রিরাইটে পরিণত হয়।\n\nদ্রুত সমাপ্তি চেকঃ\n\n- Users: প্রতিটি ব্যবহারকারী টাইপের একটি স্পষ্ট লক্ষ্য আছে এবং “কে কি করতে পারে” নোট (create, view, edit, delete) আছে।\n- Jobs-to-be-done: প্রতিটি কাজ একটি ট্রিগার দিয়ে শুরু হয় এবং একটি স্পষ্ট সফলতার রেজাল্টে শেষ হয় যা যাচাই করা যায়।\n- Entities: জবগুলোর প্রতিটি নামকৃত পদার্থের একটা ব্যাকিং ডেটা আইটেম আছে (এভেন যদি কেবল নাম, স্ট্যাটাস, টাইমস্ট্যাম্প)।\n- Screens and flows: প্রতিটি কাজ একটা সহজ পথকে ম্যাপ করে (স্টার্ট স্ক্রিন, মূল অ্যাকশন, কনফার্মেশন)।\n- Edge cases: আপনি অন্তত ৫টি সমস্যার কথা লিখেছেন যা হতে পারে (খালি স্টেট, inválid input, ডুপ্লিকেট, পারমিশন, অফলাইন বা ধীর নেটওয়ার্ক)।\n\nএকটি সহজ স্কোরিং: প্রতিটি এলাকাকে ০–২ রেট করুন:\n\n- 0: অনুপস্থিত বা অস্পষ্ট\n- 1: আছে কিন্তু অস্পষ্ট\n- 2: বিল্ড করার জন্য যথেষ্ট পরিষ্কার\n\nশুরুতে কমপক্ষে ৭/১০ লক্ষ্য করুন। যদি Entities বা Edge cases ২–এর নিচে থাকে, আগে সেগুলো ঠিক করুন—এগুলো সবচেয়ে বেশি চোরাকর্ম দেয়।\n\nপ্রথম বিল্ডের পরে, প্রতিটি JTBD–এর বিরুদ্ধে অ্যাপ রিভিউ করুন এবং mismatch–গুলো চিহ্ন করুন। প্রতিটি পরিবর্তনের আগে স্ন্যাপশট নিন। যদি নতুন iteration সবকিছু খারাপ করে ফেলে, রোলব্যাক করুন এবং ছোট এডিট দিয়ে আবার চেষ্টা করুন।\n\nযদি আপনি Koder.ai (koder.ai) ব্যবহার করেন, Planning Mode হলো এক বাস্তব জায়গা যেখানে এই এক-পৃষ্ঠার স্পেসকে "source of truth" হিসেবে রাখা যায় এবং কেবল যেটা বদলেছে সেটাই পুনরায় জেনারেট করা যায়, পুরো কিছুকে হাতে হাতে না লিখে।\n\nস্পেস আপডেট রাখুন যেভাবে আপনি এগোবেন। যখন আপনি কোনো পরিবর্তন গ্রহণ করবেন, একই দিনে স্পেস আপডেট করুন। যখন আপনি কোনো পরিবর্তন প্রত্যাখ্যান করবেন, কেন তা লিখে রাখুন, যাতে পরের প্রম্পটও সঙ্গত থাকে।