Internal platforms
Planning, service, coordination and decision support shaped around the way teams actually operate.
Explore internal platformsWork · Operational software
Most of the products I build live inside private organisations. They coordinate people, information and decisions — so these case studies focus on the problem, the product choices and the outcome.
What I usually build
The common thread is operational complexity: software used repeatedly by teams who need clarity, reliability and room for the business to evolve.
Planning, service, coordination and decision support shaped around the way teams actually operate.
Explore internal platformsDense, high-frequency workflows designed to stay understandable under real daily pressure.
Explore operational softwareClassification, retrieval and decision support added where they create concrete product value.
Case study hub
Each case is available as a standalone page with context, problem framing, responsibility, delivery focus and outcome.
A custom internal suite unifying planning, call handling, service interventions, notifications, and shared operational data for a 20-person company.
Read full case studyA field-oriented order entry product combining structured order capture, real-time product and pricing data, and integrated sales support for a nationwide sales force.
Read full case studyA recurring pattern in my work: improving mature internal systems while preserving the business logic and operational trust teams already depend on.
Read full case studyExplore the details
Select a case to read its essential structure here, or open the full standalone page.
Confidential Case Study 01
A custom internal suite unifying planning, call handling, service interventions, notifications, and shared operational data for a 20-person company.
A growing company needed a central environment where multiple departments could coordinate planning, support activity, and service work without relying on fragmented tools or disconnected processes.
Planning, phone activity, and assistance workflows were distributed across separate habits and tools. The result was low visibility, weak auditability, and friction between departments that needed to act on the same information.
The suite became a shared operational layer for the company: tailored to the way the business actually worked, flexible enough to evolve continuously, and stable enough to support daily coordination across teams.
Confidential Case Study 02
A field-oriented order entry product combining structured order capture, real-time product and pricing data, and integrated sales support for a nationwide sales force.
A commercial organization with agents operating across the country needed a tool that could support real sales activity in the field while keeping data aligned with headquarters.
The challenge was not just collecting orders. The system had to support the sales conversation, work well on tablets, present rich product information, and maintain a structured, always-updated flow of data between agents and central operations.
The final product made ordering more reliable and structured while also functioning as a practical sales-support environment, helping agents work with current information instead of disconnected materials.
Working Pattern 03
A recurring pattern in my work: improving mature internal systems while preserving the business logic and operational trust teams already depend on.
Many of the systems I work on are not greenfield products. They are existing operational tools that grew around real work, often becoming harder to use and harder to evolve over time.
The challenge is not simply redesigning the interface. It is reducing workflow debt, clarifying dense interactions, and making change possible without disrupting the teams who rely on the system every day.
This kind of work usually leads to the same result: clearer interfaces, faster execution inside complex flows, and software that becomes easier to maintain and extend without losing the trust of the people using it.
Skills in context
The value is not in treating these as separate services, but in making them support the same operational outcome.
Map real operational behaviour before changing screens or features.
Design repeated, information-dense work to remain legible.
Build the product itself, not only specifications or visual direction.
Extend existing platforms in useful, grounded and coherent ways.
Your context
Tell me what your team is doing today, where the current tools fall short and what you need to improve.