Case Study
Building FLOW: one platform for Finance, Logistics, Operations & Workforce
Most small and mid-sized businesses run on four or five disconnected tools that don't talk to each other — a spreadsheet for finance, a separate HR file, a chat thread for logistics. FLOW is the product I build at PRDGM Mugen Trading Corp to collapse that into a single platform, and this is how it gets designed, shipped, and kept running.
Role
Full-Stack Developer
Timeline
Aug 2025 – Present
Company
PRDGM Mugen Trading
Process
Agile Scrum
The problem
Our clients operate across e-commerce, HR, day-to-day operations, and logistics. Before FLOW, each of those functions lived in its own place. That creates three concrete costs:
- 01 Re-keying. The same order, employee, or shipment gets typed into two or three systems, and the copies drift apart.
- 02 No single source of truth. When finance and operations disagree on a number, there is no system that settles it.
- 03 Every client is different. A logistics-heavy client and a retail client need genuinely different workflows, so a rigid off-the-shelf product gets abandoned within weeks.
What FLOW actually is
FLOW is an acronym for the four pillars it covers. Each is a module on a shared data layer, so a record created in one is immediately visible to the others.
F
Finance
Checkout and order flows, invoicing, and the transaction records that the rest of the platform reconciles against.
L
Logistics
Inventory and movement of goods — what exists, where it is, and what state it is in.
O
Operations
The day-to-day workflows that tie the other modules together, plus the dashboards management actually opens each morning.
W
Workforce
HRIS: employee records, attendance, and the role definitions that drive permissions across every other module.
Architecture & the decisions behind it
┌──────────────────────────────────────────────────┐
│ React front end · role-aware UI per module │
└───────────────────────┬──────────────────────────┘
│ REST (JSON)
┌───────────────────────▼──────────────────────────┐
│ Laravel API · controllers · services · auth │
├──────────────────────────────────────────────────┤
│ Eloquent models · shared domain layer │
└───────────────────────┬──────────────────────────┘
│
┌───────────────────────▼──────────────────────────┐
│ MySQL · one schema, four module boundaries │
└──────────────────────────────────────────────────┘
One database, not four services
The whole point of FLOW is that finance and workforce data agree with each other. Splitting the modules into separate services would have meant syncing them, which reintroduces exactly the drift the product exists to eliminate. A single relational schema with clear module boundaries gives us referential integrity for free. The trade-off is that the modules deploy together — acceptable at our scale, and revisitable later.
Laravel for the domain, React for the surface
Business rules — who may approve what, how a transaction settles — live in Laravel services, never in the client. The React layer stays a rendering and interaction concern talking to a REST API. That split means a rule changes in exactly one place, and it keeps the rules enforceable rather than merely displayed.
Roles as the configuration layer
Because every client needs a slightly different workflow, per-client customisation is expressed through roles and permissions defined in the Workforce module rather than through forked code. One codebase serves clients with genuinely different operating models, which is what makes the product maintainable as the client list grows.
Shipping and keeping it up
I own the platform end to end, which includes everything after the code is written. FLOW runs on a Cloudways enterprise server that I provisioned and maintain.
Staging → production
Work lands on a staging environment that mirrors production, gets checked against the phase's acceptance criteria, and only then gets promoted. Clients see changes on staging before they are live.
GitHub-triggered builds
Pushes to the main and dev branches trigger deployments via webhooks, so releases are repeatable rather than a manual sequence someone has to remember correctly at 6pm.
SSL & domains
Certificate issuance and renewal, DNS, and domain mapping for each client deployment.
Post-deployment monitoring
Watching the live site after each release, because the release is not finished when the build goes green — it is finished when the client's Monday morning works.
How the work runs
We work in Agile Scrum, shipping enhancements each phase. The part I find most valuable is that I also do the client support for what I build: I run onboarding walkthroughs, take the bug reports directly, and ship the fixes.
That closes a loop most developers never get to close. When you are the person who explains your own interface to the user who has to live in it every day, you find out within a week which of your design decisions were actually good ones. A surprising amount of what I have changed in FLOW came out of a support call rather than a planning session.
Where it stands
- ▸ All four modules are live and in daily use, on a single shared schema.
- ▸ Releases go out each phase through a repeatable staging-to-production pipeline rather than ad-hoc manual deploys.
- ▸ New client requirements are absorbed through role and permission configuration instead of forking the codebase.
- ▸ Customer-facing landing pages ship alongside the platform to support client acquisition.
What I'd do differently
Define the module boundaries in writing on day one
A shared schema is only a strength while the boundaries between modules are explicit. We arrived at clear ones, but I would rather have written them down before the first migration than discovered them through a refactor.
Automated tests around the money paths, earlier
Manual QA catches interface problems well. It is a weaker guarantee for the finance logic, where a regression is expensive and silent. That is the first place I would add coverage.
Instrument before you need it
Monitoring added after a problem tells you the problem is happening. Monitoring added beforehand tells you what changed. Worth the setup cost up front.
Want something like this built?
I build full-stack platforms end to end — architecture, implementation, deployment, and the support that keeps them running.