InsanelyGreat's Shippable States Development is a pragmatic AI-powered discipline that helps solo developers and small teams maintain a deployable, production-ready state at all times — without the chaos of a large engineering org.
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. Designed for solo developers and teams of 1–5. Published at insanelygreat.com.
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 designed for solo developers and small teams who use AI coding tools to build production software.
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 solo developers and small teams build excellent software without having to repeat thirty years of avoidable mistakes to get there.
This is shareware in the original spirit of the word: built by someone who cares, offered freely, sustained by the people who find it valuable. If SSD has helped you ship better software — if it saved you a death march, helped you convince your team to actually deploy, or just gave you a name for the discipline you already believed in — a small contribution keeps the work going and tells me it's worth continuing.
Entirely optional. No sign-up. No strings. Just good karma.
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 free — built specifically for solo developers and small teams who want to build like a well-run engineering org, without needing one. No sign-up, no paywall, no strings. If this has made you ship better software, a small donation keeps the work going.
The full InsanelyGreat's SSD Claude Code skill set — architect, coder, reviewer, skeptic, and more — is public and free to clone. Works today with Claude Code.
View on GitHubShareware honor system. If SSD saved you a death march or helped your team ship with less stress, consider buying me a coffee.
Donate via Venmo$20 suggested · entirely optional
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 is also a strong fit for startups, internal tools, and any project where forward motion and frequent feedback outweigh the ceremony of large-organization release processes.
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. As of the SSD skill set v1.17, parallel workstreams are first-class. 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) was designed specifically for solo developers and teams of 1–5. 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