LemonlessTMS case study
What building custom software actually looks like
LemonlessTMS is task-management software I built as part of The Lemonade Economy. It handles work at different levels, scheduling, support between users, completed-work momentum, calendar views, history, and local profiles.
During release preparation, I tested the software through ordinary exploratory use, larger workspaces, and a designed multi-user journey through the desktop application. This identified issues ranging from straightforward interaction problems to deeper questions about hierarchy, support, data relationships, cognitive load, and how features behave together.
The resulting changes are a useful example of the work that happens around the code itself.
Reusing context the software already has
- Problem
- Selecting “Create child item” from an existing work item opened the creation form without automatically selecting that item as the parent.
- Result
- The selected item now carries forward automatically as the intended parent.
Reasoning: The user had already provided that context by choosing the action.
- Heaviness is entered once and reused by downstream systems.
- Timezone setup uses a searchable selector rather than requiring an exact timezone string.
- Completing linked support work automatically resolves the corresponding support request instead of asking the original user to confirm the same event again.
These are small changes individually, but they reduce the amount of information and system state the user has to manage themselves.
Treating hierarchy as guidance where possible
Lemonless organizes work using:
Big-picture goal → Project → Task → Subtask → Tiny Nudge
The original implementation enforced this as a rigid hierarchy. That prevented arrangements outside the expected structure even when they were technically coherent and useful to the person creating them.
The hierarchy now provides guidance rather than enforcing a single way to organize work.
- Guidance / warning
- Unusual but structurally valid parent relationships.
- Hard invalid states
- Self-parenting
- Cycles
Parent selection is searchable, keyboard-accessible, contextual, and prioritizes recent items so the interaction remains usable as the workspace grows.
Modeling support as work
An early implementation treated a request for help primarily as metadata associated with the original work item. That didn't adequately represent what happens when another person becomes responsible for doing something.
A support request now creates linked work assigned to the support person, including context about what is being requested. Pending support is visible to the relevant user, and completing the linked work automatically resolves the original request.
Support rules
- Support tasks cannot recursively create another support request.
- Users cannot request support from themselves.
- Only the designated main user initiates the support workflow.
- Self-coordinated outside help becomes ordinary child work owned by the main user.
- Removing a support user requires pending support work to be reassigned or cancelled.
- Historical attribution is preserved.
Designing features around their relationships
Deleting a work item
Connected considerations
- Children
- Support relationships
- Calendar data
- Momentum consequences
- History
Deleting a parent leaves its children intact as independent work rather than silently destroying them. Linked relationships are handled explicitly, and historical information remains meaningful after the current item is gone.
- Completing support work → affects the originating request
- Removing a collaborator → affects assigned work
- Changing work state → affects history and Momentum
- Scheduling work → must remain coherent between the work item and Calendar
Testing those relationships matters because a feature can behave correctly in isolation while creating inconsistent state elsewhere in the application.
Matching the interface to the information
Calendar
- Before
- Scheduled work was presented only as a list.
- After
- Lemonless also provides a month grid so dates can be understood spatially. List and Month are grouped under a shared View control.
Child work
- Before
- Work-item detail had a separate Tiny Nudges section alongside the existing child-work section.
- After
- Child work is represented through one “Steps within this work” surface.
Momentum
- Problem
- Directly scaling the snowball with accumulated completed mass eventually overwhelms the interface.
- Result
- Numeric mass remains authoritative while the visual uses bounded, nonlinear scaling.
Large amounts of incoming work use a bounded visible set with navigation rather than stacking indefinitely.
Testing beyond the clean workspace
Work-item scales used during release-candidate testing
- 100+ work items
- 500 work items
- ~800 work items
Testing covered Kanban, Calendar, parent search, editing, support relationships, persistence, and backup.
Designed two-user journey
Tested together: local profiles, actor attribution, assignment, support requests, state changes, completion, and persistence.
Persistence validation
- Renderer reload
- Full Electron restart
Also tested: responsive behavior at narrower layouts, large individual Momentum completions, and large accumulated Momentum totals.
This complements isolated automated tests by checking whether the application's features continue to behave coherently when they are used together and under less convenient conditions.
Where Codex fits
Codex handled a substantial amount of LemonlessTMS implementation and assisted with testing. My role includes deciding what the software should represent, identifying friction and inconsistent behavior, tracing changes across connected features, and determining whether the resulting interaction still makes sense for the person using it.
Not every requirement can be specified correctly before implementation. Building the software makes assumptions visible and creates new information about how features interact. I use that information to revise the model and then use Codex to implement and test the next version.
For LemonlessTMS, that process changed interaction details, hierarchy rules, the support data model, deletion behavior, visual representations, multi-user behavior, and release validation.
That combination of systems analysis, interaction design, information architecture, contingency reasoning, implementation, and iterative testing is what I mean when I offer to build custom software.
Have a problem you want to discuss?
I build custom software around household, personal, workflow, and other specific problems. Let's talk about yours.
Or email me: fletcherdgaleano@gmail.com · fletcher@operationalentropy.com