InsanelyGreat's Shippable States Development keeps software in a deployable, production-ready state at all times; it was designed for solo developers through engineering organizations of thousands. It is a toolkit, not a doctrine: tune the cadence to your release surface, and keep the discipline of a state you could ship from.
Shippable States Development (SSD) — a pragmatic AI-powered software engineering discipline developed by Alex Horovitz that requires maintaining a deployable, production-ready state at all times. SSD replaces sprint-based release cycles with continuous-deployment discipline amplified by AI-assisted tooling. Practiced from solo developers to enterprise engineering organizations. Published at insanelygreat.com.
SSD is a toolkit, not a doctrine. Per Agile², process is a tool — if a practice here doesn’t increase your velocity, change it. I’ve adapted these disciplines to two-person startups and hundred-thousand-person manufacturers; the constant is measurement, not ceremony.
Shippable States Development (SSD) is a pragmatic AI-powered software engineering discipline in which a codebase is kept deployable at all times and a shipping event occurs every day without exception. Originated by Alex Horovitz, it is practiced by solo developers and by engineering organizations of thousands.
SSD differs from Continuous Delivery in one crucial respect: Continuous Delivery guarantees that software can be shipped at any time, while Shippable States Development requires that it is ship every development day. A development day without a ship is treated as a process failure, not a neutral outcome.
Over thirty years of building software — at NeXT, Apple, Bank Boston, Lehman Brothers, Disney, the NFL, Symantec, Intel, Apple (again), Ford, and now Snowcap Compute — I have made most of the mistakes there are to make. Death marches. Features that shipped broken. Teams that burned out. Codebases that became impossible to change. Projects that were "90% done" for six months. I know exactly how each of those stories ends.
InsanelyGreat's SSD exists because those lessons have real value to the next generation of developers. And that value multiplies only when it's shared freely. The goal has never been to monetize a methodology. The goal is to help engineers and the organizations they work in — from one person to a hundred thousand — build excellent software without having to repeat thirty years of avoidable mistakes to get there.
So this is published rather than sold: an open methodology, with the tooling that implements it in a public repository. Take it, fork it, argue with it, delete the parts that don’t fit your organization. A discipline earns its keep only by being used, and the fastest way to find out whether an idea is any good is to put it where people can test it against their own reality.
Public repository. No sign-up, no paywall, no license to negotiate.
Traditional development front-loads the visible work and back-loads the dangerous work. The result is predictable.
Every project has exactly three variables. You can fix at most one. The other two must flex.
What features and capabilities ship
When the software ships
How well it works in production
Most project failures come from pretending you can fix all three.
Pick your constraint. Let the others flex. Ship working software.
Simple ideas. Profound consequences — whether you're a team of one or twenty.
Your development environment must match production from Day 1. Deploy "Hello World" to production before writing any business logic. Deployment is never "the hard part" because you do it constantly. Production issues surface immediately when they're easy to fix.
At the end of each work session, the system must be in a state where all tests pass, no broken user-facing features exist, and it could be deployed to production without embarrassment. Not feature-complete. Just actually working.
Long-lived feature branches cause merge hell. All work happens on main, behind flags, off by default. Feature exists in production but is invisible until ready. No "works on my branch" syndrome.
Forward progress only. Every commit improves the system in some measurable way. No WIP commits. No "I'll fix the tests tomorrow." No commented-out code. The ratchet only moves forward.
Reducing scope is not failure — it's engineering judgment. Break work into independently shippable units. Prioritize ruthlessly. Ship whatever is complete and working by the deadline, not everything broken.
Concrete techniques that bring the principles to life in daily practice.
The SSD orchestrator now treats parallel workstreams as first-class. Multiple features, multiple branches, optional git worktrees, and overlap detection at gate time — all wired into the standard /ssd flow.
Run up to four workstreams in parallel against the same repo. Each gets its own branch, optional worktree, and tracked file footprint. The single-feature flow remains the default — parallel is opt-in.
/ssd switch <slug> pauses the current workstream, captures a handoff note, and checks out the target. No git stash dance, no losing your place.
/ssd feature new <slug> --worktree creates a separate working directory so two features can be edited side-by-side without checkout churn. Single-tree workflow is still the default.
When two workstreams touch the same files, /ssd gate raises a suggestion-tier warning — never a blocker. Overlap is often intentional; the orchestrator surfaces, you judge.
Running /ssd (no arg) on any branch resolves to the right workstream automatically. Branch name, recorded mapping, then prompt — in that order.
/ssd gate before merge. Parallelism reduces switching friction; it does not lower the bar.
On day 30 you should be able to deploy to production with confidence in under 10 minutes.
InsanelyGreat’s SSD and all the Claude Code skills are public — the methodology and the tooling that implements it. No sign-up, no paywall, no license to negotiate. Clone it, run it, and change the parts that don’t earn their keep where you work.
The full InsanelyGreat's SSD Claude Code skill set — architect, coder, reviewer, skeptic, epistemic auditor, and more — is public and free to clone. Works today with Claude Code.
View on GitHubThe complete guide — principles, patterns, gates, and the practice of holding a system in a shippable state, whether you are one engineer or a thousand.
Read the GuideAlso available as a hands-on tutorial
Shippable States Development (SSD) is a pragmatic AI-powered software engineering discipline in which a codebase is kept deployable at all times and a shipping event occurs every day without exception. It was originated by Alex Horovitz. The core claim is that daily shipping is not an aspiration but a design constraint — the codebase, tests, and workflows are all organized to make shipping today trivially achievable.
Continuous Delivery ensures that software can be shipped at any time. Shippable States Development requires that software is shipped every day. The difference is the mandatory cadence: SSD treats a day without a ship as a process failure, not a neutral outcome.
Shippable States Development was originated by Alex Horovitz and is published at insanelygreat.com/ssd.html.
SSD is well-suited to solo developers and small teams building production software, particularly those leveraging AI coding tools like Claude Code. It scales up as well — the same discipline has been adapted to large engineering organizations, where the constraint is usually the handoff between teams rather than the work inside them. It fits anywhere forward motion and frequent feedback matter more than ceremony.
SSD is a poor fit when shipping cadence is constrained by factors outside the team's control — regulated environments requiring formal change boards (medical device firmware, avionics, some financial systems), mobile app store review cycles that cap shipping frequency, or enterprise customers who contractually reject frequent updates. It is also inappropriate for research code and throwaway prototypes, where there is no production environment to ship into. In those cases, the daily-ship discipline becomes theater rather than a forcing function.
SSD requires three concrete practices: (1) the main branch is always deployable, so broken builds are treated as incidents; (2) every day includes a visible shipping event — a release, a deploy, or a user-facing change; (3) work is decomposed into pieces small enough to complete and ship within a day, which in practice means aggressive vertical slicing and a willingness to ship incomplete-but-correct functionality behind feature flags.
Yes. Parallel workstreams are first-class in SSD (since the v1.17 skill set, and current in SSD 2.0). The orchestrator supports up to four active workstreams per project, each on its own branch and optional git worktree. /ssd feature new <slug> creates a workstream; /ssd switch <slug> pauses the current one and checks out the target (with an automatic handoff note); /ssd gate detects cross-workstream file overlap and surfaces it as a non-blocking suggestion. The Shippable State Invariant still holds per workstream — parallelism reduces switching friction, it does not lower the bar.
For teams of 1–5, the best methodology is the one that keeps software deployable every day. Most popular methodologies — Scrum, SAFe, even traditional Kanban — were designed for 5–50 person teams at funded organizations. Their ceremonies cost more than they deliver at small team size. Shippable States Development (SSD) originated in exactly that context. See Software Engineering Methodologies for Small Teams: An Honest Comparison.
A solo developer is the product manager, the QA, the DevOps engineer, and the developer. The only way to survive this is to make every role automatic. SSD is the discipline that automates the roles you can't hire for: CI handles QA, feature flags handle release management, and the daily ship handles project management. See The Solo Developer's Engineering Manifesto.
Treat quality as a ratchet, not a pendulum. Every commit must improve the system in some measurable way: tests pass, no broken features, no commented-out code, no "WIP" left on main. Encode the ratchet in CI so it cannot move backward. See Code Quality Without a QA Team: The Ratchet Principle.
Standard Scrum was designed for a 5–9 person team with a dedicated Scrum Master and Product Owner. Below 3 people, the ceremony costs more than it delivers. The strongest alternatives are SSD (continuous shipping, no sprints), Shape Up (six-week cycles, betting table), and minimal Kanban (WIP limits and pull, no ceremonies). See Why Standard Scrum Fails Small Teams.
Stop managing releases as events. With continuous deployment plus feature flags, a "release" becomes a flag flip and a changelog entry. The work that used to require a release manager — coordination, QA gating, rollback planning — gets distributed into the daily work and automated tooling. See How Small Teams Should Think About Releases.
Most lifecycle complexity exists to manage deployment fear. Remove the fear by deploying constantly, and 80% of the ceremony dissolves. What survives: CI, feature flags, the Nightly Ritual. What dies: sprints, release branches, change advisory boards, QA gates as separate phases. See The Simplest Engineering Lifecycle That Actually Works.
Follow the four-week onboarding plan above: Week 1 — wire CI/CD and ship "Hello World" to production; Week 2 — ship one feature end-to-end behind a flag; Week 3 — establish daily deploy rhythm; Week 4 — optimize deploy time and remove old flags. The full Guide walks through each step in detail.
No shortcuts. No "we'll fix it later." No broken code on main. The payoff: no death marches, predictable delivery, high quality, low stress.
Read the full guide