SolutionsCraftersWe help build the future
Back to Work
SolutionsCrafters product

Case study · GovernScore

Know what your Jira is actually configured to do

GovernScore connects read-only to a Jira Cloud site and grades its configuration against 46 deterministic governance rules. You get a 0-100 score, an A-F letter grade, evidence behind every finding, and a ranked list of what to fix first.

GovernScore is a SolutionsCrafters product. Rules, platform and operations, built and run in-house.

governscore.com
The GovernScore dashboard showing an overall score out of 100 with a letter grade, pillar cards for Configuration, Security and Usage each with their own score, a coverage summary, and a list of findings ordered by severity.
Try the live demo

Try a live, read-only demo

Open a fully populated dashboard over synthetic data. No signup. Nothing to change, and no real Jira is ever touched.

Not an Atlassian product. Jira is a trademark of Atlassian.

Live demo availableOpen to investmentAvailable for licensing

This product is open for business

A SolutionsCrafters product, engineered and demonstrable. We welcome conversations about investment, licensing or acquisition, by private arrangement.

01

Context

GovernScore is built for the people who get asked whether a Jira Cloud instance is in good order and have no defensible way to answer: administrators, platform owners and IT governance leads. The sites they look after have usually run for years and been configured by many hands. Schemes have multiplied, custom fields have piled up faster than anyone retired them, a permission scheme was widened once to unblock someone and never narrowed again, filters got shared more broadly than anyone intended, projects have gone quiet, and licences still sit with people who left.

02

Challenge

The instance is too large to inspect by hand and too important to guess at. Nobody can say which custom fields are still in use, which permission schemes grant more than the policy allows, or which filters are visible beyond the people who should see them. Cleanup keeps getting postponed because there is no agreed picture of what is wrong and no way to rank it. A spreadsheet review is stale the week it is finished, and two administrators looking at the same site rarely come back with the same list.

03 · Approach

Approach

The controlling decision was to keep every rule deterministic. A rule is a stated condition over configuration the scan can read, so the same site always produces the same score and every finding names the rule that raised it. The second decision was read-only by design: GovernScore inspects and reports, and holds no path to write to Jira, so it can be pointed at a production site without a change window. The third was to publish what the scan could not check. Where a check is blocked, it is named in a coverage report and excluded from its pillar average instead of being counted as a pass, so a narrowly scoped token lowers coverage rather than lifting the grade. The last decision was to make the standard itself adjustable, because a baseline nobody agrees with is a baseline nobody acts on.

System delivered

  • 46 deterministic governance rules across three weighted pillars: Configuration (23), Security (8) and Usage (15), resolved into a 0-100 score and an A-F letter grade
  • A read-only, rate-limit-aware scan that finishes in roughly four minutes, with live progress and jobs that resume after a restart
  • Object-centric evidence: one row per Jira object listing every rule that object trips, instead of a rule-by-rule report you have to cross-reference
  • A coverage report that names every check the scan could not run and why, with those rules excluded from the pillar average
  • Nine deep-dive analyzers: automation rule audit, workflow complexity, JSM and ITSM checks, scheme visualiser, licence impact, filter remediation, delta report, app inventory and Confluence governance
  • A remediation worklist where a finding becomes assignable work with an owner, due date, status and comments, alongside scan history, delta reports, scheduled scans and CSV or JSON export
  • Multi-tenant organisations with role-based access, invitations and switching between connected Jira instances, credentials encrypted at rest, and a free tier that needs no card
  • Plans and pricing run on Stripe: subscription checkout, the customer billing portal, and plan changes that take effect against the same organisation record the scans belong to

46 rules across three weighted pillars

Configuration23
Security8
Usage15

One 0–100 score and an A–F grade, with every finding traced back to the rule that raised it.

04 · What changed

What changed

  1. 01An administrator can state what is actually configured in the instance, and point to the rule and the object behind every answer
  2. 02The grade is reproducible: scan the same site again and you get the same result, so you can put a score in front of a steering group without arguing about how it was produced
  3. 03Cleanup starts from a ranked list instead of an opinion. The worklist says what to fix first, who owns it and when it is due
  4. 04The coverage report keeps the grade honest: a check that could not run is reported as unchecked, never as a pass
  5. 05A scan changes nothing in Jira, so a production site can be assessed without a change window or a rollback plan

Related services

Technology

Jira Cloud RESTDeterministic rule engineNext.jsFlaskStripe billing
Visit the public site

Have a project in mind?

Let’s define the next useful version of your product

Tell us what the product must do, who it serves, and where the current process breaks. Those three answers are enough to start.