Two Ways to Publish: How We Write Blog Posts

We wanted a blog that worked the way we work. Sometimes that means opening a browser and typing. Other times it means staying in the terminal and pushing content like code.

So we built both options.

Option 1: The Admin Dashboard

The straightforward way. Log in, click "New Post," and start writing.

The dashboard gives you:

• A title field and markdown editor
• Category and tag selection
• Draft/publish toggle
• Live preview of your formatting

This works well for quick posts, editing existing content, or when you want to see exactly what readers will see before publishing.

Option 2: From the Command Line

Sometimes you're already deep in code. Opening a browser feels like context switching. For those moments, we can publish directly through the terminal.

The process:

1. Write your post in markdown
2. Create a database migration with the content
3. Push it to Supabase with one command

The post goes straight to production. No browser needed.

Same Database, Different Doors

Both methods write to the same place - our Supabase database in the cloud. The admin UI and the CLI are just two doors into the same room.

This means:

• Posts created via CLI show up in the admin dashboard
• Posts created in the dashboard can be found in the database
• Either method can edit what the other created

When We Use Each

Admin UI works best for:

• Drafting and revising
• Adding images or formatting tweaks
• Quick edits to existing posts
• When you want visual confirmation

CLI works best for:

• Developer-authored technical content
• Batch publishing multiple posts
• When you're already in the terminal
• Keeping content in version control (temporarily)

What We Learned

Our first post went through the CLI. We wrote the markdown, created a migration, pushed it to the database, and watched it appear on production.

Then we deleted the migration file.

Why? Because blog content doesn't belong in the codebase long-term. The migration was just a delivery mechanism. Once the content reached the database, the file had served its purpose.

Think of it like a letter and an envelope. The migration was the envelope. The blog post was the letter. You don't keep the envelope after the letter arrives.

The Setup

For anyone curious about the technical side:

• Frontend: Next.js with a markdown renderer
• Database: Supabase (PostgreSQL)
• Markdown support: Headers, code blocks, lists, links - all the basics
• Code highlighting: Syntax colors for code examples

The admin dashboard is just a React form that writes to Supabase. The CLI approach uses Supabase migrations to insert rows directly.

Why This Matters

Flexibility reduces friction. When publishing is easy, you publish more. When you have options that match how you're already working, you don't have to break your flow.

Some days we want the visual editor. Some days we want to stay in the terminal. Now we can do both.