Building Software People Actually Use
A practical look at improving a live internal platform by making it faster, clearer, and easier for the people who use it every day.
ILLUSTRATIVE WORKFLOW MODEL · ANONYMISED · INTERNAL PLATFORM
0103
In plain English
This project was about improving internal software that people already relied on every day. Instead of rebuilding the system from scratch, the work focused on making key workflows faster, clearer, and easier to use so the platform could better support daily business operations.
Business value
- Helped users complete their work with fewer delays and less confusion.
- Made important information easier to find and act on.
- Improved performance and usability gradually, without taking the system down.
- Reduced repeated manual checking so teams could focus on actual work.
- Made the platform easier to adopt for non-technical users.
Anonymised workflow improvement map
A simplified visual showing how repeated workflows, platform signals, and action queues were made easier to understand without exposing real screens, users, or business data.
- Role
- Product Engineering / Full Stack Improvements
- Design · Build · Ship
- Timeframe
- 2025 – Present
- Domain
- Business Software / Internal Operations
- Category
- Internal Tools
- Improved key workflows so users could move faster through daily tasks.
- Reduced manual checking by making important signals easier to see.
- Made the platform easier to understand for non-technical users.
- Improved the live system in layers without forcing a full rebuild.
- Improved key workflows so users could move faster through daily tasks.
- Reduced manual checking by making important signals easier to see.
- Made the platform easier to understand for non-technical users.
- Improved the live system in layers without forcing a full rebuild.
The Context
I worked on a live internal platform that people relied on every day to handle business operations, track activity, and move work forward across different teams.
The system was already valuable. It had real users, real data, and real business dependency behind it. But like many internal tools that grow over time, the platform started carrying more screens, more rules, more edge cases, and more daily pressure than it was originally designed to support.
The platform supported a busy operations environment where multiple teams depended on the same system for day-to-day work. Because the tool was already part of the business routine, every improvement had to be practical, safe, and easy to adopt without exposing real customer data or interrupting active work in progress.
The challenge was not simply to add more features. The goal was to make the software easier to use, faster to move through, and clearer for the people depending on it daily.
This meant improving the system in a way that respected the live business: no dramatic rebuild, no unnecessary disruption, and no redesign that looked good in theory but made real users slower in practice.
Over the years, different teams had added their own workflows, shortcuts, and exceptions to the system. What started as a clean tool had quietly become a layered one. Nothing was broken, but the friction was real and it compounded with every new screen, every new rule, and every new dependency the business added on top.
When Working Software Stops Feeling Useful
The platform technically worked, but working software is not always useful software.
Users could complete their tasks, but some workflows required too many clicks, too many manual checks, or too much interpretation. Important information existed inside the system, but it was not always easy to find, understand, or act on quickly.
For developers, the problem showed up as performance bottlenecks, heavy data loading, repeated logic, and screens that had grown more complex over time.
For business owners, the problem showed up differently: slower operations, less visibility, more dependency on manual follow-ups, and harder questions about what needed attention first.
For users, the problem was simple: the tool sometimes made daily work feel heavier than it needed to be.
The challenge was to improve speed, clarity, and usability without breaking the workflows people already trusted.
Working software is not always useful software.
Ownership
Everything I designed, built, and was accountable for.
Product & UX
- Reviewed repeated user workflows and identified where the system created friction
- Reduced unnecessary manual checking across common internal workflows
Engineering
- Improved backend data loading and API responses for key daily screens
- Refined frontend views to make important information easier to scan and act on
Operations
- Worked with stakeholder feedback to prioritise changes that helped real daily operations
Additional scope
- Improved performance on areas users interacted with frequently
- Kept improvements layered and safe so the live platform could continue running
- Balanced technical cleanup with practical usability improvements for non-technical users
Key decisions
The calls I made, what I rejected, and why: these are the tradeoffs that shaped the system.
Improve the live platform in layers instead of doing a full rebuild.
A big rewrite that would interrupt daily operations and force users to relearn the system all at once.
The platform was already supporting real work, so the safer path was to improve the most painful areas gradually. This kept the system stable while still making daily use faster, clearer, and less frustrating.
The Approach
I approached the work in layers because a live internal platform cannot be treated like a blank canvas.
First, I focused on the workflows people repeated most often. These were the areas where small improvements could create the biggest day-to-day impact: faster loading, clearer screens, better defaults, simpler actions, and less unnecessary noise.
On the backend, the work focused on making data retrieval more efficient and predictable. That meant reviewing API responses, reducing unnecessary data loading, improving query behaviour, and making sure the system returned only what the interface actually needed instead of pushing too much information everywhere.
On the frontend, the focus was usability. I looked at how users moved through the system, where they paused, where they had to guess, and where the interface could guide them better. The goal was to make important information easier to scan, and common actions easier to complete.
The guiding idea was simple: internal software should not just store data. It should help people understand what is happening, what matters, and what needs action next.
The best internal tools do not make people think harder. They make the next useful action easier to see.
0104
feedback · observe · improve · repeat
Frontend
Backend
Database
Infrastructure
Also used
What Improved
- Faster workflows
- Clearer daily use
- Reduced friction
- No full rebuild
- More usable platform
The platform became faster, clearer, and easier to use in daily operations.
Users could move through important workflows with less friction, understand key signals more quickly, and rely on the system with more confidence.
The improvements were delivered in layers while the platform remained live, avoiding the disruption of a full rebuild.
Key workflows became noticeably faster, clearer, and easier to use across daily internal operations.
0105
Improved daily flow
Less repeated effort
Lower screen friction
Faster user decisions
Higher user confidence
The improvements helped the platform feel more practical for daily work, not just technically functional. Daily tasks felt lighter and more predictable, while the business avoided the cost and disruption of a full rebuild. By improving speed, clarity, and operational signals in smaller layers, the system became easier to trust and easier to keep using under real business pressure.
“Rusty understands the difference between adding features and making software actually usable. He looks at how people work, finds the friction, and improves the system in a way that makes daily operations feel smoother.”
Operations Stakeholder
Internal Platform Team — name under NDA
What I Learned
This project reinforced one of the biggest lessons I have learned from working on internal systems: software does not become valuable just because it has features.
A tool can have the right modules, the right database, the right permissions, and the right technical structure, but if users have to fight the workflow every day, the system still creates friction.
Useful software usually lives in the small details. A faster page. A clearer status. A better default. A button placed where users actually need it. A dashboard that shows the next useful signal instead of another wall of data.
Those improvements may not look flashy in a demo, but they are the ones people feel every day.
That is the kind of software I care about building: systems that are technically reliable, understandable for business owners, and practical enough for real users to keep using after launch.
The goal was not to make the platform look new. It was to make the work inside it feel lighter.
Useful beats flashy.
8+
3
5+
10+
Need software people actually use?
I help businesses improve internal tools, dashboards, workflows, and platforms so teams can move faster without fighting the system.
Start a Project