Case study · an enterprise software maker
How a field-service software team stopped rebuilding the same pieces over and over
Nothing was replaced. The buttons, layouts, and forms every screen was built from were inventoried, unified into shared parts, and shipping got measurably faster.
The situation
Salesforce Field Service is what field-service businesses run on: a desktop tool for dispatchers, a mobile app for technicians. The mobile app ran on iPhone and Android, plus a third, web-based way of building screens was being introduced. Each platform team built screens from scratch, with no shared parts, so every feature meant rebuilding the same pieces: buttons, layouts, input fields. Building per platform is necessary; rebuilding those pieces every time is not. A handful of designers supported hundreds of engineers, too few to keep every screen consistent by hand. Slow and inconsistent, but nobody’s fault: the system had never been unified.
What we did
Discovered the shared system didn’t exist
It started with my assumption that turned out to be wrong: that an app this size ran on a shared system of parts. An audit said otherwise: the same button drawn slightly differently on every screen, details that should have been identical never quite matching, every screen was uniquely built. With the web-based screens on their way in, that cost was about to multiply.
Fixed two small things to prove the idea
No grand project was pitched. A unified set of type styles and one shared component, built with engineers in the gaps between feature work: proof that shared parts could hold up in the real app before anyone was asked to invest more.
Audited the whole system, together
A workshop series put twenty engineers, designers, and product leads in front of the app’s screens to lay out every element in use across all three ways of building and sort the duplicates, hands-on. You can’t unify what you haven’t counted, and a count everyone made together is a count everyone believes.
Planned the path, then built the foundations
A three-day planning workshop with the engineering team who would build it, went from how things worked, to an agreed picture of how they should, to real commitments for the next release. The numbers below come from the foundations built from that plan.
The result
66%
cut from development time for new screens
1,400 → 150
lines of code in one rebuilt area, smaller and far easier to work in
80+
unique screen elements standardized into shared parts
Features that had taken multiple development cycles began shipping in days. Not because anyone worked harder, but because nobody was rebuilding the same pieces anymore.
Why this is how Kuriri works
This is the same order Kuriri works in, at enterprise scale: find out how the system actually works, not how anyone assumes it does. Fix one small thing to prove the approach. Map the whole system with the people who run it. Then invest, with evidence instead of hope.
Systems before software.
What gets rebuilt from scratch every time in your business?
More case studies
A small product company
The busywork taken out of every order
Manual steps that scaled badly. A small tool, grown into a pipeline, absorbed peak season without a single new hire.
An Oʻahu neighborhood organization
The spreadsheet only one person understood, retired
The fix wasn’t custom software. It was choosing the right off-the-shelf tool and doing the unglamorous work of making it fit.
A global advertising business
A process no one could see whole, mapped
The whole process on a wall before anyone proposed a tool. The same move Kuriri makes with a local business, at enterprise scale.