WORK / WRITING / RESEARCH

Work, Writing & Research.

Ideas are easy to admire. Systems have to hold up. I created DMS, VMS, and OPSLASH, designed their architecture and core algorithms, and led the development teams that turned all three into completed software products. My work brings product vision, technical structure, and team leadership together to deliver complex systems.

02 / SELECTED WORK

From vision to completed products.

Three completed software products I created and led, along with related work in local AI, information systems, and interface design.

Completed products

DMS, VMS, and OPSLASH are three completed software products that I created, architected, and led through development.

DMS — Delivery Management System

Completed product

Delivery operations leave no room for blind spots. A route changes, a handoff is missed, or a status no longer matches reality, and someone still needs a reliable answer. I created DMS to connect orders, dispatch, routes, tracking, billing, and proof of delivery in one operating model. The goal was never another dashboard; it was a clear, accountable view of a business that is always in motion.

My role

I created DMS and defined its product vision, software architecture, code structure, and core operational algorithms. As product owner and project manager, I led the development teams that completed the product, keeping dispatch, handoffs, and accountability at the center of every technical decision.

Question How can a delivery operation remain visible, accountable, and responsive when the plan changes?

System design: DMS is built around orders, customer and location records, routing, scheduling, dispatch, tracking, pricing, billing, user roles, and proof of delivery. Its .NET/Avalonia desktop architecture connects these workflows through operational views. The See / Control / Prove model links visibility to action and traceability.
In practice: The .NET/Avalonia desktop codebase includes order entry, customer records, routes, dispatch, scheduling, monitoring, tracking, mapping, billing, and permission-based views.

VMS — Pet-care Operations System

Completed product

Good care depends on details that cannot be kept in separate notebooks. A booking becomes a stay, a room changes status, and a routine passes from one staff member to the next. I built VMS around that continuity, bringing occupancy, care tasks, shifts, and communication into one role-based operational model.

My role

I created VMS, defined its product vision, and designed its architecture, code structure, and core workflow algorithms. As product owner and project manager, I led the development teams that completed the product, bringing stays, rooms, care routines, and staff responsibilities together in one system.

Question How can a pet's stay, its care routines, and every staff handoff become one dependable operation?

System design: VMS connects reservations and stays with room availability, transfers, feeding and care routines, medication information, staff tasks, shift handoffs, customer updates, pricing, and role-specific views. It is designed for day-to-day care coordination, not for clinical diagnosis or treatment.
In practice: The VMS model links reservations, room availability, stays, care routines, shift handoffs, customer updates, and role-specific views.

OPSLASH SUITE — Desktop Operations Platform

Completed product

Connecting tools is the easy part. Making them work together without losing control is the real design challenge. I designed OPSLASH as a modular desktop platform that gives project knowledge, AI assistant workflows, and authorized computer actions one consistent structure. Context must be preserved, permissions must remain explicit, and every outcome must be traceable.

My role

I created OPSLASH and defined its product vision, modular architecture, code organization, and the core workflow algorithms that connect Workspace, Control, and external tools. As product owner and project manager, I led the development teams that completed the platform.

Question How can an intelligent desktop gain real capabilities without losing context, boundaries, or human control?

System design: An Electron desktop shell with shared core services and module contracts. Workspace organizes projects, files, search, and handoffs. Control provides scoped system operations through PC Commander, and declared commands, events, and services define how plugin modules communicate.
In practice: The Electron/React platform combines shared desktop services with Workspace and scoped Control tools. Both the Suite foundation and a separately installed Windows BASE-001 build have documented local runtime checks.

Related development work

Exploratory work in knowledge continuity, local AI, and consistent digital interfaces.

Nicktion Local Organizer

Files are easy to save and surprisingly easy to lose in plain sight. Local Organizer tests a simple discipline: every document should retain its source, its project context, and a safe next step. It runs locally and emphasizes traceability rather than assuming that automatic cleanup can make every decision.

Question What keeps a workspace usable after the person who organized it moves on?

System design: A local-first file and project manager with safeguarded search, source-linked extraction, owner review, and tightly scoped file operations.
In practice: Local modules handle safeguarded file operations and source-linked text extraction, helping each document retain its origin and project context.

Nicktion AI Workspace

More integrations do not automatically make an assistant more useful. Nicktion AI Workspace explores the connection between AI providers, tools, and people, with a focus on making every connection visible and every action appropriately scoped.

Question How can an AI workspace expand what people can do while keeping tool use visible and governed?

System design: A desktop AI workspace for testing assistant interactions, local provider connections, and scoped tool access.
In practice: Local builds cover assistant interactions, provider connections, packaged runtimes, and scoped tool access.

Nicktion Design System

A design system must hold up once it meets real code. This local React pilot tests reusable components, responsive behavior, and accessibility checks so design decisions carry over consistently from one screen to the next.

Question How can a visual language remain consistent across screens, states, and real-world use?

System design: Reusable visual patterns, component rules, React UI pilots, and responsive and accessibility testing.
In practice: The React pilot covers reusable patterns, responsive behavior, and automated accessibility tests across screen sizes.