Case Study · Jira Alternative
An internal work management platform designed as a ground-up Jira rethink: one tool the whole organization can live in.
Engineering, HR, marketing, and personal work ran in separate tools, so every cross-team question became a meeting and one shared dashboard suited nobody.
One platform where the workspace recomposes per role, and External User is a first-class citizen instead of a workaround.
Context
Project Sauf is a work management platform for planning projects, tracking progress, and automating workflows, designed as a ground-up rethink of Jira for one organization. The org ran engineering, HR, marketing, and personal task tracking in separate tools, so work fragmented and every cross-team question became a meeting. It turned out as one platform for every team: five workspace roles, five project types, and fourteen platform areas, told on this page through abstract, operable models instead of screens.
Confidentiality note
Due to NDA restrictions, nothing on this page is real UI: the interactive containers are abstract demonstrations of each feature’s purpose, and every label and number inside them is illustrative. Project Sauf is a white-labelled product name.
Why
The research behind Project Sauf is synthesis, not a study: years of our own lived pain running work through Jira-style tools. Five wounds became the design brief. Fragmentation across teams, role-blind dashboards that fit neither a platform admin nor a first-week contributor, external consultants bolted on through workarounds, automation running silently until a surprise bill or a late failure, and answering “who changed what, and when” as an archaeology project across admin screens.
Kept from Jira
Changed on purpose
Kept from Jira
The board-and-sprint delivery loop
Changed on purpose
Sprints sit alongside iterations, and Goal is a first-class work-item type
Kept from Jira
Custom fields and issue types as an extensible schema
Changed on purpose
Org-wide project types: Business, HR, Marketing, and Personal beside Software
Kept from Jira
Groups, teams, and an apps ecosystem
Changed on purpose
Five workspace roles, with External User as a first-class citizen
Kept from Jira
Automation as trigger, condition, action
Changed on purpose
Governed automation: scope, a run-quota meter, Draft states, failures surfaced
Making the case
A platform rebuild is argued in abstractions, and abstractions are where alignment quietly dies. Each of these comparisons replaced a circular conversation with a decision.
A wedding hall gives the caterer a pass that opens the kitchen and the service corridor, and nothing else. Nobody hands them a master key and a request to be careful with it.
So the product had to
Make External User a real role holding scoped access sized to what was shared, rather than an internal account with everything else hidden. Hiding is a setting somebody can get wrong. Scope is a boundary.
Call everything an issue in an HR team and the first thing a recruiter reads about a promising new hire is that they are an issue. The word was never neutral. It was just familiar to the people who chose it.
So the product had to
Move to work-items and make Goal a first-class type. Bringing non-engineering teams onto one platform is a vocabulary problem long before it is a features problem.
Structure
Fourteen platform areas, five roles, five project types. Without one organising rule that becomes a settings menu with ambitions.
Where things live
One rule decided every placement: the workspace opens on the question that role is paid to answer, and everything else is one step away.
Whoever just signed in
Why here
Five roles were sharing one dashboard that suited none of them. A platform admin and a first-week contributor do not open the same product for the same reason.
Admins, deliberately
Why here
Power users need this depth and everyone else needs it out of the way. Fourteen areas exist, and none of them greet a contributor on Monday morning.
Anyone who has to answer for it
Why here
Answering who changed what, and when, used to be archaeology across admin screens. Making it one place is what turns an audit from a project into a question.
The same platform, followed from the outside in. Two of these people do not work for the company, and one of them never signs in twice.
The journey, in plain words
4 stages
“I do not care what this thing can do. I need to know what I am supposed to finish today.”
What the design does
The workspace opens on the question that role is paid to answer, so capability is discovered later rather than presented first.
“Am I about to see things I should not, or be locked out of the one thing I am here for?”
What the design does
External User as a real role holding scoped access sized to exactly what was shared, instead of an internal account with things hidden from it.
Held back
This stage shaped the design but sits too close to the product to show. Happy to walk through it in conversation.
“How long has this been running, and what has it already touched?”
What the design does
Failures surface on the admin dashboard where someone accountable is already looking, rather than waiting to be discovered.
The platform is judged on its worst day, by whoever is least invested in it. That is the day the structure has to hold.
Ownership
The research was a team’s shared pain. The role model is the design I drove. Project Sauf defines five workspace roles: Super Admin, Global Admin, Project Admin, Developer, and External User, and I made the workspace recompose for each one. The call I care most about: External User is a first-class role, not a workaround, holding scoped access sized to exactly what was shared.
Sign in as each of the five roles. The abstract workspace recomposes: different blocks, different priorities, same product.
Sign in as
Five roles, one product. Each sign-in gets a different lens, not a different tool.
Workspace · Contributor lens
DeveloperAssigned to me
Active iterations
My QA work
Recent QA activity
Blocks are schematic stand-ins, not widgets. In the product, each person can also flip cards to charts and customize the rest.
What this role sees first
Signed in as a Developer, the admin blocks disappear entirely. The lens is my work-items, my iterations, my QA queue.
One product, five different mornings. The workspace answers a different question for each role, starting with the one that role is paid to ask.
Where the disagreement was
Rebuilding work management for one organisation is hard to justify against simply configuring an existing tool harder.
How it resolved
I framed it around the five wounds rather than the feature gap. Configuration could not fix role-blind dashboards or consultants held together with workarounds, because those are structural.
Retiring engineering dialect meant renaming concepts they had used daily for years.
How it resolved
I kept the delivery loop they trusted completely intact and changed only the vocabulary that excluded other teams, so the cost landed on wording rather than on how they work.
HR, marketing, and accounts had been told before that an engineering tool would work for them, and it had not.
How it resolved
Project types with their own language, rather than a software project with the labels swapped, which is what had failed them previously.
Impact
Software projects sit beside Business, HR & Accounts, Marketing, and Personal ones, each with its own key, lead, work-item counts, and active iterations. A sprint board and a hiring pipeline are, structurally, the same thing: work moving through states. Bringing non-engineering teams in meant retiring engineering dialect, so issues became work-items and Goal became a first-class work-item type, over the platform depth power users expect, fourteen areas of it.
Admin visibility is the other half: the audit log is audit-ready by design, every entry carrying its category, actor, timestamp, and captured IP, filterable and inspectable in place, with backup, cleanup, and export controls beside the stream.
Judgment
Every rule is the same sentence: a trigger, a condition, an action. The hard call was to wrap governance around that sentence instead of letting the engine run free. Rules are scoped Global or per-project, start life as Drafts, and a monthly run-quota meter makes cost visible before it is a surprise. Failures do not vanish: when a rule misfires, it surfaces on the admin dashboard, where someone accountable is already looking.
Publish rule archetypes from Draft to Live. The run-quota meter fills, and one rule misfires in simulation so you can watch the failure surface.
Close the loop
Project≈ 140 runs a month (simulated) · last-ran and run count kept per rule · own audit log
Auto-triage
Global≈ 260 runs a month (simulated) · last-ran and run count kept per rule · own audit log
Goal escalation
Global≈ 80 runs a month (simulated) · last-ran and run count kept per rule · own audit log
Draft rules cost nothing and touch nothing. Publishing is the moment a rule starts spending the quota.
Monthly run quota
140 of 500 simulated runs committed this month.
Room to spare. Every live rule declares its appetite up front.
No failures
Publish the escalation rule to see what happens when automation goes wrong: nothing hides.
Ungoverned automation is a liability with a scheduler. Quotas, Draft states, and surfaced failures turn it into infrastructure an admin can trust.
A plugin borrows trust from its host. A platform has to earn it, role by role, rule by rule, entry by entry.
Next Project
Customer SSO for Jira Service Management →