DEV Community

Cover image for A follow-up tracker with four fields and no server
Tony Hui
Tony Hui

Posted on Originally published at taoapex.com

A follow-up tracker with four fields and no server

There is a failure mode that hits almost everyone who does work for other people, and it is not a technical one.

You finish the job, you send the invoice, and then the invoice disappears into a mental list you never wrote down. Three weeks later you remember it, and by then you are the one apologising for asking.

The usual fixes all fail for the same reason. A spreadsheet is never opened. A reminder app fires while you are in a meeting and gets dismissed. A Notion database is beautiful and costs three minutes of maintenance per item, so it is abandoned within a week. None of them are built around the actual object, which is not "a task" but "something another person owes you."

OweTrace is a small iOS app built on that premise. This post is about the design decisions, not the marketing, because the interesting part is what is deliberately absent.

The data model is intentionally boring

The core object is an Obligation. Four fields matter:

  • what - a short label, free text
  • kind - money, reply, document, or refund
  • dueAt - the date the other person said they would act by
  • nextNudgeAt - computed, never user-set

The last one is the only interesting decision. Users do not pick follow-up dates. The app derives them from a three-touch cadence: first nudge at two to four business days, second one a week later, third one a week after that, then a close-out.

Why compute rather than ask: any interface that makes a user pick a date produces one of two bad outcomes. Either the user picks "tomorrow" for everything, or the user picks nothing because the decision is a nuisance. Deriving it means the default is correct and the user only intervenes when a case is genuinely unusual.

No account, no sync, no server

This is the decision that looks wrong until you look at what is actually stored.

A follow-up tracker is exactly the kind of thing people want on both a phone and a laptop. But every sync story needs an account, and every account is a thing that can be breached, a password someone forgets, and a server somebody has to keep running and paying for.

The stored data is a list of what other people owe you. It is personal, it is not high-value, and it changes rarely. Local-only storage with a JSON export covers the real use case and removes an entire class of failure.

The tradeoff is real and worth stating plainly: no sync means losing the phone means losing the list, unless you exported. There is an export. Most people will not use it. For a first version that is still the right call, because the alternative cost is having no users at all while waiting for a backend to justify itself.

The reminder problem is a scheduling problem

iOS notifications look simple and are not.

A follow-up tracker has a specific shape: few items, each with few future trigger dates, all fully known at creation time. That maps cleanly onto UNCalendarNotificationTrigger, which the system schedules ahead of time. No push notifications, no background refresh budget, no server deciding when to wake the app.

What is needed instead is correct rescheduling when an item changes. If a nudge is marked sent, the next two triggers have to move forward by exactly one step of the cadence, not by a fixed interval from today. Getting this wrong produces a tracker that nags twice in one day and then goes silent for a month, which is worse than having no tracker at all.

The whole scheduling module is a pure function from [Obligation] to [NotificationRequest]. It is about a hundred lines, it has no side effects, and it is the part worth writing tests for first. Everything else in the app is presentation.

What this shape of problem teaches

  1. Derive schedules, do not ask for them. A default that is right 80% of the time beats a picker that is right 100% of the time and used 20% of the time.
  2. Make state exportable before making it syncable. Export is a day of work. Sync is a quarter.
  3. Model the cadence, not the reminder. "Three touches then close out" survives a change in notification API; "schedule a notification for day 3" does not.
  4. Do not build a social feature. A list of what people owe you is embarrassing information. Nobody wants to share it.

The app is free to start, with a Pro tier that unlocks unlimited active items. The longer write-up on follow-up timing, including the message templates, lives here:
https://taoapex.com/en/guides/general/how-long-to-wait-before-following-up/?utm_source=devto&utm_medium=social&utm_campaign=owetrace-followup-cadence&utm_content=article-01

Disclosure: OweTrace is built by TAOAPEX LTD, which also publishes that guide.

Top comments (0)