Overview

Explanation

The code MaShop generates is yours. It lives in a GitHub repository on your account and reads from a Supabase project on your account. MaShop hosts the builder where you talk to the AI; it does not host your store or your customer data. This page explains what the repository contains, where the two halves of your project live, and what "you own it" means in practice.

Two places your project lives

A MaShop project has exactly two homes, and both belong to you:

MaShop itself stores only a pointer to each: the projects row records your github_repo and github_branch, plus supabase_url, supabase_project_ref, and supabase_anon_key. The Supabase service-role key is stored encrypted at rest, the same way OAuth tokens are. Your products, orders, and customers never sit on a MaShop server.

How the repository gets created

When you provision a project, MaShop creates the GitHub repository for you. The provisioning step calls createForAuthenticatedUser with private: true and auto_init: true, so the repo starts with one initial commit (a README, a LICENSE, and a .gitignore) on the main branch. If a repo of that name already exists on your account, MaShop reuses it instead of failing, so a retried provision never creates a duplicate.

The repository name is derived from your project slug: lowercased, non-alphanumeric characters replaced with hyphens, trimmed to 90 characters, and prefixed with mashop-. A project with slug my-coffee-shop becomes the repo mashop-my-coffee-shop.

What the repository contains

What lands in the repo depends on how the project was created, but in every case it is a complete Next.js 15 application you can build and run yourself.

The starter scaffold

When the AI starts from an empty repo, it runs a one-time scaffold that commits a buildable Next.js 15 project. That scaffold writes these files, each as its own commit:

Path	What it is
package.json	Dependencies and scripts
tsconfig.json, next-env.d.ts	TypeScript config
next.config.ts	Next.js config
tailwind.config.ts, postcss.config.mjs	Tailwind CSS v4 setup
eslint.config.mjs	Lint rules
app/layout.tsx, app/page.tsx, app/globals.css, app/icon.tsx	App Router root, home page, styles, favicon
app/api/checkout/route.ts	Checkout route handler (placeholder until you wire a provider)
components/Header.tsx, components/Footer.tsx	Shared layout components
lib/supabase.ts	Supabase client reading your env vars
lib/products.ts, lib/types.ts, lib/utils.ts, lib/seo.ts	Data access, types, helpers, SEO and JSON-LD helpers
.env.local.example, netlify.toml, README.md, .gitignore	Local env template, Netlify config, docs

The Supabase client reads your own database. It calls createClient with NEXT_PUBLIC_SUPABASE_URL and the anon key from the environment, so the deployed app talks to the Supabase project on your account, not to MaShop:

import { createClient } from '@supabase/supabase-js';
const url = process.env.NEXT_PUBLIC_SUPABASE_URL;
const anonKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY;
export const supabase = createClient(url ?? '', anonKey ?? '');

The checkout route is a placeholder, not a configured payment integration. Until you ask MaShop to wire a provider, it returns a clear message rather than charging a card:

{ "error": "Checkout not yet configured. Ask MaShop to wire Stripe." }

You choose the payment provider. The scaffold does not commit you to one; you ask the AI to wire the provider you want, and the checkout route is rewritten to match.

The backoffice template

When you provision a project through onboarding, MaShop also pushes a full Next.js 15 backoffice into the same repository as a single follow-up commit. This is the turnkey admin for managing products, orders, customers, payments, analytics, and a blog. It is the same code you would build by hand, and it arrives ready to run. The commit message reads feat: scaffold merchant backoffice from MaShop template.

SQL migrations

Your database schema lives in the repo too. When the AI changes your database, it writes a versioned migration file into the repository and applies the same SQL to your Supabase project. During onboarding, MaShop applies the backoffice template's migrations to your new Supabase project before the first build, so the tables the admin expects exist from day one.

What "you own it" means

Ownership here is literal, not a slogan. The repo sits on your GitHub account and the database sits on your Supabase account, so the normal account-owner actions are all available to you:

• Clone it. The repo is standard Git. Clone it, run pnpm install, copy .env.local.example to .env.local, fill in your Supabase keys, and run pnpm dev on your own machine.
• Edit it. Change any file by hand and commit, or keep talking to the AI in the workspace. Both write to the same repo. Nothing is locked or minified.
• Publish it. The repo is private when created, but it is yours to make public, transfer, or branch however you like.
• Delete it. Delete the GitHub repo and the Supabase project from their own dashboards whenever you want. MaShop holds only the pointers, not the code or the data.

The generated README says the same thing in one line: your code is yours to fork, edit, and deploy anywhere.

Where deployment fits

Deployment is a separate step that reads from these two homes. Netlify is the deployment target. When you deploy, MaShop connects your repository to a Netlify site and sets your Supabase URL and keys as environment variables on that site, so the live app reads from your own database. Vercel is not a deployment target in MaShop. See Deploy: overview for the full flow.

Read next

• Structure: a deeper tour of the folders and files in your repo.
• Conventions: the patterns the generated code follows.
• Supabase: how your database, auth, and storage are wired.
• GitHub: how the repo connection works.