Stage gate software puts current delivery evidence in front of the decision-maker at each gate, records the decision with its reasoning, and keeps the gate schedule visible. This guide covers how to evaluate the options and when a one-page template is enough.
Stage gate software is a category of tooling that puts current delivery evidence in front of the person deciding at a gate, records the go, hold, or kill decision together with its reasoning, and keeps the gate schedule visible so that no piece of work proceeds by default. Vendors bundle roadmaps, resourcing, and timesheets around that core, and those features belong to general portfolio management. The gate function is narrower. It is also harder to do well.
This piece assumes you already know what a stage gate is. It covers what software has to do to earn a place at the gate, how to tell the contenders apart, and when the right answer is to buy nothing.
A gate works when three things are true. Someone can say no, evidence sits in front of the decision-maker, and the decision is recorded with its reasoning. The organisation grants the stop option, and a gate without one is theatre that no software can repair. Software can make the other two conditions cheap to hold, gate after gate. It can also show drift when they slip.
Judge any candidate against three tests.
Spreadsheets and slide decks fail all three tests, and they fail quietly. Someone assembles the steering pack by hand in the days before the meeting, so the numbers are stale by the time anyone reads them. The decision, if anyone captures it at all, lives in an email thread or a minutes document that nobody can find at the next gate. No schedule shows which projects are overdue for review. Work proceeds by silence. On the day, all of this looks like a normal meeting.
Start here, because it decides most of the rest. A gate tool that sits apart from the delivery system brings the staleness problem straight back. Someone still exports, reformats, and pastes, and the gate still reviews last week. If work runs in Jira, the gate evidence should read from Jira, and if it runs elsewhere, the tool needs a live connection to wherever it runs. An integration on a feature list proves little. Ask to see the exact screen a decision-maker would open on gate day.
Some stage gate process software is presentation software with a governance label, offering templates for gate packs and workflows for circulating them. That automates the meeting and leaves the substance where it was. Look for the raw material behind every number on the screen: the epics behind the progress figure, the risk entry behind the risk rating, and the actuals behind the spend line. If the decision-maker cannot click through to the source, the tool is asking to be trusted. Gates exist to replace trust with evidence.
Make the record structural. It should capture the decision, the decider, the date, the reasoning, the conditions, and the evidence as it stood, all at the gate and locked afterwards. Change requests belong in the same log, because scope drift between gates is where governance leaks. One screen should hold the answer when an auditor asks why stage three was approved.
Permissions are governance. The tool should separate the people who prepare evidence from the people who decide, and stop one person doing both on the same investment. Separation of duties sounds bureaucratic until a project manager approves their own gate. The tool also needs a working reject path. Ask to see what happens when a decision is hold or kill. If nobody can show you, nobody has tested it.
Price the licence, then price what it removes. Take a program that runs monthly gates across a dozen investments. Each cycle someone exports, reconciles, formats, and chases to assemble the packs, and the hours that work takes are the true baseline for the comparison, because they are the cost the licence has to beat. A cheap tool that leaves the assembly in place costs more than a dearer one that removes it. Ask each vendor which of those hours disappear, and how.
If the portfolio is three projects, one sponsor, and a horizon of a couple of quarters, a platform is overhead. A recurring calendar entry, a one-page gate template, and a sponsor willing to say no will outperform any tool. At that scale the constraint is discipline. Discipline comes from the sponsor. Software earns its keep when the portfolio grows past what hand assembly can serve, when staff turnover means nobody remembers why stage two passed, or when auditors will ask for the record. A platform bought to compensate for a sponsor who never says no gives the theatre better production values.
Tollgate is a Forge app that runs inside Jira Cloud, built for teams whose delivery already lives there. Each investment carries a business case whose financial case calculates NPV, IRR, and payback from the cashflows you enter, and work packages link to the Jira epics doing the delivery, so the gate reads progress from the work itself. Risks & Opportunities, Decisions, and Changes sit on the same record with an audit trail. Approvals of changes and decisions carry separation of duties. Whoever raises one cannot approve it.
Gate states are advisory. The sponsor makes the call, and the record shows it. Investment Health rolls the record up into status cards, and those cards are the steering pack, so the meeting reads the dashboard and nobody assembles a deck. Forge apps run on Atlassian’s own infrastructure, so the data stays inside your Atlassian tenancy and no Softwired server sits in the path. Tollgate is free for up to 10 users and priced per user through the Atlassian Marketplace above that, month to month.
Tollgate is on the Atlassian Marketplace. Install it on one live investment and run the next gate from the dashboard.
Tollgate keeps the business case, the gate decisions and the payoff in one record, next to the delivery they pay for.