As of October 2026.
The short version
richbay.org is a reference site for comparing countries, cities, visas, universities and living costs, built on official government sources. It went from an empty repository on 3 May 2026 to this in about five and a half months:
- Country hubs
- 51 published (a directory of 100)
- City pages
- 405, including 41 in-depth living guides
- Visa routes
- 64 curated
- Universities
- 160 profiles, 3,385 listed
- Official sources monitored
- 109, across 55 countries and regions
- Languages
- English, Chinese, Japanese
- URLs in the sitemap
- ~2,800
- Commits
- ~2,400, with ~290 tagged releases
Nearly all of the code and content was written by AI coding agents, in sessions directed by a small team. People call this vibe coding. What made it work was not vibes. It was written rules, automated checks that refuse to ship known mistakes, and a habit of checking the live page rather than trusting the change.
Who does what
The team decides what to build and what not to build, sets the rules, and reviews samples of content and decisions.
AI coding agents write the code and content, run the tests and checks, deploy, verify the live site, and write down what they learned for the next session.
AI agents do not remember earlier sessions. Everything learned has to live in files that the next session reads first.
The stack
| Layer | Choice | Why |
|---|---|---|
| Framework | Astro 5, with most pages prerendered | Mostly static pages, plus a few server endpoints |
| Language | TypeScript throughout | The type checker is the first reviewer of AI-written code |
| Styling | Tailwind CSS 4 | Easy for agents to keep consistent |
| Hosting | Cloudflare Workers + Static Assets | One deploy for static pages and server routes |
| Database | Cloudflare D1 (SQLite) | Saved user state, waitlist, maintenance schedule |
| CI/CD | GitHub Actions | Deploy on every push to production; daily maintenance |
| Tests | Vitest |
Architecture
- Official government sources
- Typed data files in the repository
- Build + checks
- Prerendered pages · en / zh / ja
- Cloudflare Worker
- Daily maintenance job → refreshes data, checks links
- Data files → one-way copy → Cloudflare D1 → Worker
Data lives in code, not in a CMS. All published facts — countries, cities, visa routes, tax rates, holidays, universities — live in typed TypeScript files in the repository. They are the single source of truth; the database receives a one-way copy. Every fact change is a reviewable diff, which suits AI agents well. Each data point traces back to a recorded source, and pages link to the official source rather than claiming to be it.
Countries are the centre of the site. Each country hub has five pillars: Living, Work, Immigration, Education, Business. Adding a country or topic is append-only: add the data, and routes, navigation and the sitemap follow without touching layout code.
Languages. English is served at the root; Chinese and Japanese live under /zh/ and /ja/. Every translated string is stored by language key, so adding a language means adding a key, not restructuring code.
The workflow
- Work on a development branch
- Tests and checks pass
- Merge into production
- Automatic deploy
- Check the live page
- Every deploy runs a type check, a translation audit, data validation, and a set of narrow quality checks, each written after a real mistake. If any of them fails, nothing ships.
- After a deploy, the agent confirms that the version now serving is the one it pushed. A successful push does not prove that the deploy succeeded.
- Daily maintenance runs without a person. A scheduled job refreshes exchange rates and public holidays, checks outbound links, and regenerates directories. If a generated file shrinks sharply, fails a sanity check, or breaks the type check, the change is reverted, not committed.
What went wrong, and what we changed
These are the useful part. Each one became a rule or a check.
- Outgrowing the host. The site started on a platform with a per-deploy file limit. Three languages and hundreds of entities outgrew it, so it moved to Workers.
- Redirects that never ran. Redirects written in framework middleware silently did nothing on prerendered pages. They now live at the CDN layer.
- Pages that 404 instead of rendering on demand. A prerendered route serves only the paths it listed at build time. "The server will handle it" was a wrong assumption.
- Missing translations that passed the type check. A loosely typed registry accepted a missing language, and some pages shipped English text in other languages. Stricter types and a detector fixed it.
- Translated keys. Machine translation once translated data identifiers along with the text, which silently removed content. A check now compares structure across languages.
- Green checks, broken page. Passing checks can still produce a page that looks wrong. The rule now is to look at the rendered page after every change.
- A source link is not a source. We checked 30 randomly chosen values against the links next to them. Of the 22 links we could open, none contradicted the value, but 9 pointed to the authority’s homepage, where the value cannot be found. A reader who clicks "source" and finds no number has been let down. Our methodology page now says exactly how far the links go.
- More pages did not bring more traffic. For a young site, the bottleneck is authority, not page count. We stopped adding pages for the sake of it.
What we would tell someone starting today
- Write the rules down from day one. Agents forget between sessions; files don't.
- Turn every repeated mistake into an automated check, not a reminder.
- Keep data in typed files under version control. A diff is the cheapest review there is.
- Verify the live site, not the push. Silent failures are the normal kind.
- Have people decide what not to build. Agents will happily build everything.