TL;DR: The biggest performance and reliability work was not a fancy animation pass. It was fixing the task recommendation pipeline: removing non-translatable scoring logic from EF Core queries, sorting after real personalized scores are computed, making activity patterns accumulate correctly, syncing user timezones, and using due dates as a real urgency signal.
Why Performance Matters in an ADHD App
Dopami is a soft-gamified chore app built for ADHD users.
In this kind of app, performance is not just polish. If the app hesitates at the moment someone is ready to act, the motivation window can close. The goal is simple: when the user opens the app, the next useful task should appear quickly, feel relevant, and not require extra thinking.
During the beta-hardening phase, I found several issues in that exact path.
Fix 1: EF Core Crash in Personalized Task Scoring
Problem: some task-listing endpoints were trying to call the C# scoring service inside an EF Core LINQ projection.
That is a classic trap: EF Core can translate SQL expressions, but it cannot translate arbitrary C# service logic.
When that logic leaks into the query, the endpoint can crash at runtime because EF Core does not know how to turn it into SQL.
Fix: split the work into two phases.
- Let SQL do what SQL is good at: filtering, counting, includes, and coarse candidate ordering.
- Materialize the tasks.
- Map them to DTOs.
- Apply the personalized score in memory.
This fixed the runtime crash and made the scoring path explicit: database first, personalization second.
Fix 2: Correct Personalized Sorting Before Pagination
Problem: the assigned tasks endpoint was paginating too early.
That meant the app could fetch a page of tasks first, then score only that page. But for a recommendation system, this is wrong: the best task might be on page 2 or 3 before scoring.
Fix: load a bounded candidate set, score it in memory, then paginate after sorting by score.
This keeps the endpoint efficient while making the result much more relevant.
The SQL query still applies a cheap pre-sort based on urgency and impact.
Then the app applies the full personalized score with activity patterns, preferred reminder hours, day-of-week patterns, routine context, and due-date urgency.
Fix 3: Activity Patterns Were Not Reliable Enough
The recommendation system depends on knowing when a user usually completes tasks.
Problem: the activity-pattern logic had edge cases that could prevent the user’s completion history from being used correctly. One issue was treating hour-based patterns like an array index instead of looking up the pattern by HourOfDay.
Fix: score the current local hour by looking up the matching pattern.
That made the score reflect the actual hour bucket instead of accidentally depending on list position.
I also fixed the completion recording path so existing patterns are incremented instead of losing useful history.
This matters because personalization only becomes useful if the app actually remembers behavior over time.
Fix 4: Timezone-Aware Scoring and Reminders
A task reminder system cannot use raw UTC hours and pretend that is the user’s day.
Problem: the backend had scoring logic based on local hour, but the user’s UTC offset was not fully wired through the profile/update flow.
Fix: add UtcOffsetHours to the user DTO, profile update model, backend update path, and mobile auth context.
On app startup, the mobile client now compares the device timezone offset with the saved user offset and silently syncs it when needed.
This makes “good time to suggest this task” much more meaningful.
A reminder at 9 AM should mean 9 AM for the user, not 9 AM for the server.
Fix 5: Due Dates Became a Real Priority Signal
Due dates were present in the data model, but the write path and mobile form were not fully wired.
Fix: connect due dates end to end:
- backend
TaskFormModel - task creation/update service
- mobile
TaskFormRequest - task composer state
- task cards and metadata labels
- scoring urgency
Now due dates affect both display and ranking. A task due soon can rise naturally in the list without needing a separate “panic mode” UI.
What This Changed
The main improvement was not one magic optimization. It was making the recommendation pipeline honest:
- SQL handles filtering and bounded candidate selection.
- C# handles personalized scoring after materialization.
- Pagination happens after scoring, not before.
- Activity history is recorded correctly.
- Local time is actually local.
- Due dates influence priority.
For an ADHD app, that matters because the home screen is not just a list. It is a decision-reduction tool.
The user should not have to scan 40 chores and negotiate with themselves. The app should be able to say: “start here.”
Beta still open → do-pami.com/beta
