Objection Map

Overview

Every product decision creates objections. The goal isn’t to eliminate objections—it’s to have honest, tradeoff-aware responses that help the right users understand why these decisions make sense.

This map documents the most common objections and provides talk tracks grounded in Daylight’s actual architecture.

Objection 1: “What about sync conflicts?”

The Concern

“If I edit a task on my phone while my laptop is offline, won’t I lose data when they sync?”

The Reality

Conflicts can happen with any file-based sync. Syncthing doesn’t silently merge—it creates conflict files so you can see exactly what happened and choose which version to keep.

This is more honest than cloud apps that silently merge and occasionally lose data without telling you.

Talk Track

“Sync conflicts are a reality of multi-device editing—any system has them, most just hide them. Syncthing creates a conflict file when it can’t auto-merge, so you always know what happened. You’ll see a duplicate task, compare them, keep the right one, delete the conflict. It’s a 30-second fix instead of mysterious data loss.”

Supporting Points

• Conflict files are visible, not hidden
• Both versions are preserved—you choose
• Best practice: let Syncthing finish before editing on another device
• Most users rarely see conflicts with normal usage patterns

Link to docs

Sync & Conflicts — Full conflict resolution guide

Objection 2: “No built-in timers?”

The Concern

“I track time with timers. Start when I begin, stop when I’m done. How can manual entry be better?”

The Reality

Timers assume uninterrupted work. In reality:

• You get interrupted and forget to stop the timer
• You start a timer, get pulled into something else, come back hours later
• Timer state needs to persist across app restarts, device switches, and sync

Manual entry at the end of a work session captures what actually happened, not what you intended.

Talk Track

“Timers track intention. Manual entry tracks reality. Most knowledge work gets interrupted—you meant to work for an hour, you actually worked for 40 minutes across three sessions with two interruptions. At the end of the day, you know how much you actually worked better than a timer does. Enter it then.”

Supporting Points

• 15-minute rounding makes entry fast
• No timer state to manage across sync
• No “forgot to stop the timer” problems
• Pairs well with calendar overlay—see what you did, log time accordingly

Link to docs

Limitations — Why manual entry

Objection 3: “Read-only calendar seems limiting”

The Concern

“Why can’t I create calendar events from Daylight? I want my tasks and events in one place.”

The Reality

Tasks and calendar events are different data types with different needs:

• Tasks have flexible scheduling (“sometime this week”)
• Events have fixed times (“3pm Tuesday”)

Letting you create events from Daylight would require OAuth integration, token management, and create ambiguity about which system is authoritative. Read-only overlays give you schedule context without the complexity.

Talk Track

“Daylight shows your calendar so you can plan around it—not to replace it. Your calendar app handles events well. Daylight handles tasks well. The overlay gives you context: ‘I have meetings until 3pm, so I’ll schedule this task for after.’ But the calendar event lives in Google Calendar where it belongs.”

Supporting Points

• See your schedule while planning tasks
• No OAuth complexity or token management
• Clear data ownership: events stay in calendar, tasks stay in Daylight
• Google Calendar and ICS feeds supported

Link to docs

Limitations — Why read-only

Objection 4: “Android permissions look excessive”

The Concern

“Why does this app need ‘All files access’? That sounds like it can read everything on my phone.”

The Reality

On Android 11+, apps can’t access files outside their own folder without the MANAGE_EXTERNAL_STORAGE permission. Daylight needs this to read your Syncthing folder—which lives outside Daylight’s app directory.

The permission name sounds scary, but the alternative is that Daylight can’t access your existing Syncthing setup.

Talk Track

“Android changed how apps access files in version 11. To read your Syncthing folder, Daylight needs the ‘All files access’ permission. We’re not reading your photos or downloads—we only access the folder you explicitly point us to. The permission exists because Android doesn’t have a ‘this specific folder only’ option. Check our code if you want—it’s open source.”

Supporting Points

• Required for Syncthing folder access on Android 11+
• Only accesses the folder you configure
• Open source—verify what it does
• Android limitation, not Daylight design choice

Link to docs

Getting Started — Android setup with permission explanation

Objection 5: “Will this scale to thousands of tasks?”

The Concern

“I have years of tasks. Can Daylight handle 5,000+ items?”

The Reality

Daylight works well up to ~10,000 tasks. Beyond that, file-per-task architecture becomes slow because:

• All tasks load on startup
• Each task is a separate file system operation
• YAML parsing has overhead at scale

This is a deliberate tradeoff: file-per-task gives portability and transparency, but has a scale ceiling.

Talk Track

“Daylight handles thousands of tasks fine—I use it with several thousand. Around 10,000 you’ll notice slower startup. The architecture trades scale ceiling for data ownership: your tasks are files, not database rows. For most personal task management, this is the right tradeoff. If you’re managing 50,000 tasks, you need a different tool—but you probably also need a different workflow.”

Supporting Points

• ~10,000 practical limit for smooth performance
• Archive completed tasks to manage scale
• File-per-task is the portability tradeoff
• Most users never hit this ceiling

Link to docs

Limitations — Scale boundaries explained

Objection 6: “Why no natural language dates?”

The Concern

“I want to type ‘tomorrow’ or ‘next Friday’ instead of picking dates.”

The Reality

Natural language date parsing is ambiguous:

• Does “next Friday” mean this coming Friday or the Friday after?
• Does “weekly” mean every 7 days or same day each week?
• How does “in 2 weeks” work across month boundaries?

Explicit dates take a few extra seconds but eliminate ambiguity. The recurrence editor shows exactly what pattern you’re creating.

Talk Track

“Natural language sounds convenient until ‘next Friday’ creates a task for the wrong Friday. Explicit dates take an extra tap, but you know exactly what you’re getting. For recurrence, the editor shows ‘Every Tuesday’ clearly instead of hoping ‘weekly on Tuesdays’ parses correctly.”

Supporting Points

• Date picker is fast and unambiguous
• Recurrence editor previews the pattern
• i18n would complicate NLP significantly
• Ambiguity causes more problems than typing saves

Link to docs

Limitations — Why explicit dates

Quick Reference Table

When to Walk Away

Some objections indicate Daylight isn’t the right fit:

Daylight is for users who value data ownership enough to accept the tradeoffs. Not every user should be a Daylight user.