একটি AI অ্যাপ বিল্ডার কি React ও Flutter সামলাতে পারে?

দুটি আলাদা AI টুল দিয়ে একটি React ওয়েব ক্লায়েন্ট এবং একটি Flutter মোবাইল ক্লায়েন্ট তৈরি করা প্রথম যৌথ নিয়মটি বদলানোর আগ পর্যন্ত যুক্তিসংগত মনে হয়। তারপর একটি টুল ব্রাউজারের প্রবাহ আপডেট করে, অন্যটি আগের দিনের ধারণা ধরে রাখে, আর ডেটাবেস দুটি সংস্করণই গ্রহণ করে। কাজের যে ভাগাভাগি সহজ মনে হয়েছিল, সেটি ইন্টিগ্রেশনের কাজে পরিণত হয়।

বেশিরভাগ ছোট দলের জন্য একটি AI অ্যাপ বিল্ডারই ভালো পছন্দ, যদি সেটি React, Flutter এবং backend-এর জন্য আলাদা codebase তৈরি করতে পারে, source code দেয় এবং প্রতিটি client স্বাধীনভাবে release করতে দেয়। "একটি builder" বলতে একটি planning context এবং একটি system contract বোঝানো উচিত। এর অর্থ একটি বিশাল application, একটি release train বা TypeScript আর Dart-এর মধ্যে UI code ভাগ করার চেষ্টা নয়।

অন্য পথটিও কাজ করতে পারে। দুটি বিশেষায়িত টুল তখন যুক্তিসংগত, যখন আলাদা web এবং mobile team আগে থেকেই তাদের client-এর মালিক, API contract দুই টুলের বাইরে নিয়ন্ত্রিত এবং প্রতিষ্ঠান coordination-এর খরচ মেনে নেয়। এই শর্তগুলো না থাকলে দ্বিতীয় টুল এমন একটি সীমা যোগ করে, যা product-এর পুরো জীবনজুড়ে কাউকে পাহারা দিতে হবে।

আপনার কি একটি AI অ্যাপ বিল্ডার দরকার, নাকি দুটি?

একই product, backend, data model এবং identity system যখন দুই client-কে সেবা দেয়, তখন একটি builder বেছে নিন। দুটি বেছে নিন কেবল তখনই, যখন platform specialization-এর মূল্য shared context-এর চেয়ে বেশি এবং সীমাটি রক্ষণাবেক্ষণের জন্য নির্দিষ্ট মানুষ আছে।

নিচের score ধরে নিচ্ছে একজন founder বা ছোট product team, একটি Go API, একটি PostgreSQL database, একটি React web client এবং একটি Flutter mobile client আছে। 5 মানে পদ্ধতিটি অল্প manual coordination-এ বিষয়টি সামলায়। 1 মানে অনুপস্থিত সংযোগটি দলকে নিজে তৈরি ও নিয়ন্ত্রণ করতে হবে।

এই সংখ্যা সিদ্ধান্ত নেওয়ার সহায়ক, product benchmark নয়। কোনো candidate source export করতে না পারলে, সত্যিকারের backend তৈরি না করলে বা web ও mobile-কে একই deployment-এ বাধ্য করলে তার score অনেক কমিয়ে দিন। আবার একটি পরিণত platform team API contract, identity service, release policy এবং compatibility test-এর মালিক হলে two-tool setup বেশি নম্বর পেতে পারে।

Screen বা prompt গুনবেন না। Authority গুনুন। প্রতিটি business fact-এর জন্য একটি authority, একটি API contract, একটি identity policy এবং একটি migration sequence দরকার। React ও Flutter এই সিদ্ধান্তগুলো ব্যবহার করে।

যৌথ business logic দুই client-এর পেছনে থাকে

Permission, pricing rule, workflow transition, quota এবং সংরক্ষিত data রক্ষার validation backend-এ রাখুন। দ্রুত feedback-এর জন্য React ও Flutter হালকা check পুনরাবৃত্তি করতে পারে, কিন্তু চূড়ান্ত সিদ্ধান্ত API নেবে।

দলগুলো প্রায়ই দুটি আলাদা বিষয়কে "shared logic" বলে। Shared source code মানে দুই client একই implementation import করে। Shared business behavior মানে দুই client একটি authority থেকে একই ফল পায়। React ও Flutter আলাদা language এবং UI model ব্যবহার করে, তাই একই implementation চাপিয়ে দিলে প্রায়ই তৃতীয় একটি abstraction তৈরি হয়, যা দুই client-এর যেকোনোটির চেয়ে কঠিন। Behavior API-এর মাধ্যমে ভাগ করুন।

ধরা যাক, একটি order কেবল তখনই draft থেকে submitted হতে পারে, যখন অন্তত একটি line item আছে এবং account সক্রিয়। প্রতিটি client এই rule-এর মালিক হলে দ্রুত চারটি version হয়: React form check, Flutter button state, web submission handler এবং mobile submission handler। কোনো policy change client release-এর আগে সব জায়গায় পৌঁছাতে হবে। পুরোনো mobile build কয়েক মাস installed থাকতে পারে।

Backend-কে allowed action দেখাতে হবে এবং action এলে আবার প্রয়োগ করতে হবে:

{
  "order_id": "ord_4821",
  "status": "draft",
  "allowed_actions": ["submit"],
  "version": 7
}

Client ঠিক করে action কীভাবে দেখাবে। Server ঠিক করে version 7-এ submit বৈধ কি না। অন্য request আগে order বদলে দিলে server শেষ write-কে নীরবে জিততে না দিয়ে conflict ফেরায়।

React-এর documentation প্রতিটি state-এর জন্য single source of truth রাখার পরামর্শ দেয়। পরামর্শটি browser tree-এর ভেতরের জন্য, পুরো multi-client product-এর জন্য নয়। Web app আর mobile app-এর common parent হলো backend contract। দীর্ঘস্থায়ী business state সেখানে রাখা system boundary-তে একই ধারণা প্রয়োগ করে।

Flutter-এর architecture guide view ও view model-কে repository এবং service থেকে আলাদা করে। সেটি আরও বলে, service বাইরের API endpoint-কে wrap করে এবং repository তার ফলকে domain model-এ বদলায়। এটি client-এর ভালো boundary। Repository-কে Dart-এ server policy আবার তৈরির অনুমতি ভাববেন না। Mobile repository cache, retry এবং data mapping করতে পারে; order submit হবে কি না, তার দ্বিতীয় authority হওয়া উচিত নয়।

কিছু logic স্বাভাবিকভাবেই client-specific: input formatting, offline presentation, navigation, animation এবং device permission handling। Mobile app offline অবস্থায় draft queue করতে পারে, আর web app সঙ্গে সঙ্গে save করতে পারে। Connect হওয়ার পর দুটিকেই একই server rule-এ একই command পাঠাতে হবে।

PostgreSQL অবশ্যই API-এর পেছনে থাকবে

React bundle বা Flutter application কোনোটিরই সরাসরি PostgreSQL-এর সঙ্গে connect করা উচিত নয়। দুটিই distributed client, যার code এবং connection detail user দেখতে, copy করতে ও বদলাতে পারে।

PostgreSQL manual client authentication-কে database server-এর সেই সিদ্ধান্ত হিসেবে বর্ণনা করে, যেখানে server দেখে client চাওয়া database user হিসেবে connect করতে পারবে কি না। এই mechanism একটি database connection রক্ষা করে। এটি বোঝে না যে Alice order 42 edit করতে পারে কিন্তু 43 পারে না, বা পুরোনো mobile build নতুন workflow transition ব্যবহার করতে পারবে না। Application authorization API-তে থাকে।

React থেকে সরাসরি connection বিশেষভাবে অগ্রহণযোগ্য, কারণ browser-এর database-এ network access এবং downloaded code-এ credentials লাগবে। Flutter-এ password package করলে কেউ application extract করা পর্যন্তই সেটি লুকানো থাকে। Row-level security PostgreSQL-এর ভেতরে আরেক স্তর সুরক্ষা দিতে পারে, কিন্তু untrusted client-কে নিরাপদ database peer বানায় না। Stable endpoint, rate ও input limit, audit context এবং installed build না ভেঙে schema পরিবর্তনের জায়গা এখনও দরকার।

একটি public application boundary-সহ topology ব্যবহার করুন:

React client  \n               -> HTTPS API -> domain rules -> PostgreSQL
Flutter client /

API-কে restricted database role দিন। Migration credential চলমান application-এর বাইরে রাখুন। Migration-কে আলাদা deployment task হিসেবে চালান, যার নিজস্ব review এবং recovery plan আছে। এই ভাগ compromised API process-এর ক্ষমতা সীমিত করে এবং client-কে database credential জানা থেকে আটকায়।

দুটি AI tool কখনও দুটি backend তৈরি করে, কারণ প্রত্যেকে সম্পূর্ণ project দিতে চায়। দুটি service ইচ্ছাকৃত domain split না হলে এমন output বাতিল করুন। একই table-এ লেখা web backend ও mobile backend duplicate authorization, অসামঞ্জস্যপূর্ণ transaction এবং প্রতি schema change-এ দুই repair point তৈরি করে। Client-ভেদে আলাদা response shape দরকার হলে thin backend-for-frontend গ্রহণযোগ্য হতে পারে, তবে adapter-কে একই domain service call করতে হবে, সেটি পাশ কাটিয়ে লিখতে হবে না।

Generated React ও Flutter repository-তে PostgreSQL connection string, database host variable, SQL driver এবং privileged service credential খুঁজে boundary যাচাই করুন। Client code-এ যেকোনো একটি পাওয়া গেলে architecture review ব্যর্থ। প্রত্যাশিত client configuration-এ শুধু API base URL, public identity configuration এবং non-secret feature setting থাকে।

Database migration-এর backward compatibility-ও দরকার। আগে nullable column বা নতুন table যোগ করুন, দুই shape সামলাতে পারে এমন code deploy করুন, প্রয়োজনে backfill করুন, read বদলান এবং supported client পুরোনো field-এর ওপর নির্ভর না করলে তবেই সেটি সরান। Mobile distribution এই শেষ ব্যবধানকে web-only team-এর ধারণার চেয়ে দীর্ঘ করে।

Authentication-এর একটি authority ও দুটি client adapter থাকে

একটি identity issuer, একটি user record এবং একটি server-side authorization policy ব্যবহার করুন, এরপর browser ও mobile-এর জন্য আলাদা session adapter তৈরি করুন। Authentication প্রমাণ করে caller কে। Authorization ঠিক করে caller কী করতে পারে। দুইটি গুলিয়ে ফেললে endpoint valid token গ্রহণ করে, তারপর নিষিদ্ধ action লুকাতে client-কে বিশ্বাস করে।

React client সাধারণত browser redirect, cookie বা token, cross-site request protection এবং refresh-এর সময় প্রতিযোগী tab সামলায়। Flutter-কে deep link, application suspension, device storage এবং operating-system callback সামলাতে হয়। এই পার্থক্য আলাদা client code-এর পক্ষে যুক্তি দেয়। আলাদা user directory বা role-এর আলাদা অর্থের পক্ষে নয়।

OWASP-এর Mobile Application Security Cheat Sheet app-এর মধ্যে credential hardcode করতে মানা করে এবং platform-specific secure storage-এ রাখা নিরাপদ, revocable access token-এর পরামর্শ দেয়। নীতিটি মানুন, তবে সীমা বুঝুন। Secure storage file থেকে সাধারণ token theft কমায়। এটি compromised device-কে trustworthy করে না, তাই API প্রতিটি protected operation-এ expiration, audience, issuer, account status ও permission পরীক্ষা করে।

কোনো client-কে screen তৈরি করতে বলার আগে auth contract লিখুন:

Access token: short lived, sent to the API
Refresh mechanism: rotated or invalidated by the identity system
Logout: ends the local session and revokes server-side refresh authority
Account disabled: API rejects new operations even if a client still shows cached data
Role changed: next authorized request uses current server policy

সবচেয়ে তথ্যপূর্ণ test সফল login নয়। দুই client খোলা রেখে account disable করুন। পরের protected request দুই client-এই একইভাবে fail করবে, policy অনুযায়ী local private data মুছবে এবং কোনো client অনন্ত refresh loop-এ যাবে না। এরপর role বদলে দেখুন, stale screen আগের action করতে পারে কি না।

আপনি যতক্ষণ stale authorization মেনে নিতে পারেন, তার চেয়ে বেশি সময় role-এর সত্য token claim-এ রাখবেন না। Claim UI দ্রুত দেখাতে সাহায্য করতে পারে, কিন্তু sensitive operation-এ server-এর current policy দেখা উচিত। Role change সঙ্গে সঙ্গে কার্যকর হওয়া দরকার হলে পুরোনো role-সহ long-lived self-contained token সেই requirement-এর বিরুদ্ধে যায়।

এখানে একটি builder 5-এর বদলে 4 পায়, কারণ shared context platform security work দূর করে না। Builder দুই adapter তৈরি করতে পারে, কিন্তু একজন মানুষকে browser redirect, mobile deep link, refresh race, clock skew, revocation এবং device restore behavior পরীক্ষা করতে হবে।

একটি contract React ও Flutter-কে একমত রাখে

API description-কে দুই client-এর build input এবং released version-এর compatibility promise হিসেবে দেখুন। Prose prompt contract নয়, কারণ দুই generation run একই বাক্য আলাদাভাবে বুঝতে পারে।

HTTP API-এর জন্য OpenAPI বাস্তবসম্মত পছন্দ। Request field, response field, error body, authentication requirement এবং stable operation identifier নির্ধারণ করুন। Document থেকে thin TypeScript ও Dart client generate বা maintain করুন, আর application behavior সাধারণ React hook ও Flutter repository-তে রাখুন। Generated client code পরিবর্তনযোগ্য হতে হবে; product decision তার ভেতরে লুকাবেন না।

এই অংশটি version conflict স্পষ্ট করে:

/orders/{orderId}/submit:
  post:
    operationId: submitOrder
    requestBody:
      required: true
      content:
        application/json:
          schema:
            type: object
            required: [expected_version]
            properties:
              expected_version:
                type: integer
    responses:
      "200":
        description: Order submitted
      "409":
        description: Order changed since the client loaded it

Server behavior ও checked contract হলো source of truth। Generated TypeScript ও Dart type হলো projection। কোনো tool contract না বদলে client type edit করলে build সেই edit overwrite বা reject করবে।

Contract test-এ static schema যে behavior বলতে পারে না, সেটি পরীক্ষা করুন। Empty order submit করে দুই client-এর request থেকে একই error code আশা করুন। পুরোনো expected_version দিয়ে request replay করে 409 আশা করুন। পুরোনো client fixture-এ unknown enum value পাঠিয়ে দেখুন, crash না করে safe fallback নেয় কি না।

Additive API change পছন্দ করুন। Client unknown field ignore করলে নতুন optional response field সাধারণত নিরাপদ। Field সরানো, optional field required করা বা enum value নতুন অর্থে ব্যবহার করা installed mobile build ভাঙতে পারে। Meaning ধরে রাখা অসম্ভব হলেই endpoint version করুন; নিয়মিত version bump compatibility burden-কে বেশি directory-তে নিয়ে যায়।

একটি জনপ্রিয় পরামর্শ cross-platform package-এ domain model ভাগ করতে বলে। Order, account ও invoice দুই client-এ থাকায় সেটি কার্যকর মনে হয়। বাস্তবে TypeScript ও Dart package-এর আলাদা serialization behavior, null handling, date handling এবং release tooling লাগে। একটি contract থেকে transport shape generate করুন, তারপর প্রতিটি client-কে local UI model-এ map করতে দিন। Shared definition উপকারী। চাপিয়ে দেওয়া shared runtime model নয়।

Contract দুটি tool-কেও বেশি কার্যকর করে। এটি প্রতিটি tool-কে এমন boundary দেয়, যা সহজে নতুনভাবে ব্যাখ্যা করা যায় না। তবুও দুই generation session-এর বাইরে কাউকে contract change, compatibility check এবং release note-এর মালিক হতে হবে। কারও এই কাজ না থাকলে contract implementation-এর পেছনে পড়ে যাবে।

Release train স্বাধীন থাকা উচিত

একটি builder তিনটিই তৈরি করলেও web client, mobile client এবং API আলাদা schedule-এ ship করুন। Coordinated generation মানে coordinated deployment নয়।

React deployment-এর কয়েক মিনিটের মধ্যে user-এর কাছে যেতে পারে। Mobile release store review-এর মধ্য দিয়ে যায় এবং user update পিছিয়ে দিতে পারে। তাই API-কে current web build ও support window-এর প্রতিটি mobile version সমর্থন করতে হবে। সব client একসঙ্গে update হবে ধরে নেওয়া release plan প্রথম delayed review বা staged rollout-এই ভাঙবে।

প্রতিটি change-এর জন্য compatibility matrix ব্যবহার করুন:

Cell-এর শব্দ version number-এর চেয়ে বেশি গুরুত্বপূর্ণ। এগুলো দলকে বলতে বাধ্য করে পুরোনো client আসলে কী করে। Matrix change plan-এ রাখুন এবং সম্ভব হলে তার দাবিগুলোকে test-এ পরিণত করুন।

নিরাপদ feature rollout প্রায়ই এই ক্রমে চলে:

1. Backward-compatible database structure এবং API behavior যোগ করুন।
2. নতুন response বোঝে এমন client release করুন, তবে feature লুকানো রাখুন।
3. Write চালু করার আগে error এবং compatibility signal দেখুন।
4. Server-controlled capability বা account setting দিয়ে feature চালু করুন।
5. Support window শেষ হলে পুরোনো path সরান।

Feature flag exposure নিয়ন্ত্রণে কাজে লাগে, incompatible schema ঠিক করতে নয়। পুরোনো client নতুন required field বা enum parse করে crash করলে startup-এর পর button বন্ধ করা তাকে বাঁচাবে না। Compatibility payload design-এর অংশ।

দুটি tool platform-specific packaging-এ শক্তিশালী হতে পারে। Mobile-focused builder store metadata ও device entitlement ভালো বুঝতে পারে, web-focused builder browser deployment ভালো সামলাতে পারে। API readiness, feature exposure এবং support window সমন্বয়ের বাড়তি কাজের চেয়ে এই সুবিধা বড় হলেই two-tool approach-এর release score বাড়ান।

Log এবং error report-এ release identifier দেখান। প্রতিটি API request-এ non-secret client name ও build identifier থাকবে, যাতে operator browser regression এবং পুরোনো mobile behavior আলাদা করতে পারে। Authorization-এর জন্য এই identifier বিশ্বাস করবেন না, কারণ client এটি নকল করতে পারে।

Rollback-এর তিনটি আলাদা অর্থ আছে

Client rollback, server rollback এবং data rollback আলাদা failure সমাধান করে এবং আলাদা procedure চায়। এগুলোকে একটি "undo" button ভাবলে recoverable release data loss-এ বদলে যেতে পারে।

React deployment সাধারণত traffic আগের artifact-এ পাঠাতে পারে। Mobile rollback প্রায়ই staged rollout থামানো এবং fixed build জমা দেওয়া বোঝায়; ইতিমধ্যে update হওয়া device খারাপ version-এ থাকতে পারে। ওই সময় API-কে দুই version সহ্য করতে হবে।

Database পুরোনো binary-এর সঙ্গে compatible থাকলেই server code rollback করা যায়। Additive migration প্রায়ই এটি সম্ভব করে। সরাসরি column rename, meaning বদল বা data delete করা migration তা নাও করতে পারে। Expand-and-contract migration ব্যবহার করুন: নতুন representation যোগ করুন, দুই code version চলতে দিন, data সরান, read বদলান, পরে পুরোনো representation সরান।

Data rollback বিপজ্জনক। Database snapshot restore করলে snapshot-এর পরের valid write মুছে যায়। অনেক production incident-এ forward repair নিরাপদ: corrected code deploy করুন, audit query দিয়ে affected row খুঁজুন এবং সীমিত compensating change দিন। Snapshot বিপর্যয় থেকে বাঁচায়, কিন্তু reversible migration-এর সহজ বিকল্প নয়।

একটি সাধারণ failure দেখুন। API deploy delivery_window-কে required field করে। নতুন web client সেটি পাঠায়। Review-তে থাকা mobile build পাঠায় না। Team database column NOT NULL করে, আর পুরোনো mobile submission server error দিতে থাকে। শুধু web client rollback করলে কিছু বদলায় না। পুরোনো binary নতুন schema পড়তে না পারলে শুধু API rollback ব্যর্থ হতে পারে। পুরো database restore করলে unrelated order হারাবে।

সঠিক recovery-তে API missing field গ্রহণ করে, documented default দেয় বা transition পিছিয়ে দেয় এবং mobile support যথেষ্ট হওয়া পর্যন্ত field optional রাখে। তারপর team unrelated write না ফিরিয়ে affected record মেরামত করতে পারে। আসল ভুল rollback button না থাকা ছিল না। ভুল ছিল incompatible sequence।

প্রতিটি deployment-এর আগে এই চারটি line লিখুন:

Web rollback: artifact and routing action
Mobile containment: rollout stop, affected builds, fixed build path
API rollback: compatible binary and schema range
Data repair: query, owner, backup point, and forward correction

একটি builder-এর snapshot ও planning history সম্পর্কিত change কভার করলে সেটি সাহায্য করে, তবে scope যাচাই করুন। Source snapshot, deployed artifact এবং PostgreSQL backup আলাদা asset। ভালো rollback test প্রতিটি asset disposable environment-এ restore করে এবং প্রমাণ করে পুরোনো client মূল write flow শেষ করতে পারে।

দুটি builder integration ownership বাড়ায়

দুটি tool maintenance অর্ধেক করে না। তারা দুটি generation history, দুই সেট assumption এবং দুটির বাইরের একটি integration surface তৈরি করে।

প্রথম মাস দ্রুত মনে হতে পারে, কারণ প্রতিটি tool পরিচিত platform code বানায়। Change boundary পার হলে খরচ দেখা যায়: field rename, permission বদল, account state যোগ, logout behavior বদল বা endpoint retire করা। প্রতিটি prompt-এ current contract এবং অন্য client-এর release state-এর প্রভাব থাকতে হবে। একটি detail বাদ পড়লে এমন plausible code তৈরি হয়, যা compile করে অথচ product behavior ভাঙে।

Failure pattern অনুমান করা যায়। Web tool enum-এ archived যোগ করে এবং ঠিকমতো দেখায়। Mobile tool unknown value-কে parsing error ধরে। API আগে deploy হয়, archived record user list-এ আসে এবং mobile screen সব record load করা বন্ধ করে। প্রতিটি local change যুক্তিসংগত ছিল। কেউ cross-version combination test করেনি।

Maintenance-এর একজন owner এবং repeatable change packet দরকার:

• Behavior change এবং তার owner server rule
• API ও migration diff
• React acceptance case
• Flutter acceptance case
• Release order এবং rollback limit

একটি builder-এর সঙ্গেও packet উপকারী, তবে একটি planning context পুরো change-এর সঙ্গে এটি ধরে রাখতে পারে। দুটি tool হলে team-কে copy করতে, দুই output record করতে এবং conflicting edit মেলাতে হয়। Automation schema drift ধরতে পারে; কোন interpretation product-এর সঙ্গে মেলে তা ঠিক করতে পারে না।

Source export tool dependence শেষ করে, এমন ধরে নেবেন না। Exported code আপনাকে custody দেয়, কিন্তু maintainability নির্ভর করে readable structure, test, dependency choice, build instruction এবং শুধু বদলানো অংশ regenerate করার পরিষ্কার পথের ওপর। Project পরীক্ষা করুন যেন builder কাল হারিয়ে যাবে। একজন দক্ষ React developer web client ship, Flutter developer mobile app build এবং backend developer original chat history ছাড়া PostgreSQL migrate করতে পারবে কি?

Maintenance সাধারণ evidence দিয়ে মাপুন: contract test failure, generated change মেলাতে সময়, regeneration-এ হারানো manual edit, unsupported client version এবং recovery rehearsal result। Shared code line-এর মতো vanity metric এড়ান। সামান্য duplicated presentation mapping বুদ্ধিদীপ্ত sharing layer-এর চেয়ে সস্তা হতে পারে।

দুটি builder তখন যুক্তিসংগত যখন দুই team আগেই এভাবে কাজ করে। প্রতিটি team নিজের client-এর owner, platform group API ও identity-এর owner, আর automated compatibility test release-এর আগে চলে। তখন tool organization-এর সঙ্গে মেলে। Solo founder-এর এমন organization chart নকল করা উচিত নয়, যা তার নেই।

কীভাবে সিদ্ধান্ত নেবেন?

প্রতিটি tool প্রথম screen কত দ্রুত আঁকে তা তুলনা না করে, একটি cross-client change প্রমাণ করে approach বাছুন। Trial-এ schema change, authorization rule, পুরোনো mobile build, independent release এবং rollback rehearsal থাকবে।

One-builder candidate-কে ছোট vertical slice বানাতে বলুন: React ও Flutter client একই order command PostgreSQL-সমর্থিত Go API-তে পাঠায়। দুই client কাজ করার পর rule বদলান। Optional field যোগ করুন, একটি role deny করুন, শুধু web change release করুন এবং নতুন row না হারিয়ে আগের server artifact restore করুন। Source export করে builder interface-এর বাইরে test চালান।

Two-tool candidate-কে checked OpenAPI document দিয়ে একই sequence চালাতে বলুন। Session-এর মধ্যে কত fact copy করতে হয় এবং tool কতবার boundary-এর বাইরে edit করে তা মাপুন। শুধু generation time নয়, drift diagnose করার সময়ও ধরুন।

এই শর্তগুলো পাস করলে একটি builder ব্যবহার করুন:

• একটি contract ঘিরে আলাদা React, Flutter ও backend project বানায়।
• PostgreSQL backend-এর পেছনে এবং secret client-এর বাইরে রাখে।
• স্বাধীন client ও server release সমর্থন করে।
• Source, deployment state এবং আলাদা recovery point দেয়।
• Generated code chat history ছাড়া build ও test করা যায়।

Specialist capability mobile বা web ফলকে বাস্তবে বদলালে এবং একজন নির্দিষ্ট ব্যক্তি contract governance-এর মালিক হলে দুটি বাছুন। "Mobile output সুন্দর ছিল" যথেষ্ট নয়। Device integration, accessibility, store packaging, offline operation বা team-এর existing skill যথেষ্ট হতে পারে, যদি maintenance হিসাবের পরও সুবিধা থাকে।

Koder.ai একটি chat context থেকে React, Go/PostgreSQL এবং Flutter application তৈরি করতে পারে, সঙ্গে planning mode, source export, deployment ও hosting, snapshot এবং rollback দেয়। এই combination এখানে বর্ণিত one-builder architecture-এর সঙ্গে মেলে, তবুও vertical-slice test চালান, কারণ feature list release ও recovery path প্রমাণ করে না।

সিদ্ধান্ত পরে বদলাতে পারে। ভালো boundary-র system business rule API-এর বাইরে না সরিয়ে React generator, Flutter generator বা দুটিই বদলাতে দেয়। প্রথম architecture-এ সেই বিকল্প রাখতে হবে।

অস্বস্তিকর test সহজ: release-এর দিন mobile tool হারিয়ে গেলে আপনি কি current API contract ব্যাখ্যা করতে, exported client build করতে এবং ship চালিয়ে যেতে পারবেন? উত্তর remembered prompt-এর ওপর নির্ভর করলে আরেকটি tool যোগ করার আগে ownership model ঠিক করুন।