Sastrify · Acquired by Deel · 2025 · B2B SaaS
Turning rigid approvals into a flexible visual workflow builder
Problem
Every SaaS purchase, renewal or cancellation at a customer runs through an approval workflow. The builder only handled linear ones, so enterprise clients couldn’t model their real approval logic. Some left for competitors that could.
My role
Led the end-to-end redesign of Workflow Setup, and made the case to widen the scope to Initiatives. The only designer on a team of 1 PM and 8 engineers. Also expanded the design system along the way.
Outcome
50+ enterprise customers adopted the new builder. Initiative creation rose 20% among early adopters in the first month, and 60% more IT-persona users built a workflow.
Sastrify helps companies control their software spending. Its approval builder couldn’t model how enterprise procurement actually works.
Mixpanel, first month after launch. Details in Results.
Affinity map from 10+ stakeholder interviews
The insight
The brief was to redesign Workflow Setup. Talking to our procurement team, I realised that was only half of it.
No one in the company could hold all the paths from creating a workflow through to Initiatives in their head. Not even the procurement team, who lived in it daily. And the workflows themselves were too rigid to model real approvals. Neither piece worked on its own, so I pushed to put both in scope.
Making the case
Two features instead of one needed a yes from leadership, so I brought evidence.
First, I ran a usability test of Initiatives with our CEO and CTO. They struggled with basic tasks and couldn’t find basic information in their own product, and they saw it happen.
Then I asked our procurement team how many of our clients ran this exact step on a competitor’s platform while also paying for our procurement team. That showed where the gap was: the team was strong, and the product was weak right where clients work with them.
We got the yes. The cost was a longer launch, and Workflows shipped in smaller chunks.
Before: a linear form
One step stacked on the next, in a flat form. No branches, no conditions, no way to say “if it’s over 10k, add finance.” One assignee per step and nothing in parallel, so one person on holiday froze every approval behind them. Teams that needed more rebuilt the same workflow by hand every quarter.
After: a node-based builder
A workflow is now a canvas. Drop in steps, branch them, set conditions, see the whole path at once. Departments approve in parallel, so one absence no longer stalls the queue.
The drawer
I wanted a pop-up next to the node, like our competitors. Deadlines pushed me to the drawer, already in our design system. It aged better: room to grow, so each release could add what customers asked for.
10 incremental releases
Each small enough to test with real customers before the next. Release 2 tried drag and drop; users found it too complicated, so release 3 swapped it for a plus sign. I designed all 10. I left after release 5, and the rest shipped with only small tweaks from testing.
Decisions
Four calls, what each replaced, and what it cost.
Two features in scope
instead of: The one in the brief
cost: A longer launch, with Workflows shipped in smaller chunks
The drawer from the design system
instead of: A pop-up next to the node
cost: A less spatial feel on the canvas
A plus sign to add a node
instead of: Drag and drop (release 2)
cost: Dropping a feature one release old
Ten small releases
instead of: One big launch
cost: A half-built canvas in production for a while
50+ enterprise customers adopted the builder in the first release cycle. IT personas had just become the target segment after a strategy shift, so the 60% was the number leadership watched. Teams that used to rebuild workflows by hand every quarter were spinning them up in minutes, and first-wave customers came back for a second workflow within a week.
From a blank page to a working workflow in under two minutes.
Reflection
The brief was one screen. Stepping back before committing is now the first thing I do on anything new, because on Sastrify that’s what caught the real problem. Shipping in 10 small releases meant customers got value from release 1 and we could test between each.
The fun part was the scope fight: one feature in the brief, two in the real problem. If you work on enterprise tools where the hard part is the logic underneath, I’d love to talk.
natalia.wlwsk@gmail.com →