How to Vibe Code a Game Like Lagos Life: Free APIs, Prompts, and How to Survive the Traffic

On October 1, 2026, Nigeria's Independence Day, a browser game called Lagos Life went live at 7 a.m. Its creator had reportedly been building it through the night with AI help. Within days it was everywhere on Nigerian X and TikTok: you create a character, get a job, buy food, pay rent in virtual naira and run into other players on the streets of Lagos. Within a week and a half, the company behind it had raised a $500,000 angel round.

The lesson for developers isn't "there's a secret API". It's that one person with an AI coding assistant, a sharp local idea and a handful of free APIs can ship something millions of people play. This guide shows how to build your own version: what to build in which order, what to tell your AI tool at each step, which free APIs make the world feel real, and the traps that cost Lagos Life real money and trust in its first weeks.

Note: we have no connection to Lagos Life or its developer, Vatar, and they haven't published their tech stack. Facts about the game come from public reporting, linked below. The build plan and API advice are ours, and we tested every API mentioned in October 2026.

#What Lagos Life actually is (and why it spread)

Here's what's been reported, mostly by Techpoint Africa, TechCity, Innovation Village, The Condia and TheCable:

How it makes money: players can buy "Game Naira" with real money through Flutterwave. It can't be cashed out. Brands buy in-game billboards and lagoon plots; reported prices went from ₦5,000 to ₦250,000 a week as the game grew. The founder said it made about $46,900 in its first four days, against hosting costs of roughly $6,000 a month.

Why it spread:

1. It's local. Danfo buses, Lekki rent, Yaba, the lagoon. Players recognise their own city and want to screenshot it.
2. It's a link. No app store, no download, no "Android only". A post on X opens straight into character creation.
3. It's social. Other real people are on the same map. That gives you something to post about.
4. The loop is simple. Work, eat, sleep, pay rent, show off. Everyone already understands it.

None of these needs a big team, which is exactly why it's worth studying.

#Can you really vibe code a game like this?

Yes, with one big condition. AI tools are excellent at the first 80%: the map, the characters, the menus, the API calls. They're dangerously confident about the last 20%: money, multiplayer cheating, security and scale. Lagos Life's biggest public problems were in that last 20%. Hacked accounts and a loophole produced "trillion-naira" balances that the team had to wipe, and the servers needed an overload screen ("Lagos hit a small go-slow") within days.

So the approach below is: let the AI write the code, but you design the rules and check the risky parts yourself. You don't need to be a senior engineer for that, just to know what to ask and what to test.

#The toolkit

• An AI coding tool. Agentic tools that edit a real project (Claude Code, Cursor, Windsurf) are the best fit, because a game grows past what fits in one chat. Browser builders (Bolt, Lovable, Replit) get you a first playable version fastest but get harder to steer as the game grows.
• A game framework the AI knows well. Lagos Life is 3D in the browser, and its creator announced that phones struggling with 3D now switch to a lighter view instead of crashing. For 3D, Three.js (or Babylon.js) with low-poly models; for your first version, Phaser in 2D is far easier and still works. AI tools write both fluently because there's so much example code online.
• A backend with real-time support: Supabase (Postgres database, auth and realtime channels, with a free tier) is the least-setup option. A small Node server with Socket.IO gives you more control.
• Hosting: Vercel or Netlify for the front end. For an always-on game server, a small VPS (DigitalOcean, which Lagos Life's privacy policy names, or Hetzner).
• Free APIs for everything that makes the world feel real. That's the big section below.

Tip: before you start, write a one-page game design doc (the jobs, prices, needs, what happens when you're broke) and give it to the AI as a file in the project. AI tools are much better at following a written spec than at reading your mind across fifty prompts.

#The build plan: 7 phases, with prompts

Build in this order. Each phase ends with something you can play, which keeps both you and the AI on track. The prompts are starting points; paste them in, then iterate.

#Phase 1: A city you can walk around

Start with the map and a character, nothing else.

Create a Vite + Phaser 3 project for a top-down 2D life-sim set in Lagos, Nigeria.
(For 3D: Vite + Three.js, low-poly glTF models, and an automatic 2D/low-detail
fallback when the frame rate drops below 25 fps.)
One scene: a tile-based map with roads and 6 named areas (Yaba, Surulere, Ikeja,
Lekki, Victoria Island, Lagos Island) as labelled zones. A player character moves
with arrow keys/WASD on desktop and a virtual joystick on mobile. Camera follows
the player. Keep the total bundle small: this must load fast on a cheap Android
phone on a 3G connection.

Check: play it on your actual phone, on mobile data. Most of your players will be on mid-range Android phones with expensive data. If it's slow now, it'll be unplayable at scale.

#Phase 2: The life loop

Now the "Sims" part: needs, jobs, money and rent.

Add a life simulation loop, following docs/game-design.md:
- Game time runs at 1 real minute = 10 game minutes. Show the clock and day.
- Needs: hunger and energy (0-100), decaying over time. Sleeping restores energy.
- Jobs at specific buildings: start a shift, get paid at the end of it.
- Rent is due every 7 game days. If you can't pay, you get evicted to a cheaper area.
- All money is stored as whole kobo (integers), never decimals.
Put all game rules in one module (rules.ts) as pure functions so they can be tested.

Check: ask the AI to "write tests for rules.ts covering a full work day, rent day and going broke". Pure functions plus tests are the best defence against the AI quietly changing a rule in a later prompt.

#Phase 3: The real-world layer (free APIs)

This is what makes your game feel like the city, not a city: the real weather, real neighbourhoods, real holidays. See the API section below for which ones to use and their gotchas.

Add a "world" service on the server that, every 15 minutes, fetches current Lagos
weather from Open-Meteo (no API key) and today's Nigerian public holidays from
Nager.Date, and broadcasts them to all players. Effects: rain makes commutes
30 game minutes longer and costs extra energy; public holidays close workplaces.
Sync the day/night cycle to real Lagos sunrise and sunset from the
Sunrise-Sunset API. Cache everything; players must never call these APIs directly.

Check: that last sentence matters. AI tools love to put fetch() calls in the client "for simplicity". With 100,000 players, that's 100,000 people hitting a free API, and you'll be blocked within minutes.

#Phase 4: Multiplayer

Seeing other people on the map is what turns a toy into Lagos Life.

Add multiplayer with Socket.IO (or Supabase Realtime). The server is authoritative:
clients send movement *intents* (direction), the server validates speed and walls,
updates positions and broadcasts them. Only send each player the positions of
players within their area of interest (a spatial grid, 3x3 cells around them),
not everyone on the map. Throttle position updates to 10 per second.

Check: "server is authoritative" and "area of interest" are the two phrases that matter. Without the first, anyone can open the browser console and teleport. Without the second, the server tells every player about every other player, so traffic grows with the square of your player count. In our simulation of 20,000 players on a large map, a simple grid cut each update from 19,999 recipients to about 19.

#Phase 5: The economy (do not skip this)

This is where AI-generated code most often goes wrong, and where Lagos Life reportedly got hurt. The usual bugs:

• Read-then-write races. Two "send money" requests read the same balance at the same time and both succeed.
• Double-counted retries. A flaky connection resends a transfer, and it goes through twice.
• Trusting the client. Negative amounts, decimals, or "my balance is now 1,000,000" sent from the browser.

Rebuild all money handling in the database, not in game code:
- A wallets table with a CHECK (balance >= 0) constraint, amounts in integer kobo.
- Transfers between players run in one transaction with a conditional update
  ("UPDATE ... SET balance = balance - X WHERE id = ? AND balance >= X") and an
  idempotency key, so replays are ignored.
- Every naira that enters the game (salary, purchase) or leaves it (rent, shops)
  is recorded in a supply_changes table.
- Add a reconcile job that checks SUM(wallet balances) == SUM(supply_changes)
  every 5 minutes and alerts me if it drifts.
Then write tests that try: double-sending, negative amounts, overdrafts and
1,000 concurrent transfers. Show me the results.

Check: the reconcile job is your smoke alarm. Remember that you can break the economy too: Lagos Life's ₦100,000-per-player outage apology was, in effect, minting money for millions of accounts at once. Record grants like that as supply changes, so you can see their effect on prices. We built this pattern and then deliberately "hacked" a balance directly in the database; the reconcile check flagged the exact drift immediately. If Lagos Life's loophole had been caught in hours rather than after it spread, the clawback would have been much smaller.

#Phase 6: Chat and safety

Players will talk, flirt, argue, and someone will try to scam someone. Plan for it.

Add proximity chat (only players within the same area of interest see messages).
Rate-limit to 1 message per 2 seconds per player. Filter messages with a local
word list (include Nigerian Pidgin and Yoruba insults I'll provide), and run the
PurgoMalum API asynchronously as a second pass for reported messages only.
Add report and block buttons. Block any message that contains a phone number,
bank account number or payment link, with a warning about scams.

Check: the scam filter isn't optional. Within days of Lagos Life going viral, accounts were being hacked, people were offering to "buy and sell game cash for real naira", and an unofficial crypto token appeared using its name. Your game will attract the same.

#Phase 7: Payments and launch

If you sell virtual currency, the money is real even when the naira on screen isn't.

Add a "Buy Game Naira" flow with Flutterwave Standard checkout. Credit coins ONLY
after the server calls Flutterwave's verify endpoint
(GET /v3/transactions/{id}/verify) and checks: data.status is "successful",
tx_ref matches our order, currency is NGN and amount matches the pack. Use the
Flutterwave transaction id as an idempotency key so the webhook and the redirect
can't both credit. Write clear terms: Game Naira can't be withdrawn or exchanged.

Check: Flutterwave's response has two "statuses": the top-level status is "success" when the transaction is found, while data.status must be "successful" for the payment to have gone through. Mixing them up is a classic way to hand out free coins.

#The free APIs that make a game world feel real

Every API here is free, and the ones marked "no key" need no sign-up. We tested all of them in October 2026; click through to the directory for live status and uptime.

Three rules apply to all of them:

1. The server calls the APIs, never the players. Free APIs are free because they're used politely.
2. Cache by how often the data changes. Weather every 15 minutes, holidays once a year, places once ever.
3. Have a fallback. If the weather API fails, the game should default to "sunny", not crash.

For more ideas, browse free game and comics APIs and every API that needs no key.

#What AI won't warn you about

After testing this build, these are the things we'd check in any AI-generated game before launch:

• Secrets in the front end. Ask the AI: "list every API key or secret and where it's used". Payment keys must only exist on the server.
• Database rules. If you use Supabase, ask it to "audit row-level security on every table". A missing policy means any player can edit any wallet from the browser console.
• Sign-up abuse. Questions were raised about how many Lagos Life accounts were real people. Add email verification and a CAPTCHA (Cloudflare Turnstile is free) before launch, not after bots arrive.
• Age and data rules. Lagos Life became 18+ and publishes a privacy policy naming its providers. Nigeria's data protection law applies to you too. Write the policy before you collect a single email.
• Your own name. Within days there were fake Lagos Life tokens and cash-sellers. Register your handles early, and pin an "official links only" post.

#How Lagos Life handled the traffic, and how you would

This is the part most "I built a game in a weekend" stories skip, and it's where a viral game lives or dies. Lagos Life went from zero to a reported 109,000+ people online at once in days. Here's what that means technically, what's known about how Lagos Life coped, and the architecture that survives it.

#Total players don't matter. Concurrent players do.

"1.2 million players" sounds terrifying, but on the morning of October 5 the live counter showed about 55,000 online, and later that day around 72,000. Roughly 5–6% of all accounts were playing at the same moment. That's normal, and it's the number to design for: servers, bandwidth and database connections scale with concurrent players, not sign-ups.

A sign-up costs you one database row. A player who's online costs you an open WebSocket connection, position updates ten times a second, chat messages, and a slice of CPU on a game server, for every minute they play.

#What we know about how Lagos Life coped

The developer hasn't published a post-mortem, but the public record shows the classic pattern of a game scaling live, in production:

• An early outage (October 2). The game went down briefly a day after launch. The team apologised by giving every player ₦100,000 of virtual cash: free to issue, and very good for goodwill.
• An overload screen. Players reported a "Lagos hit a small go-slow" screen when the servers were busy. Showing a friendly, on-brand "we're full" message instead of an error is exactly the right move (see admission control below).
• Adaptive graphics. Phones that couldn't handle the 3D city were switched to a lighter view instead of crashing. That's a scaling fix too: the cheapest server request is the one a crashed client never retries.
• Chat pressure. Developers on X speculated that in-game chat was the biggest bandwidth problem, because a social game's chat can turn into "everyone talks to everyone". That's speculation, but it's the right instinct, as the maths below shows.
• The bill. The founder cited hosting of about $6,000 a month, and the privacy policy names DigitalOcean as the host.

#The maths of 100,000 people on one map

Here's a back-of-envelope estimate for a shared map, assuming each position update is 12 bytes (a player ID plus x and y) and the server sends ten updates a second:

The first row is why naive multiplayer code (exactly what an AI writes if you don't ask for more) falls over at a few thousand players. The second row is very manageable.

It also matters for your players' data bundles: at 3 KB per second, an hour of play is about 11 MB of mobile data, plus the one-off download of the game's assets. In Nigeria, where players pay for every megabyte, that's a feature worth bragging about.

#The architecture that survives going viral

Each of these is a prompt you can give your AI tool, one at a time:

1. Put every static file on a CDN. HTML, JavaScript, 3D models, textures, sounds and avatars should be served by Cloudflare, Vercel or Netlify, never by your game server. Compress 3D models (glTF with Draco or Meshopt compression, and KTX2 textures) so the first load stays small.
2. Split "web" from "game". Sign-up, profiles, the shop and the stats page are ordinary stateless HTTP endpoints that can scale out behind a load balancer. The live world (WebSocket connections, positions, chat) runs on separate game servers, which hold state in memory.
3. Shard the city into zones. One game server process per area (Island, Mainland, Lekki…), with players handed off when they cross a boundary. If one zone gets busy, it slows down alone, and you can add instances of the busiest zones (Lekki on a Friday night) without touching the rest.
4. Area of interest plus tick batching. As in Phase 4: only send nearby players, and send one combined binary packet per tick rather than one JSON message per player. Send distant or idle players less often.
5. Treat chat as its own service. Proximity chat only reaches players in the same area of interest; global or city-wide channels are rate-limited and paginated; messages are kept for hours, not forever. Use Redis pub/sub so chat scales independently of the game servers.
6. Keep positions out of the database. Writing 100,000 positions ten times a second would melt any database. Positions live in game-server memory and are saved as snapshots every minute or two. Only the important things (money, purchases, property) go straight to Postgres, in transactions, through a connection pooler like PgBouncer.
7. Cache the stats page. A "live players" counter that every visitor reloads is one of the most popular pages. Compute it once every 30 seconds and serve the cached number.
8. Admission control: your "go-slow" screen. Decide the maximum players per zone and per server before launch. When you're full, put new arrivals in a queue with their position ("you're number 340"), instead of letting everyone in and making the game unplayable for all.
9. Adaptive quality on the client. Detect a low frame rate and drop to fewer players drawn, lower-detail models, or a 2D view. Lagos Life's 3D fallback is this exact idea.
10. Autoscale on the right signal. Scale game servers on open connections and tick time (how long each 100 ms tick takes to compute), not on CPU alone. If a tick takes longer than the tick interval, players feel lag before any CPU graph looks scary.

A combined prompt to start with:

Refactor the multiplayer server for scale: (1) split the map into zones, one
process per zone, with handoff between zones; (2) use a spatial grid for area of
interest and send one binary snapshot per 100 ms tick with only nearby players;
(3) move chat to a separate service using Redis pub/sub with per-player rate
limits; (4) keep positions in memory and snapshot to Postgres every 60 seconds;
(5) add an admission queue with a friendly "Lagos is full" screen when a zone
reaches MAX_PLAYERS_PER_ZONE. Explain each change before making it.

#What it costs

Bandwidth is usually the surprise line on the bill, and the provider you pick changes it by roughly 9×. Using the ~300 MB per second estimate above for 100,000 concurrent players (about 1.1 TB per hour at peak):

Add servers, a managed database, Redis and a CDN, and a game at Lagos Life's reported peak landing somewhere in the low thousands of dollars a month on a budget host is plausible. On a big cloud with default settings, it could easily be several times that. Choose a host with cheap or bundled egress before you go viral.

#Load test before the internet does it for you

Ask your AI tool to write a load test with k6 or Artillery that opens 1,000, then 5,000, then 20,000 fake WebSocket players, has them walk around and chat, and records tick time, memory and messages per second. Run it against a staging server the same size as production. The numbers tell you how many players one server handles, so when the next spike comes you know exactly how many to add, and which screen people see when you run out.

#Your launch checklist

• Loads in under 5 seconds on a mid-range Android phone over mobile data
• Opens straight into character creation from a shared link
• A shareable "my character" card (avatar + job + area) for X and TikTok
• Server-authoritative movement and money, with tests
• Area-of-interest updates, zones and an admission queue, load-tested
• Economy reconcile job running, with alerts
• Chat filter, scam-pattern blocking, report and block
• Payments credited only after server-side verification
• Privacy policy, terms (no cash-out), age gate
• Official social handles registered and pinned

#The takeaway

Lagos Life worked because it was local, instant and social, and it was built fast because AI tools now handle most of the code. You can do the same for Accra, Nairobi, Jo'burg or your own city. Let the AI build the world; you own the rules, the money and the safety. That split is the difference between a viral hit and a viral clawback.

New to APIs? Start with what a public API is, then browse the no-key API list for your city's real-world layer.