GitHub Is a Library Pretending to Be a Deployment System (And I Love It Anyway)

I use GitHub every day. I love GitHub. It's an exceptional tool for what it was designed for: version control, collaboration, code review, and maintaining a coherent history of changes across a complex codebase. It's a sophisticated library system for code, and libraries are wonderful things.

But ecommerce doesn't need a library. Ecommerce needs a deployment system optimized for speed. And somewhere along the way, we convinced ourselves that version control and deployment were the same problem.

They're not.

What GitHub Actually Is (in my opinion)

GitHub is version control with a collaboration layer on top. It was built for software development cycles measured in weeks or months, for teams working on complex codebases where deliberate, reviewed changes are essential. It's optimized for tracking changes, attributing blame, managing merge conflicts, and enabling multiple developers to work on the same code without destroying each other's work.

It's exceptionally good at this. If you're building an operating system, a database engine, or any substantial piece of software, GitHub (or git generally) is exactly what you need. The branching strategies, the pull request workflow, the required reviewers, the protected branches with all of these existing for good reasons.

The problem is that ecommerce operates at a completely different pace, and we're using the same tools designed for Linux kernel development to deploy landing pages for flash sales.

The Ecommerce Speed Problem

Here's what a typical "simple" change looks like in an ecommerce environment using GitHub:

Marketing needs to change the hero image on the homepage. This requires a developer to update the code or config, create a branch, commit the change, push to GitHub, open a pull request, wait for CI checks to run, get code review approval, merge to main, trigger the deployment pipeline, and wait for the deploy to complete.

Minimum time if everything goes smoothly: 15-20 minutes. More realistically: 30-60 minutes if the developer is busy, if CI is slow, if the reviewer isn't immediately available.

Meanwhile, your competitor just dropped their price by 20%. You need to match it. Same process. Same ceremony. Same 30-60 minute minimum.

Black Friday banner has a typo. Same process. A/B test needs to launch. Same process. Flash sale starts in 30 minutes and you need to update the homepage. Same process.

Every change, regardless of risk or complexity, goes through the same workflow designed for mission-critical code changes.

The False Equivalence Problem

This is where the GitHub-as-deployment-system model breaks down. It treats all changes as equally risky and equally complex. Changing the payment processing flow? That's high risk. That should require review, testing, staged rollout, the full ceremony. You want git history. You want rollback capability. You want multiple people looking at it.

Changing a banner image? Low risk. The worst case scenario is the image looks bad. You need speed and the ability to fix it immediately if something goes wrong.

Your GitHub workflow doesn't distinguish between these. Everything goes through the same pipeline because "best practices." But best practices for what? For software engineering, yes. For operational agility in ecommerce? Not remotely.

The coordination problem isn't that GitHub lacks features. The coordination problem is that the entire mental model of version control assumes a pace that ecommerce stopped operating at years ago.

The Workarounds That Prove the Point

Look at what ecommerce teams actually do in practice:

They implement feature flags so they can deploy code that doesn't run yet, then enable it instantly without another deployment. They build CMS systems so marketing can edit content without touching git. They create admin panels for configuration changes. They sometimes (don't tell anyone) make direct database edits because the git workflow is too slow for urgent changes.

Every workaround is an admission that git workflows don't match ecommerce pace. You're routing around GitHub because GitHub is the bottleneck.

This isn't GitHub's fault. GitHub is doing exactly what it was designed for. The problem is that we're using it for something it wasn't designed for and then complaining that it doesn't work perfectly.

And here's the thing: the "solution" everyone reaches for is to add more tools. A CMS for content. A feature flag service for deploys. An admin panel for config. A CDP for data. Each tool solves one piece of the coordination problem and creates three new coordination problems in the process.

What We're Actually Optimizing For

GitHub workflows optimize for code quality, review processes, audit trails, and preventing bad deployments. These are good things. These are important things. But they come at a cost: deployment speed, marketing agility, and response time to competitive changes all suffer.

Ecommerce needs both. Don't break the site AND move fast. GitHub gives you one at the cost of the other.

The question isn't whether GitHub is good (it is). The question is whether it's the right tool for every type of change in ecommerce (it's not). And the follow-up question is: do you solve this by adding seventeen disconnected tools, or by building something that actually coordinates?

The Mental Model Mismatch

Think about what a library actually is. It's a place where items are carefully cataloged, stored systematically, and retrieved deliberately. You don't go to a library when you need something right now. You go to a library when you need something specific and you value the organizational system that helps you find it.

GitHub is a library. A very good library. But ecommerce often needs a deployment system, which is a different thing entirely. A deployment system is optimized for getting changes live fast and safely, with version control as a feature rather than the entire architecture. We've retrofitted our library into a deployment system by adding CI/CD pipelines, automation, and calling it DevOps. It works, mostly. But the impedance mismatch is always there.

The Coordination Problem Nobody's Solving

The real issue isn't that GitHub is slow. The real issue is that nobody's built a system that understands the difference between high-risk code changes and low-risk content changes, that knows marketing needs speed while engineering needs safety, that can coordinate between what's deployed and what's enabled and what's actually affecting customers.

Instead, we have GitHub for code. A CMS for content. Feature flags for rollout. Analytics for measurement. Attribution tools for tracking. Admin panels for configuration. Each one a disconnected system with its own interface, its own permissions model, its own idea of what "deployed" means.

This is the coordination problem I keep thinking about at 3am. Not "how do we make GitHub faster" but "how do we build something that actually coordinates all of this without requiring seventeen different tools that don't talk to each other?"

I'm working on something in this space. Something that understands that changes have different risk profiles and should flow through different paths accordingly. Something that coordinates work across teams without forcing marketing to open pull requests or developers to edit CMS entries. Something that doesn't replace your tools but sits between them and actually makes them work together.

You'll find out more when there's more to know. For now, it's enough to say: the solution isn't better tooling. The solution is better coordination.

Why I Still Love GitHub

Despite all of this, I use GitHub every day and genuinely love it. It's an exceptional tool for managing code complexity, enabling collaboration, and maintaining a coherent history of changes. The pull request workflow is one of the best inventions in software development. Code review catches bugs. Version control saves you when things break. But loving a tool doesn't mean using it for everything.

A hammer is an excellent tool. That doesn't mean every problem is a fucking nail.

GitHub is exceptional at what it was designed for. The problem isn't GitHub. The problem is the assumption that version control infrastructure should also be your deployment infrastructure for a business that needs to move at ecommerce speed.

Your competitor just changed their pricing. You're waiting for CI to pass. GitHub isn't failing you. You're using a library as a deployment system and wondering why it feels slow.

The solution isn't abandoning GitHub. The solution isn't adding more disconnected tools.

The solution is something that coordinates between the speed marketing needs and the safety engineering requires, something that understands context and risk, something that makes your existing tools work together instead of against each other.

That's the coordination problem worth solving.