Kyles Blog

I Built a Blogging Platform in a Weekend. Here’s Everything That Happened.

2026-04-07T18:16:28+00:00

Over one weekend, I shipped a complete blogging platform from first line of code to production. It’s powered by the Notion API and includes AI-generated SEO, multiple themes, custom domains, Stripe billing, and privacy-friendly analytics, built solo with a stack I know well: Notion, Laravel, and a lot of stubbornness.

This is the story of building tiniest.blog.

The Idea

I write in Notion. Most of my notes, drafts, and half-formed ideas live there. But publishing those ideas as a blog always meant migrating content to WordPress, Ghost, or Substack, copying text, reformatting, fiddling with settings, losing the Notion workflow I’d already built.

The question I kept coming back to was simple: what if I could point at a Notion database and have a blog appear? I didn’t want a brittle export pipeline or a script I’d need to babysit. I wanted a real blog that stayed in sync automatically, shipped with proper SEO, supported a custom domain, and loaded fast enough to feel like a static site generator.

Day 1: The Foundation

The first commit landed on Saturday afternoon. A design document, a monochrome editorial design system, and a 19-task implementation plan. I knew the shape of what I was building before I wrote a line of application code.

The stack: Laravel 13 for the backend, React with TypeScript via Inertia.js for the dashboard, PostgreSQL, S3 for static file storage. No server-side rendering for blog pages, the output would be pure static HTML. Zero JavaScript on the public blog. Under 8KB of CSS.

The first real challenge was the Notion API. Notion’s block structure is deeply nested, a page contains blocks, blocks contain children, children contain more children. A table of contents block needs to scan all sibling headings. A column layout needs to know how many columns exist. A synced block references content from somewhere else entirely.

I built a NotionBlockRenderer that handles every Notion block type: paragraphs, headings, lists, code blocks, tables, toggles, callouts, equations, bookmarks, embeds, columns, and more. Each block maps to semantic HTML. The renderer walks the tree recursively, handles nested children, and produces clean, accessible markup.

By the end of day one, I had:

Notion OAuth for connecting workspaces
A full sync pipeline (fetch pages, render blocks, generate HTML)
Static blog output with a proper editorial design
An onboarding flow that goes from “nothing” to “live blog” in three steps

Day 2: The Hard Parts

On Sunday I focused on the things that separate a prototype from something that feels like a product.

AI-generated SEO. Every blog post gets automatic meta tags, Open Graph data, JSON-LD structured data, and keyword extraction, all generated by an AI agent that reads the content and produces structured output. No SEO knowledge required from the user. The blog just ranks.

Multi-blog support. The initial design was one blog per user. By Sunday morning, I’d rearchitected the entire data model: users can have multiple blogs, each connected to different Notion databases, potentially from different Notion workspaces. This meant rewriting controllers, policies, and the entire routing system.

The image problem. Notion’s image URLs expire after one hour. Every image in every blog post would break within 60 minutes of syncing. The fix: an image proxy that downloads every Notion image to our own S3 bucket during sync, rewrites the URLs in the HTML, and serves them permanently.

Themes. I started with one monochrome editorial theme. By the end of the day, I had six: Default (Fraunces serif), Warm (Playfair Display, earthy tones), Ocean (DM Sans, cool blues), Brutalist (Space Mono, raw and bold), Pastel (Nunito, soft colours), and Night (JetBrains Mono, terminal green on black). Each theme is a single CSS file under 8KB. Each supports dark mode automatically via prefers-color-scheme.

Layouts. Four index layouts (list, grid, magazine, minimal) and three post layouts (standard, wide, sidebar). Mix and match with any theme. All pure CSS, no JavaScript.

Stripe billing. Free tier gets 3 blogs with 10 posts each. Pro unlocks unlimited everything plus custom domains. Cashier handles subscriptions, checkout, and the billing portal.

Privacy analytics. Page views recorded server-side, no cookies, no JavaScript tracker, no GDPR consent banner needed. Just path, referrer, and country, with IP addresses hashed using a daily rotating salt.

Day 3: Production and the Domain Problem

By Monday I was ready to put it in production, using Laravel Cloud for hosting and Cloudflare for DNS.

The first deployment worked, and subdomain routing (kyle.tiniest.blog) resolved correctly. The blog loaded, the themes rendered as expected, and I got that brief satisfaction of something working on the first try.

After that, I moved on to custom domains.

Custom domains on a platform like this are genuinely hard. The user adds rusby.blog to their settings. We need to issue an SSL certificate for that domain, route traffic to our servers, and resolve the request to the correct blog, all automatically, for any domain, without manual intervention.

Attempt 1: DNS verification. Check if the user has set a CNAME record pointing to us. This works, but Cloudflare’s proxy strips the original hostname, and browsers throw Error 1014: CNAME Cross-User Banned when the CNAME crosses between Cloudflare accounts.

Attempt 2: Cloudflare for SaaS. This is the right solution, Cloudflare’s product for exactly this use case. Register each custom domain as a “custom hostname” via their API, and Cloudflare handles SSL provisioning automatically. The fallback origin points to custom-domains.tiniest.blog.

Attempt 3: But Laravel Cloud only accepts *.tiniest.blog. When rusby.blog arrives at Cloudflare’s edge and gets routed to our origin, the Host header is still rusby.blog. Laravel Cloud rejects it, it only allows hostnames matching the configured domain.

The fix: a Cloudflare Worker. A 20-line JavaScript function that intercepts custom domain requests, rewrites the Host header to custom-domains.tiniest.blog, and preserves the original domain in an X-Original-Host header. Laravel reads that header and resolves the correct blog.

In practice it didn’t work on the first try, and rusby.blog kept returning a 404.

The X-Original-Host header was being set by the Worker, but Laravel Cloud’s load balancer was overwriting X-Forwarded-Host with the rewritten hostname. The original domain was lost somewhere in the proxy chain.

It took about an hour to diagnose, and the eventual fix was a single line. I added X-Original-Host as a custom header that load balancers don’t touch, and checked for it first in the middleware. Once that was in place, requests started resolving to the right blog.

The Security Audit

Before calling it done, I ran a full security audit, four parallel agents examining authentication, injection vectors, authorization, and infrastructure hardening.

They found 15 issues. Three critical:

Stored XSS via Notion links. The block renderer HTML-encoded URLs but didn’t validate the scheme. A javascript: URL would pass through e() untouched and execute in the browser. Fixed with a URL sanitizer that only allows http://, https://, mailto:, and tel:.
Webhook authentication bypass. The Notion webhook endpoint silently accepted requests when the webhook secret wasn’t configured, a fail-open pattern. Changed to fail-closed.
Header spoofing on custom domains. Any direct request to the origin could set X-Original-Host to impersonate any blog. Fixed with a shared secret between the Cloudflare Worker and Laravel.

Plus 12 more: HSTS headers, Content Security Policy, rate limiting on registration and domain creation, mass assignment hardening, destructive command protection, password policy fallbacks. All fixed in a single commit.

More Themes, More Layouts

Research across Ghost, WordPress, and Substack, plus 2026 design trend reports, showed clear demand for more variety. I added four more themes:

Terminal, IBM Plex Mono, matrix green on black. For developers who want their blog to feel like a terminal.
Serif Classic, Playfair Display and Merriweather on warm cream. The New Yorker meets Substack.
Swiss, Inter with a red accent. International Typographic Style, clean, grid-based, timeless.
Meadow, DM Serif Display with sage green tones. Warm minimalism, 2026’s biggest design trend.

Two new index layouts: Newsletter (date-focused, Substack-style) and Masonry (Pinterest-style cards). Two new post layouts: Longform (wider column with drop caps) and Split (side-by-side hero image and title).

10 themes. 6 index layouts. 5 post layouts. 300 possible combinations, all from pure CSS.

What tiniest.blog Is Now

Three days of work produced:

A complete multi-tenant blogging platform built on Laravel 13 and React
Real-time Notion sync via webhooks with a polling fallback
AI-generated SEO for every post, meta tags, JSON-LD, Open Graph, keywords
10 CSS themes and 11 layout options, all under 8KB, zero JavaScript
Custom domains via Cloudflare for SaaS with automatic SSL
Privacy analytics, no cookies, no tracking scripts
Stripe billing with free and Pro tiers
Static HTML output served from Cloudflare R2, sub-second page loads
162 commits, comprehensive test coverage, and a full security audit

The architecture is simple: you write in Notion, we sync and build static HTML, your readers get the fastest blog on the internet. No migration. No lock-in. Your content stays in Notion where it belongs.

What’s Next

At this point the product works and the infrastructure feels solid, but the next challenge is distribution.

The go-to-market is Reddit-first, r/Notion, r/SideProject, r/webdev, followed by a Product Hunt launch and outreach to Notion creators. The pitch writes itself: “Turn your Notion database into a beautiful blog in 60 seconds.”

If you write in Notion and want a blog without the overhead, tiniest.blog is live. Connect your workspace, pick a database, and your blog exists.

Built by Kyle Rusby. Powered by Notion, Laravel, and an unreasonable amount of concentration 👀

Try it free at tiniest.blog.

Kyle’s Software Engineering Blog. Building Simple, Sturdy Products with tiniest.blog

2026-04-07T18:16:25+00:00

Hi, I’m Kyle.

Welcome to my software engineering blog, where I share software engineering lessons from building and shipping real products. I like making things that feel simple, sturdy, and pleasant to use. I also like writing, usually in short bursts, usually when something has just clicked, or just broken, or just surprised me.

If you arrived here from search, here is the quick context. I built tiniest.blog to make publishing blog posts genuinely easy. It is for people who want to write and hit publish without turning it into a weekend project. Less setup. Less fiddling. More writing.

If you’re here, grab a tea or a coffee, and stay for one post, or wander around for a while.

Why I write software engineering lessons

My brain works better when I put ideas into words. Even a small note can turn a fuzzy thought into something you can hold.

Some posts will be practical. Things I tried, what worked, what did not, and what I would do differently next time. Some will be reflective. What it feels like to build software products for real people, under real constraints, with limited time and imperfect information.

I am not trying to be a guru. I am not trying to win the internet. I am mostly trying to be useful to my future self, and hopefully to you as well.

Software engineering lessons and topics covered

Most of what I write will be about building software products. That includes the craft of engineering, and the choices that make a product feel calm and reliable.

Building and shipping software products
Tools and workflows that reduce friction
Small design decisions that add up
Bugs, fixes, and lessons learned
The boring fundamentals that keep things running

Sometimes the writing will be technical. Sometimes it will be plain language. I like both. I like code, and I like the human side of building things.

I also care about the pace of work. The goal is not to sprint forever. The goal is to keep going. So you might see posts about habits, focus, energy, and the small routines that make a week feel manageable.

A warm, practical tone

I aim for clarity, but I do not want this place to feel stiff.

Software can be serious, but it can also be playful. There is joy in getting a tiny detail right. There is relief in deleting a big chunk of code. There is comedy in the way a one line change can break everything.

So I will try to keep things warm. I will keep it honest. I will keep it readable.

If I change my mind about something, I will say so. If I make a mistake, I will correct it. If you spot something off, feel free to tell me.

About tiniest.blog

tiniest.blog is my attempt to remove the usual barriers to blogging.

A lot of writing tools make you do a pile of setup before you get to the part that matters. Pick a theme. Pick a layout. Pick a framework. Pick a hosting provider. Pick a build pipeline. Then, maybe, write.

I wanted the opposite. I wanted a short path from thought to published post.

I have noticed that good habits often fail because the cost is too high in the moment. Not because people are lazy. Because life is busy, and the barrier is just a bit too tall.

So I try to lower the barrier. If you want to write more, it helps when the tool gets out of the way. That is what I am aiming for with tiniest.blog, and it is what I am aiming for with this software engineering blog too.

Short posts, complete thoughts

This is not a place where every post needs to be a masterpiece.

Some posts will be a single idea, cleanly stated. Some will be a small tutorial. Some will be a note-to-self that turns out to be useful for someone else.

My only rule is that I want to publish complete thoughts. Even if a post is short, it should land the point. If I do not have the ending yet, I would rather wait and finish it than ship something half done.

Thanks for stopping by

If you want to follow along, start anywhere. Pick a title that looks interesting and see if it is your thing.

I will keep building. I will keep learning. I will keep writing.

And genuinely, thanks for reading :)