DEV Community: Dopami

Devlog: Performance Optimization Lessons from ADHD App Beta Testing

Dopami — Wed, 17 Jun 2026 08:16:35 +0000

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

Devlog: Building Bulk Task Assignment for an ADHD Chore App

Dopami — Tue, 16 Jun 2026 18:56:52 +0000

TL;DR: Users had to assign chores one-by-one, which is exhausting with ADHD. I added bulk selection + a single batch endpoint. Key decision: batch API over client-side loop for atomic UX and clean error handling.

The Problem

Before this feature, assigning tasks in Dopami required opening each task individually. For a household with 20 weekly chores, that's 20 taps just to distribute work. For users with ADHD, that repetitive loop is more than annoying — it's a pattern that kills motivation mid-task.

Most apps treat this as acceptable. It isn't.

UX Design: Tap-to-Select with a Sticky Footer

The interaction model is simple: tap a task to toggle it in/out of the selection. A sticky footer appears as soon as the first item is selected, showing the count and an "Assign" button. No long-press mode, no modal to open first.

// BulkAssignScreen.tsx
const [selected, setSelected] = useState<Set<number>>(new Set())

const toggle = (taskId: number) => {
  setSelected((current) => {
    const next = new Set(current)
    if (next.has(taskId)) next.delete(taskId)
    else next.add(taskId)
    return next
  })
  void Haptics.selectionAsync()
}

Each tap also fires a haptic (selectionAsync) — a small but meaningful signal that the tap registered.

The footer only mounts when selected.size > 0:

{selected.size > 0 ? (
  <View style={styles.footer}>
    <Text style={styles.footerMeta}>{t('bulkAssign.selectedCount', { count: selected.size })}</Text>
    <Button
      label={t('bulkAssign.assignAction')}
      onPress={pickAssignee}
      loading={assignMutation.isPending}
      style={styles.footerButton}
    />
  </View>
) : null}

No hidden menus. No multi-step confirmation. The count lives in the footer so you always know the selection state without reading individual cards.

Assignee Picker: Native Alert

Clicking "Assign" opens a native Alert listing the household members plus a "Nobody" option (to unassign):

const pickAssignee = () => {
  Alert.alert(t('bulkAssign.assignTo'), undefined, [
    ...members.map((member) => ({
      text: member.username,
      onPress: () => assignMutation.mutate(member.userId),
    })),
    { text: t('bulkAssign.nobody'), onPress: () => assignMutation.mutate(null) },
    { text: t('common.cancel'), style: 'cancel' as const },
  ])
}

userId: null means "unassign" — the same endpoint handles both operations.

Implementation: Batch Endpoint vs. Client Loop

Option A — Client-side loop (simpler, rejected)

// N requests, N points of failure, visible one-by-one update
const assignAll = async (taskIds: number[], userId: number | null) => {
  for (const id of taskIds) {
    await houseService.assignTask(id, userId)
  }
}

Problems:

N network requests = N points of failure
UI updates trickle in one-by-one → ripple effect (bad for perceived speed)
Partial failure is ambiguous and hard to recover from

Option B — Single batch endpoint (chosen)

// taskService.ts
assignBulk(taskIds: number[], userId: number | null): Promise<{ assigned: number }> {
  return api.post<{ assigned: number }>('/api/tasks/assign-bulk', { taskIds, userId })
    .then((r) => r.data)
},

houseService exposes it directly as a facade over taskService:

// houseService.ts
assignBulk: taskService.assignBulk.bind(taskService),

The mutation in the screen:

const assignMutation = useMutation({
  mutationFn: (userId: number | null) =>
    houseService.assignBulk([...selected], userId),
  onSuccess: async (result) => {
    await Promise.allSettled([
      queryClient.invalidateQueries({ queryKey: QUERY_KEYS.allRooms() }),
      queryClient.invalidateQueries({ queryKey: QUERY_KEYS.activeRooms() }),
      queryClient.invalidateQueries({ queryKey: QUERY_KEYS.assignedTasks() }),
    ])
    void Haptics.notificationAsync(Haptics.NotificationFeedbackType.Success)
    showToast(t('bulkAssign.success', { count: result.assigned }), 'success')
    router.back()
  },
  onError: () => showToast(t('bulkAssign.error'), 'error'),
})

Three query keys are invalidated in parallel (Promise.allSettled) so every list that shows tasks refreshes at once. Success fires a NotificationFeedbackType.Success haptic — a heavier, more satisfying pulse than the selection tick.

Backend: One UPDATE, Scoped to the Household

The request model is minimal:

// AssignBulkRequest.cs
public class AssignBulkRequest
{
    public List<int> TaskIds { get; set; } = [];
    public int? UserId { get; set; }  // null = unassign
}

The controller delegates straight to the service:

// HouseController.cs
[HttpPost("tasks/assign-bulk")]
public async Task<ActionResult> AssignTasksBulk([FromBody] AssignBulkRequest request)
{
    var assigned = await taskService.AssignUsersBulkAsync(
        request.TaskIds, GetCurrentUserHomeId(), request.UserId);
    return assigned is null
        ? BadRequest(new { detail = "Utilisateur invalide." })
        : Ok(new { assigned = assigned.Value });
}

GetCurrentUserHomeId() comes from the JWT — the client never sends a homeId, so a user can only modify tasks in their own household.

The service runs it as a single EF Core ExecuteUpdateAsync:

// TaskService.cs
public async Task<int?> AssignUsersBulkAsync(
    IReadOnlyCollection<int> taskIds, int homeId, int? userId)
{
    var ids = taskIds.Distinct().ToList();
    if (ids.Count == 0) return 0;

    await using var context = await factory.CreateDbContextAsync();
    if (userId.HasValue
        && !await context.Users.AnyAsync(u => u.Id == userId.Value && u.HomeId == homeId))
        return null;  // user not in this household

    return await context.HouseTasks
        .Where(task => ids.Contains(task.Id) && task.Room.HomeId == homeId)
        .ExecuteUpdateAsync(s => s.SetProperty(t => t.UserAssignedId, userId));
}

Two things worth noting:

ExecuteUpdateAsync translates to a single UPDATE ... WHERE id IN (...) — no per-row round-trips, no change tracking overhead.
The homeId filter on task.Room.HomeId means passing arbitrary task IDs from another household silently does nothing. No explicit auth check needed beyond "is this your household?"

null return = the target user doesn't belong to this household. int return = how many rows were updated, echoed back to the client as { assigned: N }.

Why Atomicity Matters for ADHD UX

The dopamine loop in a chore app depends on a clear cause → effect: I did the action → I see the result. A ripple update (15 items changing one-by-one over 750ms) breaks that loop. It communicates "this is working through a queue" rather than "done."

A single batch operation gives you:

Instant visual confirmation (one spinner → success haptic → everything refreshes)
No partial state to reconcile
Clean error path: show one error toast, the selection is still intact, the user can retry

For neurotypical users this is a polish detail. For ADHD users it's the difference between a satisfying interaction and an anxious one.

Takeaway

If your app has any "do X to each item" flow, ask whether a batch operation serves the user better. The implementation cost is one endpoint and a single ExecuteUpdateAsync. The UX benefit — especially for users with executive dysfunction — is significant.

Try Dopami in beta → do-pami.com/beta

I’m building a gamified chore app for ADHD adults because todo lists don’t work for me

Dopami — Tue, 16 Jun 2026 13:29:51 +0000

I’m building a gamified chore app for ADHD adults because todo lists don’t work for me

Most chore apps assume the hard part is remembering the task.

For ADHD adults, the hard part is often starting.

The problem with classic chore apps

They show a long list.
They expect prioritization.
They make every task look equally urgent.

That creates friction instead of clarity.

What I’m trying to build

I’m building Dopami, a gamified ADHD chore app focused on:

short household missions
energy-based task suggestions
XP and progress
shared homes for couples, families and roommates
less decision fatigue

Why gamification helps

The goal is not to turn life into a game.

The goal is to reduce the activation cost:
“Pick one small mission, start, get feedback.”

What I learned so far

Duration matters more than category.
Energy level matters more than priority.
Visual progress helps more than guilt.
Shared homes need clarity, not pressure.

Current status

Dopami is currently in development/beta.

I’m documenting the process and testing what actually helps ADHD adults manage household chores without creating another overwhelming task manager.

Site: https://www.do-pami.com