SwiftWork • Product Development
An ERP that thinks, not just stores
Role
Builder
Timeline
June 2026
(5 days)
Team
Just me!
Skills
Product Design
Product Strategy
Product Management
Front-end Development
The Brief
I had five days to design and build two ERP modules.
I was assigned two modules to take from zero to one: People Management and Timekeeping & Payroll. The company behind it has 100 employees, 50 doctor consultants, and 20 branches nationwide, two very different kinds of workers under one roof. My job covered the whole product cycle, from strategy and branding all the way to a working prototype and documentation ready for handoff.
The Sprint
How do I even do this in five days?
The brief didn't come with a problem to solve. It just came with two modules to build, and the rest was up to me. So before anything else, I planned. I mapped out the five days around the deliverables, decided what needed to be done each day, and gave each day one clear job.
Day 1 was about planning a company that didn't exist.
SwiftCare is a fictional telehealth company I built in an earlier round, and this round asked for SwiftWork, the ERP behind it. Since it isn't real, I couldn't go looking for actual pain points. So I had two ways to approach this: design for companies still doing everything on paper, or build something better than the ERPs that already exist. I chose the second.
Days 2 and 3 were for finding what those ERPs were still getting wrong.
I went deep on both modules and studied the strongest ERPs, HR systems, and payroll platforms out there, then asked what they were still getting wrong. From there, I mapped out the main user journeys for each module, listed the features that would make it functional, and then the features that would actually solve the problem.
With the features clear, I started with the development-ready user stories and the technical documentation, since I already knew how the system needed to work and look. While doing that, I pulled screens from existing ERPs into Figma as references. The brand book came together quickly too, since it builds on the one I made for SwiftCare the week before. By the end of day 3, the strategy side was done.
Make it exist first, then make it better.
Day 4 was for building. By this point, only the interface and the pitch were left, so I scaffolded fast and deployed the front end early to get something real out as soon as possible. My development workflow was already set up, and since the design tokens came from the brand book and SwiftCare, I reused a lot of existing components and built new ones specific to an ERP. Most of my time went into figuring out how each screen should actually be laid out, cards or tables, short or detailed, whatever worked best.
Then on day 5, I told the story.
I put together the pitch deck and recorded the pitch.
The Problem
Most ERPs store data and call it a day.
Every ERP I looked at did the same thing: collect records, organize them into tables, and wait to be searched. The actual work still lived with HR, manually catching expiring licenses, odd payroll entries, and submissions that needed a second look. At 100 employees across 20 branches, the things nobody catches in time are exactly the things that turn into problems.
Discovery
The best tools still made people do the noticing.
Looking at the strongest ERPs out there, the pattern was always the same: clean, organized tables, but you still had to know what to look for. That was the gap. A system can hold everything and still notice nothing. So that became my direction, SwiftWork should surface what needs attention on its own, before anyone goes looking.
Solution
Every screen leads with what needs attention.
Every screen surfaces the things that used to hide in tables: licenses about to expire, payroll entries that look off, submissions stuck in review, a branch where sentiment is dipping. I designed both modules from the HR admin view, since that's who carries the most, then built the parts that prove the idea, an action items strip on every dashboard, a payroll dry run that flags discrepancies before any money moves, and a live attendance board that knows when a doctor is mid-consultation.
Reflection
Deciding fast is a skill, not a shortcut.
The biggest thing I took from this was how much being decisive matters. With five days, I couldn't wait around to gather every piece of data before making a call. I had to decide with what I had, as carefully as I could, then keep moving. That's the part of product management this project made real for me. Time is a resource too, and a good decision made now is often worth more than a perfect one made too late. Working in short, deliberate sprints like this taught me more about agile and the actual product cycle than any plan on paper could.
Turns out I like wearing every hat at once.
It also reminded me why I like working this way. Strategy, design, and code usually get split across different people, but having all three in my own head meant I could move from a decision to a built screen without anything getting lost in between. That's the kind of work I want to keep doing, the kind where I get to think it, design it, and build it.
Also check out...