असली बैकएंड और डेटाबेस वाली AI ऐप्स: संपूर्ण गाइड (2026)

कौन-से AI ऐप बिल्डर असली बैकएंड बनाते हैं — और "असली" किसे कहते हैं?

छोटा जवाब: असली बैकएंड का मतलब है स्थायी PostgreSQL डेटा, सर्वर-साइड ऑथेंटिकेशन, और REST APIs जो नियम सर्वर पर लागू करती हैं — न कि एक सुंदर React फ्रंटएंड जहाँ लॉगिन फ़ॉर्म किसी को ऑथेंटिकेट नहीं करता और डैशबोर्ड के चार्ट हार्डकोडेड JSON दिखाते हैं। ज़्यादातर AI ऐप बिल्डर दूसरी चीज़ जेनरेट करते हैं। VULK (हमारा प्रोडक्ट — डिस्क्लोज़र नीचे) पहली चीज़ जेनरेट और डिप्लॉय करता है: जब आपका प्रॉम्प्ट अकाउंट, सेव्ड डेटा या एडमिन रोल बताता है, तो यह अपने आप असली बैकएंड प्रोविज़न करता है — PostgreSQL स्कीमा, CRUD एंडपॉइंट्स, रोल्स वाला JWT auth — फ्रंटएंड के साथ, आपस में जुड़ा और डिप्लॉय्ड। Lovable और Bolt एक अलग, जायज़ रास्ता लेते हैं: वे बैकएंड Supabase को सौंप देते हैं, जो अच्छा काम करता है पर एक दूसरी प्लेटफ़ॉर्म चलानी पड़ती है। फ्रंटएंड-फर्स्ट टूल कठिन 60% आप पर छोड़ देते हैं।

यह माँग कोई किनारे का मामला नहीं है: VULK पर जेनरेट हुईं सभी ऐप्स का 62% SQL स्कीमा शामिल करता है (VULK प्लेटफ़ॉर्म डेटा, जुलाई 2026, 11,355 जेनरेटेड ऐप्स पर) — "ऐप" प्रॉम्प्ट करने वाले ज़्यादातर लोग, चाहे उन्हें एहसास हो या न हो, उपयोगकर्ताओं और डेटा वाली कोई चीज़ बता रहे होते हैं। यह गाइड सब कुछ कवर करती है: असली बैकएंड के चार टेस्ट, ऑटोमैटिक प्रोविज़निंग कैसे काम करती है, जेनरेटेड स्कीमा और auth असल में कैसे दिखते हैं, सुरक्षा पैटर्न, डिप्लॉयमेंट, छह पूरे कॉपी-पेस्ट प्रॉम्प्ट, और — वह हिस्सा जिस पर विक्रेता बुदबुदाते हैं — एक्सपोर्ट और पोर्टेबिलिटी की ईमानदार कहानी, हमारी अपनी समेत। डिस्क्लोज़र: VULK हमारा प्रोडक्ट है। 17 जुलाई 2026 को अपडेट किया गया।

तुलना तालिका: AI बिल्डर बैकएंड कैसे सँभालते हैं

"फुल-स्टैक AI बिल्डर" लेबल के पीछे तीन आर्किटेक्चर छिपे हैं। जेनरेटेड (VULK, Databutton): AI आपकी स्कीमा, एंडपॉइंट्स और auth ऐप के हिस्से के रूप में लिखता है — सबसे ज़्यादा एकीकृत, और आप जेनरेटेड सर्वर कोड पर भरोसा कर रहे हैं (यह जाँचा जा सकता है; जाँचिए)। डेलिगेटेड (Lovable, Bolt → Supabase): टूल आपके फ्रंटएंड को एक मैनेज्ड BaaS से जोड़ता है — बेहतरीन DX और साफ़ डेटा पोर्टेबिलिटी, पर आप दो प्लेटफ़ॉर्म चलाते हैं और BaaS का ढाँचा विरासत में पाते हैं। एम्बेडेड (Base44): शून्य सेटअप, शून्य निकास। कोई भी ग़लत नहीं है; बढ़ने पर वे अलग-अलग तरीक़ों से नाकाम होते हैं। कीमतें 17 जुलाई 2026 को सत्यापित।

केवल-फ्रंटएंड AI ऐप्स में असल में क्या कमी है?

किसी भी "AI ऐप बिल्डर" डेमो को चार टेस्ट से गुज़ारिए:

1. स्थायित्व: डेटा बनाइए, फिर से डिप्लॉय कीजिए — क्या वह अब भी है? मॉक-डेटा ऐप्स रीसेट हो जाती हैं। localStorage ऐप्स डेटा को एक ब्राउज़र में बंधक बना लेती हैं।
2. असली auth: क्या लॉगिन फ़ॉर्म क्रेडेंशियल सर्वर पर जाँचता है और सेशन जारी करता है? क्लाइंट-साइड "auth" सजावट है — कोई भी DevTools खोलकर उसके बग़ल से निकल सकता है।
3. सर्वर पर लागू नियम: क्या उपयोगकर्ता A अनुरोध में एक ID बदलकर उपयोगकर्ता B के रिकॉर्ड पढ़ सकता है? अगर वैलिडेशन केवल React में रहता है, तो जवाब हाँ है।
4. जाँचने योग्य डेटा: क्या आप अपने डेटाबेस पर SQL चला सकते हैं?

इनमें फ़ेल हुए तो आपके पास प्रोटोटाइप है — आइडिया परखने के लिए वाक़ई उपयोगी, और यहीं v0 जैसे टूल चमकते हैं। पर उस प्रोटोटाइप और प्रोडक्ट के बीच की खाई ठीक-ठीक बैकएंड ही है: अकाउंट, रोल्स, वैलिडेशन, रिलेशन, माइग्रेशन। यही वह हिस्सा है जो ऐतिहासिक रूप से इंजीनियरिंग का सबसे ज़्यादा समय खाता था, और यही वह हिस्सा है जिसकी VULK की 62% जेनरेशनों को आख़िरकार ज़रूरत पड़ती है (VULK प्लेटफ़ॉर्म डेटा, जुलाई 2026)।

VULK बैकएंड अपने आप कैसे प्रोविज़न करता है?

आप कभी नहीं कहते "बैकएंड जोड़ो"। डिटेक्शन आपके प्रॉम्प्ट में संकेत पढ़ता है:

• Auth संकेत — "लॉगिन", "साइन अप", "यूज़र अकाउंट", "एडमिन पैनल", "रोल्स": auth सिस्टम ट्रिगर करते हैं।
• स्थायित्व संकेत — "सेव", "स्टोर", "हिस्ट्री", "रिकॉर्ड", "डेटाबेस": स्कीमा + CRUD जेनरेशन ट्रिगर करते हैं।
• API संकेत — "एंडपॉइंट", "REST", "webhook": रूट जेनरेशन ट्रिगर करते हैं।

डिटेक्शन जान-बूझकर रूढ़िवादी है — लैंडिंग पेज या पोर्टफ़ोलियो तेज़ स्टैटिक फ्रंटएंड ही रहता है; "उपयोगकर्ता लिस्टिंग पोस्ट कर सकते हैं और विक्रेताओं को मैसेज कर सकते हैं" वाले प्रॉम्प्ट को पूरा स्टैक मिलता है। ट्रिगर होने पर, एक जेनरेशन चार समन्वित परतें बनाती है:

1. PostgreSQL स्कीमा — टेबल, टाइप, कंस्ट्रेंट, फ़ॉरेन की, इंडेक्स — आपके प्रॉम्प्ट की इकाइयों से निकाले हुए।
2. REST API — प्रति इकाई पूरा CRUD, वैलिडेशन, पेजिनेशन और सही स्टेटस कोड के साथ, VULK के API इंजन पर डिप्लॉय्ड।
3. Auth सिस्टम — रजिस्ट्रेशन और लॉगिन एंडपॉइंट, bcrypt पासवर्ड हैशिंग, JWT जारी करना, निजी रूट्स की रक्षा करता मिडलवेयर, और जहाँ प्रॉम्प्ट रोल्स का संकेत दे वहाँ रोल-चेक।
4. जुड़ा हुआ फ्रंटएंड — React ऐप इसी API के विरुद्ध जेनरेट होती है: fetch कॉलें असली एंडपॉइंट्स की ओर इशारा करती हैं, टोकन अनुरोधों से जुड़ते हैं, लोडिंग और एरर स्टेट मौजूद हैं। लॉगिन फ़ॉर्म सच में लॉगिन कराता है। यही आख़िरी परत "बैकएंड जेनरेट किया" को "दो आधे-अधूरे टुकड़े जेनरेट किए जिन्हें जोड़ने का सौभाग्य आपका है" से अलग करती है।

फिर एडिटर आपको एक बैकएंड पैनल देता है: टेबल और पंक्तियाँ ब्राउज़ कीजिए, क्वेरी रनर में सीधा SQL चलाइए, API टेस्टर से एंडपॉइंट परखिए, और कोई भी टेबल CSV में एक्सपोर्ट कीजिए। आपका डेटा कभी परदे के पीछे नहीं रहता।

जेनरेटेड SQL स्कीमा कैसा दिखता है?

स्कीमा की गुणवत्ता ऐप्लिकेशन की गुणवत्ता तय करती है, इसलिए जेनरेशन वे पैटर्न लागू करती है जो एक सावधान डेटाबेस इंजीनियर अपनाता। "एक टास्क मैनेजर जहाँ उपयोगकर्ता प्रोजेक्ट बनाते हैं और टास्क जोड़ते हैं; उपयोगकर्ता केवल अपने प्रोजेक्ट देखते हैं" के लिए:

CREATE TABLE users (
  id            SERIAL PRIMARY KEY,
  email         VARCHAR(255) UNIQUE NOT NULL,
  password_hash VARCHAR(255) NOT NULL,
  name          VARCHAR(120) NOT NULL,
  role          VARCHAR(20) NOT NULL DEFAULT 'member',
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE projects (
  id         SERIAL PRIMARY KEY,
  user_id    INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  name       VARCHAR(160) NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE tasks (
  id          SERIAL PRIMARY KEY,
  project_id  INTEGER NOT NULL REFERENCES projects(id) ON DELETE CASCADE,
  title       VARCHAR(200) NOT NULL,
  description TEXT,
  priority    VARCHAR(10) NOT NULL DEFAULT 'medium'
              CHECK (priority IN ('low','medium','high')),
  status      VARCHAR(12) NOT NULL DEFAULT 'open'
              CHECK (status IN ('open','in_progress','done')),
  due_date    DATE,
  created_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX idx_projects_user_id ON projects(user_id);
CREATE INDEX idx_tasks_project_id ON tasks(project_id);
CREATE INDEX idx_users_email ON users(email);

सोचे-समझे चुनाव — हर एक, भोले-भाले जेनरेटेड कोड की एक आम ग़लती:

• password_hash, कभी password नहीं। कॉलम का नाम ही सादे-टेक्स्ट स्टोरेज को ग़लती से लिखना नामुमकिन बना देता है — प्रॉम्प्ट-इंजीनियरिंग स्तर पर लागू एक नियम।
• सोच-समझकर तय किए डिलीट-व्यवहार वाली फ़ॉरेन कीज़ — जहाँ बच्चों को माता-पिता से आगे नहीं जीना चाहिए वहाँ ON DELETE CASCADE; जहाँ अनाथों को बचना चाहिए वहाँ SET NULL (हटाई गई कैटेगरी से आगे जीते प्रोडक्ट)।
• सीमित मानों के लिए CHECK कंस्ट्रेंट — टास्क का स्टेटस चुपचाप "donee" नहीं बन सकता।
• क्वेरी पैटर्न से मेल खाते इंडेक्स — फ़ॉरेन कीज़, लॉगिन-लुकअप ईमेल, सॉर्ट कॉलम।
• हर टेबल पर टाइमस्टैम्प। ज़रूरत पड़ने तक उबाऊ; फिर निर्णायक।

MongoDB या Firebase नहीं, PostgreSQL क्यों? क्योंकि लोग जो ऐप्स प्रॉम्प्ट करते हैं वे भारी बहुमत में रिलेशनल हैं — ऑर्डर में आइटम होते हैं, टास्क प्रोजेक्ट के होते हैं, प्रोजेक्ट उपयोगकर्ताओं के — और कंस्ट्रेंट वाली फ़ॉरेन कीज़ इसे उन अखंडता गारंटियों के साथ व्यक्त करती हैं जो डॉक्युमेंट नहीं दे सकते। और क्योंकि किसी थर्ड-पार्टी BaaS पर निर्भरता "एक प्रॉम्प्ट, चलती डिप्लॉय्ड ऐप" को दूसरी प्लेटफ़ॉर्म पर अकाउंट सेटअप से तोड़ देती। Postgres वही है जो आप प्रोडक्शन के लिए हाथ से चुनते, इसलिए वही जेनरेट होता है।

जेनरेटेड ऑथेंटिकेशन कैसे काम करता है?

पूरा auth फ़्लो, जैसा बनना चाहिए वैसा — क्योंकि auth वही परत है जहाँ जेनरेटेड शॉर्टकट सुरक्षा-उल्लंघन बन जाते हैं:

• POST /api/auth/register — इनपुट वैलिडेट करता है, पासवर्ड को bcrypt से हैश करता है (कभी सादा टेक्स्ट नहीं, कभी पलटने योग्य नहीं), password_hash में सहेजता है, JWT लौटाता है।
• POST /api/auth/login — bcrypt हैश की तुलना करता है, सफल होने पर साइन किया JWT जारी करता है। ग़लत ईमेल और ग़लत पासवर्ड पर एक जैसा एरर (अकाउंट एन्यूमरेशन नहीं)।
• हर सुरक्षित रूट पर मिडलवेयर JWT सर्वर-साइड सत्यापित करता है; फ्रंटएंड उसे अपने आप जोड़ता है।
• क्वेरियों में पंक्ति-स्तर स्वामित्व — सत्यापित टोकन से WHERE user_id = $1, ताकि URL में ID बदलने से किसी और की पंक्तियाँ न पढ़ी जा सकें।
• रोल्स, जब प्रॉम्प्ट में हों ("एडमिन प्रोडक्ट मैनेज कर सकता है") — मिडलवेयर में जाँची जाती role कॉलम, केवल-एडमिन एंडपॉइंट, और उसके अनुरूप कंडीशनल UI।

Auth के साथ-साथ, बिना-विकल्प वाले सुरक्षा डिफ़ॉल्ट: हर जगह पैरामीटराइज़्ड क्वेरियाँ (स्ट्रिंग-जोड़ा SQL नहीं), हर एंडपॉइंट पर सर्वर-साइड इनपुट वैलिडेशन, ऐप के ओरिजिन तक सीमित CORS, और auth एंडपॉइंट्स पर रेट लिमिटिंग। लॉन्च से पहले जेनरेटेड ऑथराइज़ेशन लॉजिक की समीक्षा वैसे ही कीजिए जैसे एक तेज़ जूनियर डेवलपर के काम की करते — पैटर्न सही हैं; आपकी ऐप के ख़ास "कौन किसका डेटा देख सकता है" नियम इंसानी नज़रों के हक़दार हैं।

फुल-स्टैक ऐप्स के लिए 6 पूरे कॉपी-पेस्ट प्रॉम्प्ट

हर एक पूरा है और जान-बूझकर बैकएंड जेनरेशन को काम पर लगाता है — अकाउंट, रिलेशन, रोल्स, एग्रीगेशन। जस का तस चिपकाएँ।

1. टीमों वाला SaaS टास्क मैनेजर:

Taskframe नाम की टास्क मैनेजमेंट ऐप बनाओ जहाँ उपयोगकर्ता साइन अप करते हैं, प्रोजेक्ट बनाते हैं और शीर्षक, विवरण, प्राथमिकता (कम/मध्यम/उच्च), नियत तारीख़ और स्टेटस (खुला/जारी/पूरा) वाले टास्क जोड़ते हैं। उपयोगकर्ता ईमेल से साथियों को प्रोजेक्ट में आमंत्रित कर सकते हैं; सदस्य साझा प्रोजेक्ट देखते हैं, पर प्रोजेक्ट डिलीट करना या सदस्य हटाना केवल प्रोजेक्ट मालिक कर सकता है। व्यू: कॉलमों के बीच ड्रैग वाला स्टेटस-आधारित बोर्ड, और सॉर्ट व फ़िल्टर वाला लिस्ट व्यू। डैशबोर्ड सभी प्रोजेक्ट्स के मेरे खुले टास्क नियत तारीख़ के क्रम में दिखाए, देर वाले लाल में। साफ़ हल्की UI, इंडिगो एक्सेंट।

2. एडमिन पैनल वाला ई-कॉमर्स स्टोर:

Kiln & Co. नाम का हस्तनिर्मित सिरैमिक का ऑनलाइन स्टोर बनाओ। ग्राहक कैटेगरी फ़िल्टर वाली प्रोडक्ट ग्रिड ब्राउज़ करते हैं, प्रोडक्ट डिटेल पेज देखते हैं, कार्ट में जोड़ते हैं और चेकआउट करते हैं (शिपिंग पते का फ़ॉर्म + मॉक भुगतान), जिससे उनके अकाउंट में सहेजे इतिहास वाला ऑर्डर बनता है। एडमिन रोल: अलग /admin क्षेत्र जिसमें प्रोडक्ट मैनेजमेंट (नाम, कीमत, स्टॉक, कैटेगरी, विवरण के साथ प्रोडक्ट बनाना, संपादित करना, आर्काइव करना), स्टेटस अपडेट वाली ऑर्डर सूची (लंबित/भेजा/डिलीवर) और महीने-दर-महीने आमदनी का सार। ऑर्डर पर स्टॉक घटता है; शून्य स्टॉक वाले प्रोडक्ट बिक चुका दिखाते हैं और ऑर्डर नहीं हो सकते। गर्म मिनिमल डिज़ाइन, टेराकोटा एक्सेंट।

3. बुकिंग प्लेटफ़ॉर्म:

एक योग स्टूडियो के लिए बुकिंग ऐप बनाओ। सार्वजनिक: हफ़्ते का क्लास शेड्यूल (नाम, शिक्षक, समय, बची सीटें), साइनअप और लॉगिन। सदस्य किसी क्लास में सीट बुक करते हैं — क्षमता सर्वर-साइड लागू हो ताकि भरी क्लास और बुकिंग नकार दे — और शुरू होने से 2 घंटे पहले तक रद्द कर सकते हैं। मेरी बुकिंग पेज आगामी और बीती क्लासें दिखाए। स्टाफ़ रोल: क्लास बनाना और संपादित करना (नाम, शिक्षक, वार, समय, क्षमता), प्रति क्लास सूची देखना और हाज़िरी दर्ज करना। एक ही सदस्य की एक ही क्लास में दोहरी बुकिंग रोको। शांत सेज-और-क्रीम डिज़ाइन।

4. ग्राहक फ़ीडबैक बोर्ड:

एक मिनिमल प्रोडक्ट रोडमैप टूल जैसा सार्वजनिक फ़ीडबैक बोर्ड बनाओ। लॉगिन किया कोई भी व्यक्ति आइडिया भेज सकता है (शीर्षक, विवरण, कैटेगरी) और दूसरों को अपवोट कर सकता है — प्रति उपयोगकर्ता प्रति आइडिया एक वोट, टॉगल होने वाला। आइडिया वोट या नएपन से क्रमबद्ध हों; हर एक में कमेंट थ्रेड हो। एडमिन रोल: आइडिया का स्टेटस बदलना (समीक्षा में/योजित/जारी/शिप्ड), आइडिया पिन करना और स्पैम हटाना। सार्वजनिक रोडमैप पेज आइडिया को स्टेटस के अनुसार कॉलमों में बाँटे। स्टेटस बदलाव आइडिया की एक्टिविटी फ़ीड में दिखें। डार्क थीम, इलेक्ट्रिक ब्लू एक्सेंट।

5. इनवॉइसिंग ऐप:

फ्रीलांसरों के लिए इनवॉइसिंग ऐप बनाओ। उपयोगकर्ता क्लाइंट मैनेज करते हैं (कंपनी, संपर्क नाम, ईमेल, पता) और इनवॉइस बनाते हैं: क्लाइंट, लाइन आइटम (विवरण, मात्रा, इकाई मूल्य), कर दर, नियत तारीख़, और प्रति उपयोगकर्ता स्वतः बनता क्रमिक इनवॉइस नंबर। इनवॉइस स्टेटस: ड्राफ़्ट, भेजा, भुगतान हुआ, अतिदेय — अतिदेय नियत तारीख़ से अपने आप निकले। डैशबोर्ड: बक़ाया कुल, इस-महीने-भुगतान, अतिदेय गिनती, और 6-महीने का आमदनी बार चार्ट। साझा करने योग्य लिंक पर प्रिंट-अनुकूल लेआउट वाला सार्वजनिक रीड-ओनली इनवॉइस पेज। पेशेवर स्लेट-और-सफ़ेद डिज़ाइन।

6. कम्युनिटी रेसिपी प्लेटफ़ॉर्म:

एक कम्युनिटी रेसिपी-शेयरिंग प्लेटफ़ॉर्म बनाओ। उपयोगकर्ता रजिस्टर करते हैं, रेसिपी प्रकाशित करते हैं (शीर्षक, फ़ोटो प्लेसहोल्डर, सामग्री सूची, क्रमांकित चरण, पकाने का समय, कठिनाई, टैग) और केवल अपनी ही संपादित या डिलीट करते हैं। सब लोग टैग से या शीर्षकों व सामग्री पर फुल-टेक्स्ट खोज से ब्राउज़ करते हैं; हर रेसिपी पर स्टार रेटिंग (प्रति उपयोगकर्ता एक, संपादन योग्य) औसत रेटिंग के क्रम में, साथ में कमेंट। उपयोगकर्ता प्रोफ़ाइल उनकी रेसिपी और सहेजे पसंदीदा दिखाए। होमपेज: इस हफ़्ते की सर्वोच्च रेटेड और सबसे नई। मॉडरेटर रोल रेसिपी और कमेंट हटा सकता है। सेरिफ़ हेडिंग के साथ ताज़ा हरा-और-क्रीम डिज़ाइन।

पैटर्न पढ़िए: इकाइयों और उनके फ़ील्ड का नाम लीजिए, बताइए कौन क्या कर सकता है ("केवल मालिक डिलीट कर सकता है"), और वह हर नियम बताइए जो टिकना चाहिए ("क्षमता सर्वर-साइड लागू", "प्रति उपयोगकर्ता एक वोट")। वही वाक्य फ़ॉरेन कीज़, मिडलवेयर और कंस्ट्रेंट बन जाते हैं।

फुल-स्टैक ऐप्स में डिप्लॉयमेंट और प्रीव्यू कैसे काम करते हैं?

जेनरेशन के दौरान फ्रंटएंड hot reload वाली लाइव-प्रीव्यू microVM में चलता है, और पहले से ही असली जेनरेटेड API से बात कर रहा होता है — प्रीव्यू में आप जो साइनअप टेस्ट करते हैं वह असली पंक्तियाँ लिखता है जिन्हें आप तुरंत बैकएंड पैनल के टेबल ब्राउज़र में देख सकते हैं या सीधे SQL से क्वेरी कर सकते हैं। डिप्लॉय करने पर फ्रंटएंड Cloudflare की edge पर और बैकएंड + PostgreSQL VULK के इंफ्रास्ट्रक्चर पर जाता है — एक क्लिक, लाइव URL, कस्टम डोमेन समर्थित। बैकएंड + PostgreSQL डिप्लॉय Builder टियर ($19.99/माह) से ऊपर शामिल हैं; डिप्लॉय के बाद की इटरेशन वही फ़ॉलो-अप-प्रॉम्प्ट लूप है, जिसमें स्कीमा बदलाव डेटा-नष्ट करने वाले रीबिल्ड नहीं बल्कि माइग्रेशन के रूप में सँभाले जाते हैं।

क्या आप सब कुछ एक्सपोर्ट करके जा सकते हैं? (ईमानदार जवाब)

यह सवाल हर प्लेटफ़ॉर्म से 10,000 उपयोगकर्ता होने से पहले पूछना चाहिए। VULK के जवाब का एक हिस्सा मज़बूत है और एक सीमित — दोनों, ठीक-ठीक:

जो साफ़-साफ़ एक्सपोर्ट होता है:

• फ्रंटएंड का पूरा सोर्स — ZIP डाउनलोड या GitHub पुश; बिना किसी प्रोप्राइटरी निर्भरता वाला स्टैंडर्ड React + Vite + TypeScript प्रोजेक्ट।
• आपकी पूरी स्कीमा — schema.sql सोर्स एक्सपोर्ट में साथ जाता है।
• आपका सारा डेटा — बैकएंड पैनल से प्रति-टेबल CSV एक्सपोर्ट (पूरी टेबल, सिर्फ़ दिखता पन्ना नहीं), साथ में क्वेरी रनर से सीधा SQL एक्सेस।

जो नहीं होता: बैकएंड का रनटाइम। जेनरेटेड CRUD एंडपॉइंट्स और auth परोसने वाला API इंजन VULK का होस्टेड इंफ्रास्ट्रक्चर है, और एक्सपोर्टेड फ्रंटएंड उसे उसके होस्टेड URL पर कॉल करता है। फुल-स्टैक ऐप एक्सपोर्ट कीजिए और फ्रंटएंड कहीं भी चलेगा — पर वह VULK की API से ही बात करता रहेगा। पूरी चीज़ सेल्फ़-होस्ट करने का मतलब है API परत दोबारा लागू करना (आपकी एक्सपोर्टेड स्कीमा और डेटा पूरी स्पेसिफ़िकेशन हैं — Express-या-कुछ-भी में सीमित दायरे का पुनर्निर्माण, पर असली काम)।

बाज़ार के बाक़ी लोग इसी सवाल का क्या जवाब देते हैं, उसका संदर्भ: Lovable/Bolt की डेटा पोर्टेबिलिटी सबसे साफ़ है — Supabase प्रोजेक्ट आपका है, pg_dump और चलिए (edge functions और RLS नीतियों वाला बैकएंड लॉजिक फिर भी माइग्रेट करना होगा)। Replit कोड की पूरी पहुँच देता है; VM आपकी है। Base44 में बैकएंड एक्सपोर्ट है ही नहीं। केवल-फ्रंटएंड टूल इस सवाल से यूँ बचते हैं कि आपका डेटा उनके पास कभी था ही नहीं। जो भी टूल चुनें: एक्सपोर्ट का रास्ता पहले हफ़्ते में परखिए, बारहवें महीने में नहीं।