Mijn Fonky 2.0

Fonky is a field sales agency in the Netherlands, and Mijn Fonky is their internal operations platform, the thing every employee uses every day. MF2 is the second version: a fully custom redesign and rebuild, replacing an outdated system that had accumulated years of workarounds and frustration. I've been the designer and frontend developer on it since 2022, working as a consultant with the product owner, backend developer, and lead developer.

The scope is everything: 13 modules across the full employee lifecycle, lead management, shift planning, order processing, contract management, onboarding, user accounts, finance, and more. The kind of application where the edge cases never stop and the users have strong opinions because they're in it all day.

My process for each module: early research, gathering flow requirements with the product owner, refining those flows, building mockups, iterating to high-fidelity screens, then implementing in the frontend myself. Stakeholder feedback, demos, and decision-making all came through direct client contact, which kept things lean without a layer of translation in between.

What made this work cleanly at scale was syncing Tailwind's color tokens directly into Figma. Every color in the design file maps exactly to a Tailwind class in the frontend, no drift between mockup and implementation. By the time a screen is high-fidelity in Figma, I already know exactly how it will look in the browser.

Leads & recruitment

The recruitment pipeline was one of the first major modules, managing the full funnel from lead to hired employee. Both a list view for filtering and sorting and a kanban card view for status tracking across funnel stages.

Shift planning

Shift planning was the most complex module to design, and the one I spent the most time on early in the project. Multiple iterations before landing on something that handled data density without becoming unreadable.

Data-heavy screens needed a different approach. The dashboard surfaces KPIs and charts for management, so hierarchy and scannability mattered more than feature density.

Onboarding module

More recently, I designed and built the onboarding module end-to-end. New field sales recruits go through a structured multi-shift program before being fully placed; each shift is evaluated by their coach against configurable targets, with a final evaluation at the end.

That covered data models, event-driven evaluation creation, auto-saving evaluation forms, an extend/approve/decline state machine, and a two-pane management dashboard for coordinators to track all active onboarding processes at a glance.

The coach side was its own design problem. Before starting a shift with a rookie, coaches needed quick context on how far along the recruit was, their previous scores, the targets for this shift, without interrupting their flow. I added a pre-shift context step to the existing shift start flow that surfaces exactly this, pulling from the live evaluation data.

The planning grid also needed to surface onboarding status to coordinators at a glance: an amber badge on any user with an active onboarding process, wired through the PHP resource layer to the TypeScript types in the frontend.

Task module

Also more recent: a task system that connects to any model in the platform, a shift evaluation that needs reviewing, a contract pending approval, anything that requires action. I wired the dashboard task widget and the topbar notification panel to live shared data, and added conditional visibility so both components disappear cleanly when there's nothing pending.

Three years on the same product teaches you things a short project can't. The biggest shift: now that the design system is in place and the application is fully componentized, I do a lot of new feature work directly in the frontend. Instead of going back to Figma for every new screen, I design in real context using the existing component library as building blocks. It's faster, more honest about what's possible, and the output is production-ready from the start.