Skip to main content

Beyond Blogging: Git as a Workflow Platform

· 4 min read

I thought I was building a blogging platform.

Then I thought I was building a note-taking platform.

Then I realized I wasn't really building either.

The blog and the notes are simply different workflows.

The actual product is something much larger.

A Git-native workflow platform.


The Observation

Every project I've started recently keeps converging on exactly the same architecture.

Whether it's:

  • blog posts;
  • documentation;
  • personal notes;
  • technical specifications;
  • project planning;
  • journals;
  • cookbooks;
  • knowledge bases;

they all follow nearly the same lifecycle.

Content

Markdown

Git

Validation

AI

Workflow

Output

The infrastructure barely changes.

Only the workflow does.


Git Is the Database

Instead of storing everything inside proprietary databases, applications, or cloud services:

Store everything as files.

Markdown.

JSON.

YAML.

Images.

Whatever makes sense.

Git already provides:

  • history;
  • synchronization;
  • collaboration;
  • branching;
  • backups;
  • offline support;
  • versioning.

These are problems Git solved decades ago.

Most modern applications simply rebuild them.


MCP Becomes the API

Once the repository is exposed through MCP, it no longer matters which AI client you're using.

The repository becomes programmable.

Instead of opening applications, you ask for outcomes.

Examples:

Save this as a note.

Turn this note into a blog post.

Convert this blog post into a design document.

Generate implementation tasks.

Create GitHub issues.

Publish the documentation.

Each request triggers a workflow.


The Workflow Engine

Imagine the platform like this:

Git Repository


Workflow Engine

├── Blog Workflow
├── Notes Workflow
├── Wiki Workflow
├── Cookbook Workflow
├── Documentation Workflow
├── Journal Workflow
├── Specification Workflow
├── Knowledge Base Workflow
├── Meeting Notes Workflow
└── Custom Workflows

Every workflow shares the same infrastructure.

  • Git
  • Markdown
  • Templates
  • AI
  • Validation
  • Search
  • MCP
  • Publishing

The workflow simply decides what happens next.


Blogging Is Just One Workflow

Idea

Markdown

Frontmatter

Validation

Git Commit

Publish Website

Nothing special.


Notes Are Another Workflow

Voice Note

Markdown

Git Commit

Search Index

MCP Knowledge Base

Same infrastructure.

Different output.


Documentation

Specification

Markdown

Validation

Documentation Build

Website

Again...

Same platform.


Specifications

Concept

Design Document

Technical Specification

GitHub Issues

Implementation

Exactly the same pattern.


Recipes

Recipe

Markdown

Categorization

Website

Shopping List

Still the same platform.


Journals

Journal Entry

Markdown

Private Repository

AI Summaries

Timeline

Again...

No new infrastructure required.


Why This Matters

The difficult part isn't building blog software.

The difficult part isn't building note software.

The difficult part is building:

  • Git integration
  • Authentication
  • Repository management
  • Templates
  • Validation
  • Search
  • AI orchestration
  • MCP integration
  • Publishing
  • Permissions

Once those exist...

Creating another workflow is relatively inexpensive.

You're composing existing capabilities rather than building another application.


The Bigger Picture

This also changes how ideas evolve.

Instead of isolated applications:

Idea

Note

Blog

Design

Specification

GitHub Issues

Implementation

Deployment

Documentation Update

Every stage produces another Git artifact.

Each workflow simply transforms one artifact into another.


A Hosted Git Workflow Platform

This realization also changes the product itself.

Instead of selling:

  • blogging software;
  • note software;
  • documentation software;

the platform becomes:

A hosted Git-native workflow engine with AI orchestration.

Blogging becomes one packaged workflow.

Notes become another.

Documentation another.

Customers could create entirely new workflows without changing the underlying platform.

The workflows become plugins.

The platform remains the same.


Looking Ahead

It's easy to imagine dozens of workflows eventually sharing the same infrastructure.

  • Blog publishing
  • Personal knowledge bases
  • Company documentation
  • Engineering specifications
  • Product requirements
  • Meeting notes
  • Research notebooks
  • Cookbooks
  • Personal journals
  • Project management
  • AI memory repositories

All of them are fundamentally the same problem.

Take structured content.

Store it in Git.

Expose it through MCP.

Run workflows.

Everything else is simply configuration.


Final Thought

I started by trying to make writing blog posts easier.

Somewhere along the way, I accidentally stopped building applications.

I started building a platform where applications are simply workflows running on top of Git.

That feels like a much more interesting destination.