From Prototype to Live: GitHub, Vercel and Supabase, No Code
A non-coder's step-by-step guide to taking an app live: move code off Base44 to GitHub, deploy on Vercel, wire up Supabase, and point your own domain.
By William Ifeanyi Moore · 2026-07-28 · 10 min read
From Prototype to Live: GitHub, Vercel and Supabase, No Code
In Part One I got HVNG from an idea to a working prototype without writing code. This part is the migration: how I took it out of the prototype world and onto the real internet, on its own infrastructure, with its own name, still as a non-coder. You will learn the three-worker mental model of a live platform, why you cannot actually break anything, and the exact steps to go from a repository to a domain people can type into a phone.
Key takeaways
- GitHub feels like a dentist's chair. The dread is about the room, not the task, and the task is smaller than the fear at the door.
- You do not have to know how things work in order to do them. Ask the AI for a step-by-step guide and follow the steps.
- You can almost always roll back, and most logic is walled off inside its own function. Breaking one thing rarely breaks everything.
- A live platform is three workers: GitHub (source), Supabase (memory), Vercel (engine).
- Cross-pollinate everything. The more platforms your AI can see, the more invisible problems it catches for you.
- Buying and pointing a domain is easier than buying concert tickets on release day.
Where we left off
Last time, I left you on a cliff. The responsible version of me had called a coding friend to help with the migration. And then impatience struck, the same impatience that started this whole thing, and a voice said: you have come this far alone, you can do this too.
So I hung up the responsible plan and started the migration alone.
This gets more technical than Part One, but I promise you the same thing I promised at the start: every wall in this story is a doorway. Let me show you the doors.
How to set up GitHub when you have never used it
The migration started with the single most off-putting step for a non-coder. I had to open a GitHub account.
I need to be honest about how this feels, because if I pretend it is easy I am not helping you. For a non-technical person, opening GitHub feels like being marched into the dreadful place engineers go to do their dreadful things. It is a version of being taken to the dentist. You do not want to be there. Everything about it signals this room is not for you.
I got lucky. Over the years, working with other products at a marketing and management level, I had brushed against GitHub enough that the dread had worn down to a dull discomfort instead of full panic. So I was not starting from terror.
And I will be transparent about the limits of my own courage. There is another platform that gives writers this exact dread, and that one is Excel, and I am not sure I will ever get over it in this lifetime. So I am not pretending to be fearless. The fear is normal, and you walk through it anyway.
So I opened the GitHub account. Then I connected it to my Base44, and I migrated the code into a repository on GitHub.
The dread is about the room, not the task. Walk into the room you have been avoiding. The task inside it is almost always smaller than the fear standing at the door.
The professional already lives in your computer
Now, the obvious question. How did you know how to do any of that? Connect GitHub to Base44? Migrate a code repository? You said you are not technical.
You will not believe the answer. I asked AI.
If there is one single thing you carry out of this entire piece, write this one down:
You do not have to know how things work in order to do them. The AI can guide you through any process, step by step.
That professional you have been dreaming of hiring, the one you cannot afford, the one who would set all this up for you? They already live inside your computer. They are sitting there right now, fully qualified, infinitely patient, waiting for you to ask them the right question.
And here is how you ask. Do not be too proud. Do not be scared to act like a toddler. Open the chat and say exactly this: "Claude, assume I have no technical experience and I have never done this before. I need a step by step guide." That sentence is a magic key. It changes the entire register of the help you get back.
When you get lost in the middle of a step, do not freeze. Screenshot your screen and paste it in for guidance. The model can see what you are seeing and tell you what to click next. Base44 has AI inside it. ChatGPT will do this. Google's AI mode will do this. If you already have Claude, same thing. Even the most basic of these models will give you a walkthrough for almost anything you need.
I followed the steps. That is the whole secret. I asked like a beginner, and I followed the steps.
Why you cannot actually break it
Let me kill the fear that stops more people than any other: the fear that you will touch something, break it, and the whole thing will collapse into an unfixable mess.
Two things, and please absorb both.
First: you can almost always roll back to an older version. The fear assumes a mistake is permanent. It is not. There is an undo button on this whole journey, and it works. So the catastrophe you are imagining cannot actually happen the way you imagine it.
Second, and this is the one that really frees you: most logic is localised inside its own function. Breaking the comment section is not going to suddenly break the search. The search does not even know the comment section is having a bad day. Things are walled off from each other far more than your panic believes.
So, and I say this with love: relax, bro and broette. You are too scared. The system is more forgiving than your fear is telling you.
Nothing here is permanent and nothing here is as connected as it feels. You have a rollback, and you have walls between the parts. Build like someone who knows that.
Out of prison, into the wild
Once the code had moved into the GitHub repository, I felt a particular kind of freedom. I had escaped Base44's platform lock-in. The code was mine now, sitting in a place I controlled, not trapped inside someone else's house. It felt like walking out of prison.
But my woes were only at the genesis. Yes, the code was free. But free code is not a living product. A repository sitting on GitHub does not serve anybody. It does not load on a phone. It does not breathe. I had liberated it, and now it was just lying there, lifeless, waiting for me to bring it to life by myself.
So, as I now did with everything, I asked the AI: the code is free, what do I need to actually make this thing run?
The three workers you need to hire
The AI told me exactly what to assemble. Think of it as hiring a small team, except the team costs almost nothing and never sleeps.
Worker one: Vercel, to run the server infrastructure. A monkey like me has no business touching raw server infrastructure directly, and Vercel means I do not have to. It also gives you things like edge functions, which are key for scaling and speed. I am not going to explain every new term I picked up on this road, because we would be here till next year. But two promises. One, you will learn these terms naturally on your own journey, just by doing. Two, if you want a confidence boost, the community has resources, plain-language explanations of the terms and how-tos for the steps, and it is free for members.
Worker two: Supabase, to handle hosting and the database. Here is the maths that made me laugh out loud. For about twenty-five dollars, I could host on the order of a hundred thousand users. Let me put that plainly. If I cannot build a business that turns a hundred thousand users into enough money to cover twenty-five dollars, then I am not in a difficult business, I am simply in the wrong one, and also an idiot. That price point is part of why a single person can now do this at all. (Pricing on these platforms shifts, so always check the current plan before you quote it, but the order of magnitude is the point: it is absurdly cheap to start.)
Worker three: Claude itself, on the desktop. I already had a Claude subscription for my regular work, but I had never bothered downloading the desktop app, because I had never needed it for coding. And yet here I was, downloading away. That download is the moment the assistant stops being a chat window and becomes something that can actually reach into your project and work.
You are not building alone and you are not building everything yourself. You are assembling a team of specialists, each one handling the part you should not have to understand.
Cross-pollinate everything: give the AI eyes
Once the workers were hired, the real unlock was connecting them all together using their API and security keys.
I want to slow down here, because this step is especially important for non-technical people, and most guides do not explain why. When you connect these platforms to your AI, you are giving the AI eyes. You are letting it check things that you yourself do not even have the knowledge to know you should be checking. You do not know what you do not know. But the AI does, and the more access it has, the more of those invisible problems it can catch and fix on your behalf.
So the principle is simple: cross-pollinate everything. Make sure all the platforms are connected, and make sure Claude has access to all of them. The more it can see, the more it can help.
My pro-tip, the one that will save you a headache: use the same GitHub account to sign up for both Vercel and Supabase. When they all share one identity, the connecting is just easier. Fewer logins, fewer mismatches, fewer little walls between your workers.
Access is help. Every door you open for the AI is a problem it can now solve for you that you could not even have named.
The wiring: migrating off Base44 onto your own stack
Now the satisfying part, the moment it starts becoming real.
Once Supabase, Vercel, and GitHub are all connected to your Claude, you give it the instructions in order. First, you tell Claude to look at the codebase in GitHub and adapt it for Claude and away from Base44. The code was written to live inside Base44's world, and now it needs to stand on its own, so you have it re-shaped for its new home. Then, once that is done, you ask it to wire in Supabase as the database layer, so the application has a real place to store and pull its data from.
This takes some time. Do not panic at the waiting, the waiting is normal. But when it is finished, something quietly miraculous has happened. You will have a site you can actually load, live, at a vercel.com URL.
Sit with that for a second. The thing that was lifeless code in a repository is now a website you can open. It is alive. You did that.
Putting your name on the door: buying and pointing a domain
A vercel.com URL is alive, but it is still living in someone else's building. The last stage is putting your own name on the door, your own domain.
Here is the whole process, demystified. You buy a domain from GoDaddy, or whoever you like, they all work. Then you go into Vercel, into the domain section, and you copy the CNAME it gives you. (Vercel shows you the exact record to copy and where it goes, so you are never guessing.) You paste that into your GoDaddy settings, and that connection tells the internet to start sending people to your site instead of the generic URL.
And I will say it again, because it is the spine of everything I am teaching: all of these platforms have their own AI chat built in. Vercel has one. Supabase has one. Claude is one. When you are unsure of a step, ask the platform's own assistant for guidance. That is literally why they put it there.
So do not be scared of this part either. I swear to you, it is easier to buy and point a domain than it is to buy concert tickets on a release day. And remember the rule from earlier: there is no step here you cannot take back.
Once you have set the domain redirection, you can watch it happen. Go to Google, search for any DNS propagation checker, and you can literally see your domain switching on across the world, country by country. Quick pro-tip: set your Vercel region to Europe, because it is the closest available region to us in Africa, which means faster load times for your local users. Propagation can take anything from an hour to twenty-four hours, so be patient. And then, when it has spread everywhere, your URL and your platform are live. Properly, publicly live.
Your own domain is not vanity. It is ownership. It is the difference between renting a stall in someone's market and having an address people can find on their own.
Hands-on lab
The chapter above is the why. These guides are the how. The one rule never changes: if a step stumps you, screenshot it and paste it to your AI with "assume I have no technical experience; tell me exactly what to click next." Nothing here cannot be undone.
G2.1 · Move your code from Base44 to GitHub [Core]
What you'll have: Your Base44 app's code living in your own GitHub repository, out of platform lock-in.
Before you start: Beginner · ~15 min · GitHub is free; the Base44 to GitHub connection needs Base44's Builder plan or higher · you'll need your Base44 project and an email
- Get a GitHub account at github.com if you do not have one (sign up, verify email).
- Open your project in Base44.
- Click "Code" in the top navigation bar. Your file structure appears; you never have to read it.
- Click the GitHub icon in the top navigation bar. (An upgrade prompt means you need the Builder plan, or use the ZIP fallback below.)
- Follow the prompts to connect and authorise your GitHub account; approve the request to create and push to a repository you own.
- Let Base44 create the repository and push your code; give it a moment.
- Verify on github.com: open the new repository and see your files.
Check you did it right: You can open github.com/your-username/your-repo and see your files and a commit history.
If something looks off: Upgrade prompt on the GitHub icon → upgrade, or in Code view use the download / export-as-ZIP icon and upload to a new GitHub repo (ask the AI to walk you through). Won't authorise → confirm you are logged into the right GitHub account in the same browser. Files not showing → wait a minute and refresh.
G2.2 · Set up Vercel and connect it to GitHub [Core]
What you'll have: Your site running on real infrastructure, auto-deploying from GitHub.
Before you start: Beginner · ~15 min · free tier to start · you'll need your GitHub repo
- Go to vercel.com and sign up with "Continue with GitHub" (use the same GitHub account, it keeps everything simple).
- Authorise Vercel to access your GitHub.
- Click "Add New → Project" and import your repository.
- Vercel auto-detects the framework; leave the defaults unless Claude told you otherwise.
- Click Deploy and wait. You get a live vercel.app URL.
Check you did it right: Your vercel.app URL loads your app.
If something looks off: Build fails → copy the error log, paste to Claude, ask for the fix. Wrong repo imported → re-import the right one.
G2.3 · Set up Supabase as your database [Core]
What you'll have: A real, scalable place for your data, with built-in authentication.
Before you start: Beginner · ~20 min · free tier; Pro ~$25/mo later (check current) · same GitHub login recommended
- Go to supabase.com and sign up with Continue with GitHub.
- Create a new project; set a strong database password and save it somewhere safe (never paste it into random chats).
- Choose a region close to your users (Europe is closest to West Africa).
- Wait for it to provision.
- Find your Project URL and keys under Project Settings → API.
Check you did it right: Your Supabase project dashboard is live.
If something looks off: Lost the database password → reset it in settings.
G2.4 · Install Claude on desktop and point it at your project [Core]
What you'll have: Claude able to actually work on your codebase, not just chat.
Before you start: Beginner · ~15 min · Claude subscription · you'll need a Claude account
- Download the Claude desktop app and sign in.
- For hands-on coding, use Claude Code (Anthropic's agentic coding tool); follow the current install steps at docs.claude.com, since they change.
- Connect it to your project so it can read and edit your code.
- Give it context: "this is my app, migrated from Base44, hosted on Vercel, database on Supabase."
Check you did it right: Claude can see and describe your project files.
If something looks off: Can't see files → make sure the repo is cloned/open locally; ask Claude to guide the clone.
G2.5 · Connect everything with API and security keys [Core]
What you'll have: Vercel, Supabase, and Claude all talking to each other, so the AI can see and fix the whole system.
Before you start: Beginner–Intermediate · 20–30 min · free · you'll need your Supabase keys
- In Supabase → Project Settings → API, copy your Project URL and the public (anon) key; keep any secret/service key private.
- Add these as environment variables: in Vercel → Project → Settings → Environment Variables, and in your local .env file. Ask Claude exactly where each one goes.
- Use the same GitHub login across Vercel and Supabase to keep connections simple.
- Give Claude access so it can read your config and catch issues you would not know to look for.
- Never paste secret keys into public places or random chats; store them only in your env config.
Check you did it right: Your app reaches Supabase (a test query works) and Claude can see the setup.
If something looks off: "Invalid API key" → re-copy exactly and check you used the right key type.
G2.6 · Have Claude adapt your code off Base44 and wire in Supabase [Core]
What you'll have: Your app standing on its own, with Supabase as its database.
Before you start: Intermediate · 1–3 hrs (mostly waiting) · free · you'll need G2.1–G2.5 done
- Tell Claude: "Look at the codebase in GitHub and adapt it to run independently, away from Base44."
- Let it work, and review the changes.
- Then: "Wire in Supabase as the database layer using these environment variables."
- Test on a local run or a Vercel preview deploy.
- Paste any error to Claude and ask for the fix.
Check you did it right: The app runs on your own stack, reads and writes to Supabase, with no Base44 dependency.
If something looks off: Something breaks → roll back (you can always roll back) and fix function by function; breaking one rarely breaks others.
G2.7 · Buy a domain and point it to Vercel [Core]
What you'll have: Your app live on your own web address.
Before you start: Beginner · ~20 min plus propagation · ~$10–15/yr for the domain · you'll need a deployed Vercel app
- Buy a domain from GoDaddy or any registrar.
- In Vercel → your project → Settings → Domains, add your domain.
- Vercel shows the exact DNS record(s) to add (a CNAME for www, and/or an A record for the root; it tells you which).
- Copy those records into your registrar's DNS settings.
- Save; Vercel verifies once the records propagate.
Check you did it right: Typing your domain loads your app (may take up to 24h).
If something looks off: "Invalid configuration" → match the record type and value to Vercel exactly; each registrar words it differently, so screenshot and ask the AI.
G2.8 · Confirm your domain is live and set your Vercel region [Optional]
What you'll have: Confidence it works worldwide, and faster loads for your users.
Before you start: Beginner · ~10 min plus wait · free · you'll need G2.7 done
- Search Google for a "DNS propagation checker," enter your domain, and watch it activate across regions.
- Be patient; propagation takes from an hour to 24 hours.
- In Vercel settings, set your region to a European one (closest to West Africa) for speed.
Check you did it right: The checker shows your domain resolving globally and the site loads quickly.
If something looks off: Not resolving after 24h → recheck the DNS records from G2.7.
The whole machine in one mental model
Once you hold this, the whole thing stops being mysterious. Three parts, three jobs:
The code that makes your site work lives in GitHub. That is your source of truth, your manuscript. Supabase is the database it pulls from, the memory, where all the real information lives. And Vercel is the engine that runs the whole thing smoothly and serves it to the world. Source, memory, engine. That is your platform. That is not magic. That is just three workers doing three jobs, coordinated by an assistant who lives in your laptop.
Now zoom all the way out.
In Part One, I told you HVNG died once. It died in a drawer, years ago, because a non-technical person could not afford to build it. Today, that same idea, built by that same non-technical person, is sitting live on the internet on its own domain. Nobody hired. No team. No funding round to pay developers. The wall that killed it the first time was real then, and it is simply gone now.
That is what AI has done. And we have not begun to understand how deep this goes. It is going to rearrange the economy in ways none of us can fully picture, because the question is no longer can you afford to build it. The question is now only will you sit down and do it.
But hear my real ask once more. Learn this, and then do not build alone. The solo model is not how we win, and especially not here. Africa has to move as an ecosystem. Some of us will share hosting. Some of us will share tokens. We pool what we have so no good idea dies in a drawer for lack of twenty-five dollars and a little courage.
The code is just a novel. The dentist's chair is just a room. The domain is easier than concert tickets. And the only thing standing between you and a live platform is the decision to sit down and ask the first question.
What's next
You now have a live product on your own infrastructure and your own domain. Part Three moves from building it to running it as a business: taking money, serving paying customers, becoming discoverable, and shipping native to iOS and Android.