Project Workflows Software
A workflow isn't the diagram you draw of it. It's what a board actually lets a team start, finish, and get stuck on, and ShipSprint governs that directly.
What we mean by "workflow" here
Some tools sell a workflow builder: a canvas where you draw states, wire up transition rules, and configure what triggers what. ShipSprint doesn't have that canvas, and it's worth saying so before the word "workflow" implies something more elaborate than what's actually here.
What ShipSprint has is a smaller set of mechanics that govern how work actually moves through a board: WIP limits that cap what's in progress at each stage, a triage inbox that decides what enters the flow at all, and, for engineering teams, a live connection to GitHub that keeps the board's flow synced to what the code is actually doing. Fewer configuration screens, sure, but the flow itself is real and enforced, not just diagrammed.
The mechanics that govern flow
No builder to configure, these apply automatically to every board.
Each column carries a cap on how many cards can sit in it at once. A full column stops new work from entering until something moves out: it's the mechanism that actually prevents a board from turning into fifteen things "in progress" and nothing finishing.
Nothing joins the flow directly. New requests land in a triage inbox first, and someone decides whether and when each one enters the board, so the flow only ever contains work that's actually meant to be moving.
A branch opening moves the card into progress; a merged pull request moves it to done. For engineering teams this is the closest thing to workflow automation ShipSprint offers, and it's driven by the actual code, not a rule engine.
One tap marks an item blocked and routes it to the person who can move it, with context attached. A blocked card is visibly stuck rather than silently stuck, so flow that's interrupted shows up immediately instead of getting discovered days later.
A card that hasn't moved in a while surfaces on its own, with how long it's been sitting. Nobody has to notice the flow has stopped somewhere; the system notices for them.
An engineering board flows through review and merge; a marketing board flows through draft and approval; HR flows through interview stages. Each starts from a template built for that shape, though the columns, limits and stages are yours to change.
Flow, not stages: the distinction that matters
A workflow builder tends to encourage thinking in stages: define State A, define State B, define the rule that moves a card from one to the other. That's a reasonable model for a rigid approval chain. It's a poor model for most day-to-day work, where the real problem usually isn't which stage something is in. It's that too much work is in progress at once and nothing is finishing.
WIP limits attack that problem directly, at every stage, without anyone defining a single transition rule. A column that's full stays full until something moves out, which is a much blunter and more effective flow control than a beautifully diagrammed set of states that nobody enforces once the deadline pressure starts. The triage inbox does the equivalent job at the front of the flow: it controls what's allowed to start, rather than trying to control what happens to it once it has.
A concrete example
A support request comes in. It lands in triage, not directly on the board, so it can't skip the queue by arriving as an urgent message to whoever's online. Someone with visibility across the team's workload pulls it in. It enters "In progress," which is capped at four cards. If the column's already full, something has to finish or get bumped before the new request can start, so the team can't quietly take on more than it can actually handle.
An engineer opens a branch to fix it; the card moves automatically. Partway through, the fix needs input from someone on another team. One tap flags it blocked, and that person gets pulled in with the card's context already attached, rather than the engineer hunting them down. The pull request merges, the card closes itself, and at no point did anyone configure a rule to make any of that happen. It's just what WIP limits, triage and GitHub sync do by default. That's the kind of thing teams notice a week or two into using ShipSprint: nobody wrote a rule, and the board still behaved.
Why we didn't build a workflow builder
A configurable workflow builder is genuinely useful for one kind of team: one with a complex, mostly-fixed approval process that needs codifying once and enforcing forever, multi-stage sign-offs, conditional routing, the works. It's a real tool for a real need, and it's just not the need most of the teams on ShipSprint have.
Most teams' actual problem isn't "we need to encode an elaborate process." It's "work keeps piling up in the middle and nobody notices until it's late." WIP limits and a triage inbox solve that directly, with nothing to configure beyond setting the limits themselves. If your team's real need is the elaborate, rule-driven kind, it's fair to say plainly: this isn't built for that.
There's also a maintenance cost to a workflow builder that's easy to underestimate at setup time. Someone has to own the rules, update them as the process changes, and explain them to every new hire. A board governed by a small number of fixed mechanics, limits, triage, the blocked flag, doesn't accumulate that kind of debt, because there's no rule set to drift out of date in the first place. That's part of why a ShipSprint board still makes sense to a new hire on their first day: there's no rulebook to hand them, just a column that's full or isn't.
What this looks like day to day
- A column hits its WIP limit and the team physically cannot add a new card to it until something moves on.
- A new request sits in triage, not on the board, until someone decides it's ready to flow.
- Opening a branch moves a card automatically; merging its pull request closes it, with nobody touching the board by hand.
- A card stuck for a week gets surfaced on the dashboard before anyone has to ask why it hasn't moved.
- A marketing board and an engineering board flow through entirely different stages, each named for what that team actually does.
- A request can't skip the queue by arriving as an urgent direct message; it goes through triage like everything else.
- Nobody has to configure a transition rule for any of this; the same WIP-limit and triage mechanics apply to every board by default.
Common questions
No. Flow is governed by WIP limits, a triage inbox, and, for engineering teams, GitHub sync. There's no drag-and-drop canvas for wiring custom transition rules or conditional routing.
Yes, each column carries its own limit, and different boards can be configured differently, so an engineering review column and a marketing approval column don't need to share a number.
Opening a branch moves the associated card into progress, and a merged pull request closes it, so the board's flow stays paced to the actual code rather than to someone remembering to update it. This is available on Team plan and above.
They get the same WIP limits, triage inbox and blocked-flag mechanics, the parts of "workflow" that don't depend on code. HR, marketing and operations each run these on templates built for their own shape of work, all on one subscription; see product.
Yes, columns, their order and their WIP limits are all editable per board. What isn't configurable is the underlying mechanism itself: every board enforces WIP limits and routes new work through triage, regardless of what the columns are named.
Limits are yours to change, so a team under unusual load can raise one temporarily. The point isn't to make the limit unbreakable, it's to make exceeding capacity a visible, deliberate choice instead of something that happens by default while everyone looks busy.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required