Building laverty.io — a single platform for many different projects

Today I’ve been building the foundations of laverty.io — a personal website that brings together a number of very different projects under one roof.

This post is a snapshot of:

• what I want the site to become
• why I’m putting unrelated ideas on a single platform
• the tech stack I chose
• and where things are currently at

---

Why one site?

I have a lot of different interests that don’t naturally fit under a single theme.

Things like:

• VR and experimental environments
• health and fitness tracking
• family history and GEDCOM visualisation
• local community discussion spaces
• blogging while I build and experiment
• small tools and side projects

Each of these could easily be its own standalone website.

Instead, I want one account, one identity, and one place where all of these can live — while still remaining clearly separated from each other.

Some people might only care about:

• a fitness tracker
• a family tree viewer

Others might just:

• read blog posts
• comment on experiments
• explore VR projects

The idea isn’t to merge everything into one experience, but to host many separate experiences on a single platform, without forcing users to engage with things they don’t care about.

---

High-level structure

The site is designed so that:

• each project has its own space
• navigation makes it clear what exists
• users can engage with only what they want
• everything shares a single login system

Under the hood, this is handled by keeping concerns cleanly separated:

• static content where possible
• dynamic functionality only where needed
• a clear boundary between frontend and backend

---

The tech stack (and why)

Frontend

• Astro
• Static-first HTML
• Markdown-based content
• Partial hydration only when interaction is needed
• Deployed via Cloudflare Pages

Astro is a good fit because it lets me:

• write blog posts in Markdown
• ship very little JavaScript by default
• add interactivity incrementally
• grow from a simple site into something more complex without changing frameworks

Most pages are just HTML. Interactive pieces (like comment forms) are isolated and intentional.

---

Backend

• Cloudflare Workers
• Hono framework
• TypeScript
• No Node.js-only APIs

The backend is fully serverless:

• no long-running servers
• no Express or Fastify
• no Node-specific dependencies

Locally, everything runs via wrangler dev, which simulates the Cloudflare Workers runtime closely enough that production behaves the same way.

---

Authentication

• Clerk

Authentication is shared across the entire platform.

Clerk handles:

• login and registration
• session management
• token generation
• identity across frontend and backend

Locally, authentication is real, not mocked:

• the frontend uses a publishable key
• the backend verifies JWTs using a secret key
• the same flow works in production

---

Data storage

• Cloudflare D1 (SQLite)

Different parts of the site use the database for different things:

• blog comments
• forum-style discussions
• fitness and food logging
• uploaded metadata

My own blog posts live as Markdown files in Git.
User-generated content lives in the database.

That split keeps authoring simple while still allowing user interaction.

---

Blogging without a CMS

The blog is intentionally straightforward:

• Markdown files
• typed frontmatter via Astro Content Collections
• versioned in Git
• no admin UI
• no browser-based editor

This makes it easy to write about whatever I’m working on at the time — whether that’s VR, fitness, infrastructure, or tooling — without committing to a single topic or workflow.

---

Comments as a first-party feature

Instead of embedding a third-party comment system, the site uses its own:

• authenticated via Clerk
• stored in D1
• scoped to individual blog posts
• minimal UI
• no third-party scripts

Functionally, comments are just small discussion threads attached to posts, which can later expand into a broader forum system.

---

Current state (local development)

At the moment:

✅ The site runs fully locally
✅ Frontend and backend are separate processes
✅ Authentication works locally
✅ Users can log in
✅ Logged-in users can comment on blog posts
✅ Navigation and core pages exist

The local setup mirrors production closely:

• Astro dev server for the frontend
• Wrangler dev for Workers
• local D1 (SQLite) database
• real authentication tokens

That means features built locally behave the same way once deployed.

---

What’s next

From here, the plan is incremental:

• expand the blog and tagging system
• grow comments into lightweight forums
• build out the fitness tracker
• add GEDCOM upload and visualisation
• host WebXR / VR experiments
• introduce a small shop for experiments or digital goods

Each project will stay logically separate, while sharing the same underlying platform.

---

Why document this?

Part of the goal of this site is to document the process, not just publish finished work.

Writing while building:

• clarifies decisions
• creates a record for future reference
• makes it easier to iterate

This site isn’t meant to be a single-purpose product — it’s a place where multiple ideas can coexist, evolve, and occasionally overlap.

More updates to come.