Vibe coding course with Gemini and Antigravity: from idea to an app that earns

The seventh course in MONA's free AI course series, and the one for Team Google in the AI coding tool race: vibe coding with Gemini 3.1 and Antigravity, the free AI coding environment Google launched to take on Claude Code head to head. Vibe coding, put simply, is building software with words: you describe what you want, the AI writes the code, you look at the result and keep “nudging” it with words until you are happy. This course is built on the 6.5-hour curriculum our team studied, filtered and localized into Vietnamese: from installing Antigravity and building your first website in 15 minutes, to building three full apps with login, a database and payments, and ending with something few courses teach: pricing and selling what you just made. If you have already taken the Claude Code course in this series, treat this as the matching piece from Google's side. If you have not taken any, you can start right here: the course stands on its own.

Part 1: What is vibe coding, and why the Gemini 3.1 and Antigravity pair is worth learning

In the three earlier Claude Code courses, you saw the philosophy of “AI does, humans command.” Vibe coding is the popular name for that very way of working, seen from the non-specialist's side: instead of learning syntax, you learn how to brief, inspect the result, and give feedback. Those three skills, plus a decent toolkit, are enough for a business person to build internal tools, a landing page, even a small paid software service.

The toolkit for this course has three items, and the reason for each is very practical:

• Antigravity (download at antigravity.google): Google's AI coding environment, currently for free, and signing in with a Google account is all it takes. It has Gemini 3.1 Pro built in, plus other vendors' models you can call.
• Gemini 3.1 Pro: the main brain. A strength confirmed by both the community and our own experience: among the best interface work of any model today. Design, layout, effects: hand them to Gemini.
• Claude Code (it already has a full course of its own): bring it in for solid backend architecture and security review. This course teaches you how to get the two models working on one project, each at what it does best, instead of arguing over which is better.

An honest word before we start, in the spirit of all our courses: vibe coding will not turn you into a software company overnight. It is extremely strong for three things: building prototypes to test an idea, making internal tools for your own company, and understanding the craft well enough to work smartly with an engineering team. A system that carries real revenue and holds the data of thousands of real customers needs more, and this course will point that out rather than hide it: security, testing, and someone accountable. The final part of the course draws that line clearly.

Part 2: Installing and mastering Antigravity: three panes and the agent panel

Installation really takes 10 minutes: go to antigravity.google, download the version for your machine (on a Mac, check whether you have Apple Silicon or Intel under “About This Mac”; on Windows, run the installer and click agree a few times), open it, and sign in with Google. Done. No credit card, no extra configuration.

The main screen is divided into ba khung, and once you know these three panes you are no longer lost:

• Left: Explorer, the project folder tree, like Finder. Right-click to create, rename or delete files; there is even a “timeline” showing what changes a file has gone through.
• Middle: the editor, where you open files to view code. Markdown files have a button for a rendered view. Antigravity also has its own file type called walkthrough: the AI writes a report of what it just did, with a button to approve and comment on each item.
• Right: the agent panel, the heart of the tool, opened with the button in the top right corner. This is where you give the brief and the AI works.

The agent panel has several valuable features that newcomers often miss:

• Two conversation modes: Planning (the model makes a plan and shows it for your approval before touching any file) and Fast (just do it). The rule to memorize: for new features and big jobs, open with Planning; for small one-shot jobs, use Fast. This is exactly the “plan mode” you met in the Claude Code course, with the same mindset.
• Rules and Workflows: Rules are fixed behavior rules (set them to “Always on” to be safe; the other triggers are rarely used in practice), while Workflows are packaged step sequences you can call again and again, equivalent to “skills” on the Claude side. Notably, if your project folder has a file named GEMINI.md, the model always reads it as its root rulebook, playing exactly the role of CLAUDE.md that you got used to in the previous course.
• Type “@” to load context: attach files, folders and old conversations to the brief instead of pasting raw text and cluttering the memory.
• Switch models mid-conversation: the model picker lets you jump between Gemini 3.1 Pro High, the Low version, Flash and even Claude models within one conversation. A valuable lesson: Claude models running inside Antigravity do worse than in Claude Code itself, so split them up: use Gemini things in Antigravity and Claude things in Claude Code.
• Give the brief by voice: the average person types 50-80 words a minute but can speak 150-200. Describing an interface or reporting a bug out loud is twice as fast as typing, and the model understands well.
• Tab Thought: see the model's “stream of thought”, useful when you suspect it is being lazy or misreading the brief.

There are also a few hidden corners worth knowing so you do not waste time exploring. Tab Changes lists every file the model touched; glancing through it before you nod is the habit of a careful person. Tab Terminal shows the commands it is running in the background (scaffolding, installing libraries): a terminal that sits still for too long is usually waiting for you to answer a question that scrolled out of view above. Tab Browser lets the model open a browser inside Antigravity to look at the page it just built: handy for self-checking, though not as smooth as you opening a real tab. One more small detail that long-time users notice: old conversation history can be reopened any time, with a prompt asking whether to “open in the current window or a new workspace”. Choosing a new workspace carries over the old file context, which is ideal when you want to branch off and try another direction without breaking the version that works.

About MCP servers (the third item in the customization section): in short, they are “workflows others have packaged for you to use”, for example standardized connections to GitHub, Stripe and PostgreSQL. It sounds grand, but the practical advice from both the curriculum and our experience is: newcomers do not need to touch them yet. The trio of Rules, Workflows and “@” context loading already covers nine-tenths of the need; save MCP for when you are running smoothly and need to connect to outside systems.

Part 3: Your first website in 15 minutes, from brief to a real link

The course's opening exercise: build a personal or company showcase website and put it on the real internet. A four-step process:

1. Create a new folder and add a GEMINI.md file. Paste a “framework brief” into this file: ask the model to play a heavyweight front-end engineer, build a cinematic-quality landing page, and most importantly: ban the mass-produced AI templates (the standard hero + three feature columns + call-to-action button, the template that tells you at a glance an AI made the site). The framework brief also lists “architecture styles” for the model to choose from: bento grid, split screen, horizontal scroll, linear storytelling.
2. Type one sentence: “build me a website”. The model will ask back for the brand name, core message, aesthetic style, three content pillars and conversion goal. After you answer, it makes its own plan, runs the scaffolding commands, installs libraries and writes each page itself: you sit and watch the plan tab and the task list it ticks off by itself.
3. Nudge with words: gather a batch of feedback (change the menu bar, enlarge the heading, add an about section, fix numbers overflowing their frame), say it all in one go by voice, with screenshots of another site as a reference. This is exactly the “batch feedback” technique from the app-building course, reused as is.
4. Publish with Netlify: a free hosting service for your first few sites. The most basic way: go to netlify.com, choose “Deploy manually”, and drag and drop the whole project folder into the browser. A few dozen seconds later you have a real link to send to customers. The better way (connect GitHub so it updates every time you change something) comes in a later part.

Two small things worth adding about this exercise. First, with the same framework brief, running it a few times in a few different folders gives a few very different styles: the curriculum encourages doing exactly that and picking the one you like best, because ten more minutes of running is far cheaper than trying to nudge a version you dislike from the ground up. Second, when refining the interface, a screenshot is worth more than a thousand words of description: when you see a nice menu bar on someone's site, screenshot it and paste it with the words “make it like this” and the model catches the feel immediately; keep screenshots compact, because every pixel costs tokens and huge images only drain the session's memory faster.

A static website like this has no login and no data yet, so there is not much to worry about on security. But in the very next part, the course deliberately pauses before letting you build a real app, for the reason that Part 4 states plainly.

Part 4: The 80/20 of security: five holes behind eight in ten vibe coding accidents

A true story mentioned in the curriculum: a high-profile AI project once exposed about 25,000 user API keys, with bills run up by bad actors and data left out in the open. Vibe coders get hit more easily than hand coders, not because AI writes bad code, but because the person giving the brief does not know what to demand. The following five holes cause most accidents, and once you know all five you already stand above 80% of players:

1. Exposed API keys and environment variables. If an API key is pasted straight into the interface code, anyone who opens the site and hits search can see it. The rule: every key lives in the .envfile, and that file must never go to GitHub or sit in code the browser downloads.
2. Forgetting to turn on row-level security (RLS) in Supabase. Supabase (the database for this whole course series) by default has RLS off; with it off, anyone who has the project address can read, edit and delete every user's data. A statistic cited in the curriculum: 83% of Supabase data leaks come from misconfigured RLS, not from clever hackers. Turning it on is a single switch, and the command to remember when you give the brief is: “enable RLS on every table”.
3. Checking only in the browser. Validation rules (is the email valid, is the password long enough, does this person have permission) that live only in the interface can be bypassed by a bad actor with a few lines of edits. Every important check must happen on the server side, where outsiders cannot touch it.
4. Ghost libraries and old libraries. AI sometimes invents library names that do not exist; bad actors know this and pre-publish fake packages under exactly those invented names, so installing one gets you malware. AI also likes to install old versions with known holes. The rule: tell the model to “always install the latest version”, and review the library list before handing the app to others.
5. No gatekeeper (middleware). A page that needs login but can still be reached by typing its address is broken. The standard principle: deny by default, with every route passing through an authentication checkpoint except the public pages that are explicitly declared.

And one mandatory ritual learned from the Claude Code course, repeated here because it is vital: review security in a clean session, preferably with a completely different model. If you built the app with Gemini, open Claude Code to review it, and vice versa. The reviewing model must be told to “check only, do not fix yet”, run through the whole checklist, report pass or fail on each item, and only then be allowed to fix. The reason for using a “stranger”: the model that built the code looks at it with the forgiving eyes of a parent looking at a child, while a stranger model looks with the eyes of an inspector. In the curriculum, this kind of cross-review caught a fatal flaw: a costly API route could be called directly without logging in, meaning a bad actor could burn the app owner's API credit remotely. A 20-minute review in exchange for never receiving a sky-high bill: the best bargain in the course.

Part 5: The eight-step design loop, and the toolkit that goes with it

This is the part most worth pinning to your wall: the order for building a full-stack app. Newcomers often fail by doing the right things in the wrong order (a classic: building login first). The standard eight-step loop, reused for every product afterwards:

1. Find design inspiration: browse Dribbble or Godly (two galleries of fine design used by professionals) and screenshot the samples you like. Do not make the model invent beauty from a vacuum: give it sample images and the quality jumps enormously.
2. (Optional) an animated accent: an AI-generated image or background video for the top of the page, so your app does not look like a market stall.
3. Core features first: the dashboard and the main action pages.
4. Run it entirely locally, with fake data in a JSON file, without touching the database yet.
5. Connect the real database (Supabase) and rerun everything.
6. Build login NEAR THE END: there is a solid technical reason: if you build login early, the gatekeeper only guards the pages that exist at that moment and later pages slip through; if you build it last, the model sees the whole app and casts a full net.
7. Put it on the internet and recheck from start to finish: your machine and the real server always differ, so a few bugs that only exist in the real environment are bound to show up.
8. Landing page last, because it has the least logic, and fold it into the same publishing round.

The toolkit that goes with the loop, also the “familiar toolkit” of the whole community:

• Next.js for building the web framework: the deeper reason is worth remembering: AI models are trained on mountains of projects using popular frameworks, so asking it to write Next.js means it writes in its “mother tongue”, at much higher quality than an unfamiliar framework.
• Supabase for the database and login: picture a giant spreadsheet with a locked gate. Quick tip: type database.new in the browser to land directly on the page for creating a new Supabase project.
• Netlify (or Vercel) to publish, connectable to GitHub so the site updates itself every time you change code.
• Foundations enough to get by, in four sentences: the client (the browser) only handles display; server handles logic and validation; database handles storage, each table like a sheet with a primary key column that cannot repeat; SQL (PostgreSQL is the most common) for structured data, NoSQL for free-form data, and newcomers should just go with SQL.

By now you hold the same skeleton real software shops use. And while we are on the subject of money, because we see this scenario every week: many businesses come to MONA after paying tens of millions up to over a hundred million VND for “custom software” where the vendor was really vibe coding these same steps, but skipping step 4 on security holes and skipping cross-review altogether. After this course, you will at least know how to demand what needs demanding before you hire: ask the vendor “is RLS on, where does server-side validation happen, who does the independent security review” and you will filter out half the market. And if you want us to review a piece of software being pitched to you or one that is half-built, call 1900 636 648: MONA takes a look and tells you straight whether it is worth the money, before you spend another dong.

Part 6: Hands-on 1: a customer dashboard with login and real data, running on the real internet

The course's real first project: a customer portal for a content services company: customers log in, track order progress, place new orders, and adjust settings. This model applies directly to any Vietnamese service company: agencies, print shops, maintenance providers, training centers.

How it went, and the most expensive lessons:

• Plan with one model, build with another. Open in Plan mode in Claude Code (Opus) for the architecture, with a brief like “you are an architect with 15 years of experience; build a plan for a dashboard with these pages, build order following the eight-step loop”. Then copy the whole plan into Gemini 3.1 Pro High in Antigravity along with Dribbble reference images to build it, because Gemini assembles better-looking interfaces. This is the first time you see two models hand off shifts, each playing to its strength.
• Separate the functionality phase from the polish phase. The golden rule: do not mix “fix the broken button” with “change colors and fonts” in the same long conversation, or the model gets confused. Once the functions run well, open a new conversation with clean context just for polish.
• Batch the bugs and say them out loud. A sample round of feedback in the curriculum has a dozen bugs at once: menu text too faint, a chart missing, clicking an order shows “not found”, the “mark as read” button is dead, with the verbatim Next.js error message pasted in. The model handles the whole batch in one pass. Exactly the “nudging the app” craft from the mobile app course, unchanged.
• Check the business logic, not just the interface. The model took the liberty of adding a “Start work” button for customers to click, when on this dashboard customers may only VIEW. The machine does not understand your business, so you have to be the one who catches errors like this: no one can catch them for you.
• Before memory runs out, make the model write a handoff. In long conversations, context memory runs out. Before each big stretch, order the model to record all progress and instructions in the GEMINI.md file so the next session (or another model) can read it and pick up the work right away. You will have recognized it: this is the CLAUDE.md “handoff notebook” from the previous course, Google's edition.
• Real bugs only show up on the real internet. Signing up on the live build, the confirmation email pointed to… localhost, because the Site URL setting in Supabase still held the home machine's address. One configuration field fixes it, but the lesson is big: until you have checked the full loop on the real environment, it is not done.

The Supabase connection deserves a bit more detail because you will repeat it in every later project. The standard sequence: type database.new to create a new project (the free tier covers two projects), set a strong machine-generated database password, then gather four things into the .env file: the project address, the project ID, the public key and the secret key. The model will generate the SQL script that creates the tables: you just paste it into Supabase's SQL Editor and hit run, with no need to understand every line, only to know it is “drawing the tables” for the app. A speed-up tip while testing: in the Authentication section, temporarily turn off “confirm email” so signing up does not wait for a confirmation message, but remember to turn it back on before real people use it. And check the gatekeeper by hand: type each page address directly (/dashboard, /orders, /settings) while logged out, and all of them must bounce to the login page; any that slips through is a hole in the gatekeeper for that page.

The second polish round on this dashboard has a few tricks worth borrowing. Pick a Dribbble sample with a dark sidebar and light content, then brief the model to “mimic the font, colors, border style and card style of this image”: the model catches the feel surprisingly well. Change every heading from Title Case to sentence case: a purely wording change that makes the interface look noticeably more mature. Swap drop shadows for thin borders to match the sample. And boldly delete buttons that have no page behind them: models love to pre-draw menus like “calendar, reports, portfolio” to look impressive, but a button that goes nowhere is the first crack in a user's trust. The curriculum's philosophy that we love: simplicity will become the moat: soon everyone can vibe code, every app will have too many features, and a clean, easy-to-understand app will become a rarity.

Another worthwhile decorating trick from the curriculum: an AI-generated animated hero. A four-step process: find a nice 3D object on Dribbble as a reference; go to AI Studio and ask the image model to generate a similar object on a pure white background, in brand colors, at 2K resolution; feed that image into Veo (Google's image-to-video model) with the brief “slow 6-second rotation, last frame matching the first for a smooth loop”; download the video and drop it in the project's public folder as the top-of-page background. An honest note: the generated video background is not always pure white as ordered, and sometimes needs extra processing or swapping for a ready-made community asset from Spline: but the total effort of one coffee session for a one-of-a-kind animated hero is dirt cheap compared with outsourcing.

Part 7: Hands-on 2: a lead-finding SaaS, and the “API wrapper” trade

The second project hits the wallet directly: an app that scans lists of potential customers (leads) by industry, job title, region and company size; adds emails; then has AI write a personalized opening line for each person. This is the API wrappermodel: your app is really a friendly interface wrapped around a few existing services: Apify handles the data scraping (this store has thousands of ready-made “actors” that scrape all kinds of things), AnyMailFinder handles email lookup, and the Anthropic or OpenAI API writes the greeting. “Just a wrapper” sounds trivial, but look at the SaaS market today: plenty of products that make real money are a good experience layer wrapped around someone else's API. Software itself is no longer the moat; experience and distribution are the moat.

The most expensive technical lessons of this project:

• Have the model read the real API documentation. Apify has a “copy for LLM” button that copies the whole documentation page for the AI to read; paste it along with the actor's input schema. A model that reads the real docs wires up the API correctly; make it guess and it makes things up.
• Make it test with curl before assembling into the app: call the bare API until it works, then wrap it in the interface. Separate “is the API alive” from “is the app connected correctly”, and whichever segment has the bug shows itself immediately.
• Issue a dedicated API key for the project and give it a short expiry. The Apify key in the curriculum was set to expire after one day: if you forget to delete it, it never becomes a permanent backdoor. A small habit with big class.
• Running out of model quota mid-way is normal. Gemini works for an hour and hits its usage cap; the curriculum switches to Opus in Claude Code to carry on. The right way to switch shifts: have the working model “write one brief that sums up everything discussed so far” and paste it to the new model. No bare-handed model hopping, because without a handoff note the new model wrecks the old flow.
• Batch cho nhanh: the initial personalized greeting step ran sequentially, one lead at a time, painfully slow; one command, “batch them and make it fast”, and the model switched to running in parallel by itself. You do not need to know code, just know to demand it.

This project also teaches a side skill that business people love: making a logo with AI in 5 minutes. Go to AI Studio (aistudio.google.com), call Google's image model, with a brief like: “minimal square logo, understood at a glance, classy, for a lead-scanning software”, ratio 1:1, resolution 2K; if you are not satisfied, keep pushing with “flat icon style, imitate the sample below” plus a reference image, then “remove the text, keep the shape”. Three rounds give you a logo usable for a prototype: later, once the product is truly alive, hire a designer for a proper brand identity.

Part 8: Hands-on 3: an AI app that takes real payments with Stripe, and the lesson that “payments are a mountain of work of their own”

The third project covers the last piece of a true SaaS: getting paid. The demo app: an AI YouTube thumbnail generator (give it a sample image plus your own face and the AI composes three options), sold by credit packs: top up for points, each image generation deducts points, and when points run out the user is invited to top up again.

Payments knowledge in a nutshell, so you can talk with any engineering team:

• Never handle card numbers yourself. The industry standard is Stripe-hosted checkout: the app sends the customer to a payment page run by Stripe, and Stripe handles card security, fraud prevention and invoices. Fees run around 2.9% plus 30 cents per transaction. In Vietnam you will meet local gateways like VNPay, PayOS and Momo: the same model, just a different gateway name.
• Three mandatory pieces of code in every payment flow: create a checkout session and send the customer off; webhook receive the “payment succeeded” signal back from the gateway; and a permission-check function before each time a customer uses a costly feature. Three common pricing models: one-time purchase, monthly subscription, and credit packs like this app.
• Sandbox first, real money later. Every test runs in Stripe's test mode. If the live secret key leaks, the bill has no ceiling.

And the real chain of bugs from this project, listed so you do not panic when you hit them yourself: after paying, being bounced in circles back to the payment page (a status recording bug); clicking the Pro plan but checkout showing the cheapest plan (a plan parameter passing bug); the app lagging badly after payments were added (a bug where every page open reloaded all the data instead of using the cache); and the live build throwing an error at second 22 of every image generation, which ran fine on the home machine: it turned out Netlify's free server cuts the function off after about 15-20 seconds, while the home machine has no limit. To untangle chains of issues like this, always give the model maximum context (screenshots, verbatim error messages, even whether the money has reached the Stripe wallet), say so plainly when you suspect an error message is misleading, and ask for only one big changeper turn: hard-won experience with every AI model today. The whole project's takeaway deserves to be carved on your desk: the time in building a SaaS is not in the building, it is in briefing and verifying: the AI handles the building.

Beyond money matters, this project leaves a stack of product-polishing tips worth copying:

• Proper notifications instead of raw dialog boxes: replace every browser alert box with a soft in-interface notification, with buttons like “open in new tab, download image, regenerate”: a small detail that lifts the product feel a whole level.
• Send extra requests while the model is running: Antigravity lets you queue messages: a model in the middle of old work still accepts new work and weaves it into the flow. You do not have to wait turn by turn like queuing for pho.
• Running out of points needs an exit: a user who runs out of credit and only gets an error message is a failure; the right rule is to take them to the top-up page automatically, with a clear reason. Every dead end in the app must have a signpost back to where they pay: it sounds practical, but it is the difference between a test app and a business app.
• Sync the design language: models love to round corners, add shadows and pick colors by their old habits. To give your product its own personality, you must name it explicitly: square or round, shadows or flat, a specific hex color palette, and say it once in GEMINI.md so every later session obeys.

Part 9: The art of commanding multiple agents: running in parallel, keeping direction, and the cost in money

This part is for those who already run one agent well and are getting greedy: can you run several at once? Yes, Antigravity was born for exactly that, but there are rules.

• Agent Manager and Inbox: the top right corner of Antigravity holds a hub for managing all workspaces and conversations; Inbox gathers notifications from all agents in one place, feeling just like a security guard watching a wall of cameras. The curriculum demos opening four parallel conversations building a landing page in four styles, giving a dozen versions to choose from in fifteen minutes. Fun, but the honest advice: two to three agents at once is the effectiveness ceiling for ordinary people: the human brain cannot split further, and loose supervision lets agents drift off course in bulk.
• The trajectory principle: a ship crossing the ocean that is one degree off in the first kilometer arrives hundreds of kilometers off on the other shore. Agents are the same: the first few minutes of every big build are when you must sit closest, correcting course the moment you see it start building off target, rather than letting it grind for an hour and then discovering it must all be torn down.
• The handoff file is the lifeline: the big final project of the course runs Gemini (interface) and Claude (backend) in parallel, keeping the two from stepping on each other with a file updates.md: every change is recorded there, and whichever model starts a shift reads it first. With this file you can even play a neat trick: have the two models critique each other on which features to keep and which to drop: a cheap “technical committee” that noticeably improves decision quality.
• Straight talk about money: the sprint build session of the final project in the curriculum burned an estimated $70 in model costs for a few hours of full-throttle parallel running: that is the price of “trading money for speed” under a deadline, not the standard pace. An ordinary learner goes one agent at a time, uses a fixed monthly plan, and spends a small fraction of that. The lesson for business owners: AI costs stretch with how you use it, so treat it like the electricity bill of a workshop: turn on the right machine when you need it, do not run the whole workshop with the lights on for fun.

Part 10: The economics of vibe coding: pricing, selling, and the final boundary

The part that pays the most for business people, and the part most coding courses skip: once it is built, how to sell it.

Price by value, not by cost. Do not add up costs and double them, and certainly do not look at a competitor's price and undercut by 10%: that is a race to the bottom. The curriculum's formula, which we find matches how MONA has quoted software for over ten years: calculate the total value the product creates for the customer each month, then price at 10-20% of that figure. Value has two streams: direct savings (replacing a pricier tool, cutting labor hours) and extra money earned from freed-up time. The curriculum's example: the thumbnail app saves a channel $1,000 a month in design costs plus 40 hours of labor worth another $1,000: total value $2,000, priced at $200 a month: the customer still profits tenfold and you still live well. Split into three price tiers: a top tier with all features, a middle tier at half the price with fewer features, and an entry tier that is cheapest: let customers choose where they stand.

Tip for winning new customers: let them taste it free exactly once. A tactic taught for the course's final product, and one we confirm as a real psychological lever: let a stranger use the core feature once, with no sign-up, hit the “wow” moment, and only then invite them to pay. People who have received something valuable tend to want to “return the favor”: the classic reciprocity principle of selling, built straight into the product. The free tier then limits credits low enough that people who genuinely need it must upgrade, and not so wide that they stay forever.

Three sales channels, in order. One: actively knock on doors (cold email, direct messages to people with the need): the fastest way to money but it takes a thick skin, and it is the channel to start with. Two: build content that draws customers in: slow, sometimes a whole year with nothing to show, then it takes off: shift gradually to this channel once channel one is feeding you. Three: affiliates earning commission (share 20-30% with people who already have a customer base): runs in parallel through every stage. The curriculum's suggested switching point: steady revenue of around ten thousand dollars a month from the proactive channel, and only then pour effort into brand building. And one ratio worth pinning to the wall: building the product is 5% of the time, selling is 95%: the first version is never the one that makes money, the twentieth is: ship early, invite twenty free users, hear the criticism, fix, repeat.

Applying this whole framework to Vietnam, we add three notes from over ten years of selling software in reality. One: Vietnamese business customers rarely buy subscriptions and prefer to buy by visible value: credit packs and per-project packages are usually easier to close than monthly subscriptions in the early stage, so the credit model from Part 8 suits our market best. Two: the “proactive door knocking” channel in Vietnam works best through Zalo and industry groups, not Western-style cold email: same principle, different weapon. Three: do not price low just to sell easily: low prices pull in exactly the customers who pay little and demand a lot, and they shut the door on later upgrades: pricing at 10-20% of value and then proving that value is harder at first but lasts far longer.

Closing the three-course vibe coding series, we draw the line one last time, based on MONA's over 10 years and 14,000+ projects of experience: vibe coding with Gemini and Antigravity takes you from idea to a working, money-making version faster than ever: internal tools, market test versions, compact SaaS: play freely, and this course has given you the full toolkit. But when the product begins to carry real revenue from many customers, hold sensitive data, and run operations where an hour of downtime costs real money, the game changes its rules: you need load-bearing architecture, automated testing, permissions, logs, on-call people and someone legally accountable. That is when your vibe-coded version needs to be industrialize: and that is exactly what MONA does for a living. If you have a self-built app that runs well and want to turn it into a real system, or a validated idea you want to build all the way through: call 1900 636 648 or send it to info@themona.global, and our team will look at what you have today and tell you plainly what can stay, what must be rebuilt, and what it costs: transparent quotes, and we build at the price you sign.

Part 11: The troubleshooting handbook: the seven most common cases and their prescriptions

We boiled the lessons of three projects down to seven classic cases. Print it and stick it next to your screen:

1. The model answers sloppily and lazily. Open the Thought tab to see what it is thinking; the cause is usually a vague brief or a conversation that has run too long. The fix: save a handover note into GEMINI.md and start a clean new session.
2. A confusing red error shows up. Don't paraphrase it in your own words: copy it verbatim the error message, add a screenshot, and paste it to the model. Paraphrasing wipes out the clues.
3. The same bug keeps coming back and the model goes in circles. A sign it lacks context or the error message is misleading it. The fix: say outright "this error may not reflect the real cause", feed it every fact you have, or switch to a different model that looks at it with fresh eyes.
4. Works on my machine, breaks online. Suspect three things right away: address settings (such as a Site URL still pointing to localhost), environment variables not declared on the server, and the function runtime limit on the free tier (15-20 seconds is the usual ceiling).
5. Every page looks different. The model changes its style on its own from session to session. The fix: lock the design language (colors, corners, fonts, shadows) as rules in GEMINI.md from the start, and every session follows them.
6. The app gets slower the longer it is used. The usual culprit: every page open reloads all the data from scratch. The fix: give the brief "load data once, then use the cache, and reload only when something really changes".
7. The model hits its quota mid-job. It happens all the time. The fix: a handover note (have the working model summarize all progress), then switch to another model; the Gemini quota resets on its own after a few hours, so come back and continue.

Quick answers

What is vibe coding? It is building software with words: you describe, the AI writes the code, and you inspect the result and give feedback until it is right. The core skills are writing a clear brief, verifying carefully, and knowing a few safety principles. This course teaches all three.

Is Antigravity free? Yes. Download it at antigravity.google, sign in with a Google account, and use Gemini 3.1 Pro with a free quota. If you use it heavily, the quota resets after a few hours, or you can upgrade to a paid Google AI plan.

Gemini or Claude Code: which should you learn? Both, each with its own strength: Gemini is strong at interface design, Claude is strong at architecture and security. Our course series covers both: three Claude Code courses and this course. How to combine the two is in parts 6 and 9.

Can I learn this without knowing any code? Yes. The course is written for the person writing the brief, not the person typing code. What matters most is being willing to verify and following the 80/20 security part in part 4. The AI writes the code.

Can a vibe-coded app really be sold? Yes, and the course has a full section on pricing and three sales channels. But stay realistic: building is only 5% of the game, the first version is not the version that makes money, and a product carrying serious revenue needs its technical side industrialized (part 10 draws the line clearly).

Should I worry about data and security? Yes, and it is manageable: 80% of accidents come from five familiar holes (leaked API keys, forgetting to turn on RLS, checking only in the browser, ghost libraries, missing guard checkpoints). Work through the part 4 checklist plus one cross-review round with another model, and you are ahead of most people.

The next course in the series: agentic workflows: building automated AI systems for real work, where the orchestration skills from this course are upgraded into a production line. See you there.

From idea to a paid app: the last stretch runs on MONA's tools

Say it is ten at night and Claude Code has just reported the last feature done on your computer. The site runs well, the interface looks great, everything is perfect, but if it only sits on your local machine it will not earn a single dong. That is the jam. Many people get stuck here because putting software online for real has always demanded skills in running servers, configuring firewalls, and setting up domains complicated systems. We have seen countless projects shelved because they could not find a sensible place to run, or because they used a foreign platform and had to shut the project down when the rent for cloud virtual servers billed in USD became too expensive once real customers showed up.

Instead of wrestling with dozens of different dashboards, you can drop your source code straight into the ecosystem we have already built. With MONA Cloud, the AI only needs to type a single deploy command through the command line interface or through the MCP manager, and the codebase goes straight onto a server running in Vietnam.

We have a free sandbox that simulates creating a machine, so the AI can experiment in every corner before you spend any money. When you decide to run for real, pricing starts at only 550 VND/hour for a 1-core machine with 1 GB of RAM, which works out to under 400,000 VND a month. According to our internal system's record of machine creation on September 5, 2026, creating the environment took less than fifteen seconds, and latency measured from the VNPT network in Ho Chi Minh City to the server was only around 5 to 15ms, far below the 30 to 50ms you get when renting a machine in Singapore.

The most valuable part of this whole infrastructure is the single account ecosystem, MONA Pass. You no longer manage server accounts in one place, domain details in another, and email somewhere else. We merge everything and you use one prepaid wallet in VND that is easy to follow. You top up the wallet through a VietQR code from as little as 10,000 VND, and when the balance runs out, the API returns a 402 code instead of quietly charging extra and letting the bill balloon out of control. Our advice: if you are only running a personal project for a few days, use the free sandbox first and move to a paid plan afterward. Never waste money on a large machine when the project has no customers yet.

Closing the product lifecycle: payments, domain and email in sync

Once the app gets the green light, the next essential step is wiring up the payment flow to turn all that code into revenue. Money is the lifeblood. One of our students spent a week and a half just to match a bank transfer code to the database, because the third-party notification system was always a few minutes late. And that is before the risk of relying on foreign platforms like the Auth0 authentication system. As of September 19, 2026, they offer a Free plan up to 25,000 users, but once you pass that mark you are pushed onto a 35 USD/month plan, and operating costs shoot straight up as your customer base grows. With MONA, every service sits under a single MONA Pass account, running smoothly from servers and domain management all the way to the mailbox service.

For collecting money specifically, you have MONA Pay, a bank API and automatic payment confirmation service, where money goes straight to your own account. The first 500 transactions every month are completely free with every feature included. Past that, the fee is just 99,000 VND for 2,000 transactions. There is no percentage cut of the amount your customer transfers. Because the dynamic QR code is pre-filled with the amount and the order reference, it is very hard for customers to transfer the wrong amount or enter the wrong content. Back on September 17, 2026, while building the AI wallet top-up flow on MONA Cloud through the Claude Code integration, we caught a bug in the payment notification code that let money arrive without crediting the wallet. We fixed it that same day, and ever since, our hard rule is that every payment notification gateway must be tested with a real money transaction before it opens to customers.

Because we have been in this industry since 2016, with hands-on experience from 14,000+ projects and an 85% customer return rate, we know that business software must be solid on every legal angle. You always get a proper VAT invoice, a Vietnamese-language hotline ready to resolve problems, servers and data safely hosted in Vietnam, and most importantly a real team from The MONA Group standing behind it. Never leave the core payment flows of your sales system to third-party drag-and-drop automation. The moment an API changes, the flow tears apart with no one watching, and the cost is your reputation with buyers.