DEV Community: Captio-Style Simple Memo

Todo debt: 32 field notes from a solo dev's notebook

Captio-Style Simple Memo — Fri, 29 May 2026 13:21:30 +0000

The capture friction matters more than the schema. Most of my "todo system overhauls" turned out to be schema redesigns, when the real bug was that adding a new task took eleven seconds instead of one.
Todo debt compounds the same way tech debt does, but I cannot see it in a profiler. Nobody writes a postmortem about a thing they did not do. There is no flame graph for items 311 through 480.
A todo from fourteen months ago is no longer a todo. It is a small piece of evidence that I once had different priorities. I have learned to treat it as data instead of as a guilty obligation.
The first 50 items in any list are mine. After 50, the list starts to belong to a former version of me, and the act of "processing" it is really an act of negotiating with a stranger.
I tried tagging todos by energy level — low_energy, deep_work, meeting_brain. I picked the wrong tag about seven times out of ten, and the act of picking ate the energy I was trying to budget.
A friend told me her trick: every Friday she archives any todo older than 90 days, unread. She has not regretted one archive in three years. I have copied this and the regret rate is the same for me.
The cost of a todo is not the time it takes to do it. The cost is the number of times I have to read it before I either do it or delete it. The "read tax" is the thing nobody charges for.
I once tracked re-reads with a counter. The top item in my list was read 41 times before I finally killed it. It said figure out RevenueCat. I never figured out RevenueCat, and the app shipped anyway.
There is a class of todo that exists only to make me feel like I am still planning to do the thing. Naming this class — I call them "alibi todos" — was the first thing that helped me kill any of them.
Most "Inbox Zero" advice does not survive contact with a backlog of 600+ items. The advice assumes you started clean. I never have. The bigger lie is that I will reach the starting line by next Sunday.
Things I will never todo-app again: birthday gifts, replying to friends, reading specific books. They go on a calendar, or they go in a person, or they go nowhere. A todo app turns out to be the wrong substrate for any of them.
The half-life of an "urgent" tag in my system is about eleven days. After eleven days, the tag means nothing. I have stopped using it and the number of actually-urgent items I miss has not measurably changed.
I rewrote my todo system four times before noticing that the cost of each rewrite, in lost todos, exceeded everything the new system was supposed to save. Migrations are the most expensive form of procrastination I have ever found.
A todo that lives across two devices and one syncing service is a todo that will eventually die alone in a conflict resolution dialog. The number of items I have lost to "newer version exists" prompts is, conservatively, in the dozens.
The most useful field I ever added to my todo schema was created_at. Not due_date. created_at, so I could see how long I had been lying to myself about an item. Most of my schemas before that quietly hid this fact.
Tech debt eventually crashes the build. Todo debt does not crash anything. That is the whole problem with it. There is no red light. There is only the slow, invisible compounding of attention you owe to your past self.
When I cleared 280 items in one session I felt nothing. When I cleared three items I had been postponing for months I felt lighter for a week. The relief is not linear in count; it is linear in shame.
A todo without a verb is a fragment of an idea. Most of mine are nouns: RevenueCat. Kani 2 update. bench taxes. These never get done because they were never decisions in the first place. They are categories pretending to be tasks.
The phrase quick win in a todo is a lie I tell myself to feel productive. I checked once: the median time-to-complete of items I had labeled quick win was 27 days. The label predicts the opposite of what it claims.
I once moved my entire backlog into a single .txt file and grep-searched it for verbs. About 60% of items contained no verb at all. The 40% that did contain a verb completed at roughly four times the rate of the 60% that did not.
The single trick that did the most for my real backlog was forwarding the task to my own email with a date in the subject line. Mail clients surface time better than todo apps do. A todo without a date next to it is invisible after seven days.
A reasonable answer to "should this be a todo" is "no, this should be a calendar event with a hard end". The hard end is what makes me say "good enough" and stop. Open-ended todos invite open-ended polish.
The number of open todos at the start of any month predicts the number of features I will not ship that month. It does not predict the number I will ship. The two metrics are uncoupled, which surprised me when I first plotted them.
Every time I added a child-task feature to my homegrown todo app, the average nesting depth of my tasks grew by half a level. Features train me as much as I configure them. A flat list is partly flat because the tool refuses to nest.
I keep two lists. One is for things I am doing this week. The other is for things I once told myself I should care about. The second list is where ideas go to be quietly disagreed with later.
The shortest-lived todo I have ever logged was open for four seconds. I typed it, captured it, and immediately remembered the answer was no. I keep a counter of these because they are the only honest thing in the system.
The longest-lived todo in my system right now is 893 days old. It reads: simpler. I have never had the heart to delete it and I have never been able to act on it. It exists as a kind of weather.
The number of distinct tools I have used to track todos in the last decade is twenty-one. The number of those tools that survived more than one calendar quarter in my workflow is two. The other nineteen each took a weekend to set up.
I keep a small done.txt. Every line is a thing I finished. The file is open in a tab I never close. The most reliable productivity intervention I have is rereading the last ten lines when I am about to call the day a loss.
Project todos are different from house todos are different from life todos, and putting them in the same list is the same category error as putting unit tests and dentist next to each other. I learned this slowly and at the cost of several dental appointments.
The verbs that actually pull items out of my backlog are these, in order of frequency: send, reply, delete, decide, cancel. decide is doing the most work and is in the smallest number of todos.
The honest end state for most todo lists is not "completed". It is "no longer relevant". I have stopped treating that ending as a failure. It is just how a list of things you considered doing eventually ends.

I write at @simple_memo. I ship Captio-style Simple Memo, an iOS note-to-email app I built for myself first.

An offline-first Outbox in Swift: 7 steps, no third-party libs

Captio-Style Simple Memo — Tue, 26 May 2026 13:27:59 +0000

Reproducing this in your own iOS project: seven steps.

I have been running this Outbox in my note-to-email app for ten months. It survives a four-floor subway descent, a phone reboot mid-send, and the occasional iCloud Drive hang. It is roughly 240 lines of Swift, with zero third-party packages.

Below is the recipe. I will write the code straight, the way it sits in my repo, and call out the failure modes I hit at each step. If you are building anything that needs to "send-and-forget" (analytics, message drafts, telemetry, optimistic UI mutations), most of this will transplant directly.

What an Outbox actually is

An Outbox is a durable queue that sits between your UI and the network. The UI hands it an Operation. The Outbox guarantees that Operation will be executed at least once, eventually, even if the user puts the phone in airplane mode, force-quits the app, and reopens it on a different cellular network six hours later.

A short list of requirements drove every decision I made:

The user's tap must feel instant. Network latency is the Outbox's problem, not the UI's.
A killed app, a rebooted phone, or a low-memory eviction must not lose work.
I do not want to ship 4 MB of dependencies for a feature this conceptually small.

Everything below follows from those three.

Step 1: Define a single envelope

Everything that enters the Outbox is wrapped in one envelope. Plain Codable struct, all the bookkeeping a retry loop needs, no payload coupling.

struct OutboxOperation: Codable, Identifiable {
    let id: UUID
    let kind: String          // "sendEmail", "uploadAnalytics", etc.
    let payload: Data         // opaque to the Outbox
    let createdAt: Date
    var attemptCount: Int     // mutates on retry
    var nextEligibleAt: Date  // backoff target
    var lastError: String?    // diagnostic only
}

I keep payload as opaque Data. The Outbox never deserialises it. Each registered OperationHandler knows how to decode its own payload type. This decoupling means I can add a new operation kind without touching the queue.

Failure I hit. My first version used a Swift enum with associated values for kind. It read beautifully and broke the first time I added a case in an app update. Every envelope written by the previous build failed to decode on launch, and I lost three hours of users' queued sends. A String kind plus opaque Data payload is uglier and forwards-compatible.

Step 2: Persist each operation as its own file

I store the queue as a directory of JSON files inside the app's Application Support folder.

final class OutboxStore {
    private let dir: URL
    private let encoder = JSONEncoder()
    private let decoder = JSONDecoder()
    private let lock = NSLock()

    init() throws {
        let base = try FileManager.default.url(
            for: .applicationSupportDirectory,
            in: .userDomainMask,
            appropriateFor: nil,
            create: true
        )
        dir = base.appendingPathComponent("Outbox", isDirectory: true)
        try FileManager.default.createDirectory(
            at: dir, withIntermediateDirectories: true
        )
    }

    func enqueue(_ op: OutboxOperation) throws {
        lock.lock(); defer { lock.unlock() }
        let url = dir.appendingPathComponent("\(op.id.uuidString).json")
        let data = try encoder.encode(op)
        try data.write(to: url, options: [.atomic])
    }

    func all() throws -> [OutboxOperation] {
        lock.lock(); defer { lock.unlock() }
        let urls = try FileManager.default.contentsOfDirectory(
            at: dir, includingPropertiesForKeys: nil
        )
        return urls.compactMap {
            try? decoder.decode(OutboxOperation.self,
                                from: Data(contentsOf: $0))
        }.sorted { $0.createdAt < $1.createdAt }
    }

    func remove(_ id: UUID) throws {
        lock.lock(); defer { lock.unlock() }
        try? FileManager.default.removeItem(
            at: dir.appendingPathComponent("\(id.uuidString).json")
        )
    }

    func update(_ op: OutboxOperation) throws {
        try enqueue(op) // same file path; atomic overwrite
    }
}

Why one file per operation, not one big queue file? Two reasons. The first is crash safety. An atomic write of a 1 KB envelope finishes in microseconds. An atomic rewrite of a 10 MB queue file is a much wider window for the OS to kill you mid-write. The second is the iOS memory eviction model. With one file per op, only the envelopes the drain loop is currently reading sit in memory.

Failure I hit. I forgot the .atomic write option in the first version. A backgrounded app got killed mid-write to one envelope, which left a half-written JSON on disk. On next launch, JSONDecoder threw on that one file. try? swallowed the error and silently dropped the operation. The user lost a memo. The fix was both .atomic and never try? a decode without surfacing the failure to a diagnostic log.

Step 3: Watch the network with NWPathMonitor

Apple gives you this for free. There is no reason to install a reachability library in 2026.

import Network

final class NetworkWatcher {
    private let monitor = NWPathMonitor()
    private let queue = DispatchQueue(label: "outbox.network")
    private(set) var isOnline = false
    var onChange: ((Bool) -> Void)?

    func start() {
        monitor.pathUpdateHandler = { [weak self] path in
            let online = path.status == .satisfied
            guard let self, self.isOnline != online else { return }
            self.isOnline = online
            self.onChange?(online)
        }
        monitor.start(queue: queue)
    }
}

Two opinions worth defending here. First, I treat "connected to a network" as "online" and never as "can reach my server". The reachability of a specific endpoint is a question I let the drain loop answer the hard way, by trying. Second, I do not debounce. If the user flips from Wi-Fi to cellular twice in a second, the drain loop will fire twice and the deduplication in Step 6 makes that safe.

Failure I hit. My early version queried path.isExpensive and refused to drain on cellular. I thought I was being polite to the user's data plan. Then I noticed that the only feature in my app using the Outbox is the user's own action of sending their own note. They very much want it to go even on LTE. Letting the user's explicit intent override a cost heuristic was the right call.

Step 4: Drain with bounded concurrency

The drain loop wakes on three triggers: a new enqueue, the network coming back, and a scheduled retry timer firing. It pulls eligible operations and runs them through their handlers.

actor OutboxDrainer {
    private let store: OutboxStore
    private let handlers: [String: OperationHandler]
    private let maxInFlight: Int = 3

    init(store: OutboxStore, handlers: [String: OperationHandler]) {
        self.store = store
        self.handlers = handlers
    }

    func drain() async {
        guard let ops = try? store.all() else { return }
        let now = Date()
        let eligible = ops.filter { $0.nextEligibleAt <= now }

        try? await withThrowingTaskGroup(of: Void.self) { group in
            var slots = 0
            for op in eligible {
                if slots >= maxInFlight {
                    try await group.next()
                    slots -= 1
                }
                group.addTask { [self] in
                    await execute(op)
                }
                slots += 1
            }
            for try await _ in group { }
        }
    }

    private func execute(_ op: OutboxOperation) async {
        guard let handler = handlers[op.kind] else { return }
        do {
            try await handler.run(op.payload)
            try? store.remove(op.id)
        } catch {
            try? backoff(op, error: error)
        }
    }
}

I cap concurrency at three. Higher numbers used to win me 200–300 ms on initial drains of large queues, then I noticed those wins evaporated under any real radio condition. Three is enough to mask the latency of one slow request without saturating the cellular link.

Failure I hit. My first drainer was not an actor. It was a class wrapping an OperationQueue. Two concurrent triggers (network-up plus a new enqueue arriving in the same 50 ms window) would each schedule a drain, and the same operation would execute twice. Making the drainer an actor serialises drain calls automatically. The actor reentrancy debates aside, this is one of the cleanest wins Swift Concurrency gave me.

Step 5: Exponential backoff with a hard ceiling

The retry policy is a single function. It mutates the envelope, persists it, and lets the next drain pick it up.

private func backoff(_ op: OutboxOperation, error: Error) throws {
    var updated = op
    updated.attemptCount += 1
    let base = min(600.0, pow(2.0, Double(updated.attemptCount)))
    let jitter = Double.random(in: 0..<(0.3 * base))
    updated.nextEligibleAt = Date().addingTimeInterval(base + jitter)
    updated.lastError = String(describing: error)
    try store.update(updated)
}

Doubling with a 10-minute ceiling means a request that has been failing for an hour will only be retried every ten minutes after that point. I deliberately do not give up. There is no "drop after N failures" policy because in my app every queued operation is something the user explicitly typed and pressed send on. The right time to give up is when the user clears the queue manually from a settings screen.

Failure I hit. My first backoff used a fixed 30-second retry. The first time my server had a 90-minute outage, every device in the wild was hammering it once every thirty seconds, and the post-recovery thundering herd took down my single Postgres instance for another twenty minutes. Exponential with jitter solved both problems with the four-line function above. Jitter costs nothing and saves you the day a thousand phones come back online at the same airport gate.

Step 6: Make every handler idempotent

A queue that promises at-least-once delivery is a queue that will, sooner or later, deliver something twice. Build for that on day one.

Every operation already has a client-generated UUID. The handler passes that UUID to the server in an Idempotency-Key header. The server stores a row keyed by the UUID and the user, and the second call returns the first response from a small cache.

struct SendEmailHandler: OperationHandler {
    let api: APIClient
    func run(_ payload: Data) async throws {
        let req = try JSONDecoder().decode(SendEmailPayload.self, from: payload)
        try await api.post(
            "/v1/send",
            body: req,
            headers: ["Idempotency-Key": req.id.uuidString]
        )
    }
}

I keep the UUID inside the payload as well, not just on the envelope. That way the handler can be tested without an envelope, and the wire format is self-contained.

Failure I hit. I forgot to make my analytics endpoint idempotent and reused the same Outbox for it. After a server hiccup, I had a user whose "opened settings" event was counted four times. Funnels read like the app had become viral overnight. Lesson: idempotency is not a server-only concern, but the server has to enforce it. The client only proposes; the server disposes.

Step 7: Hand the UI an optimistic state

The UI does not wait for the network. It writes to a local store and shows the user the "sent" state immediately. The Outbox is a background fact.

@MainActor
final class ComposeViewModel: ObservableObject {
    @Published private(set) var sentLocally: [LocalEmail] = []
    let outbox: Outbox

    func send(_ draft: Draft) async {
        let local = LocalEmail(id: UUID(), draft: draft, sentAt: .now)
        sentLocally.append(local)
        let payload = try! JSONEncoder().encode(
            SendEmailPayload(id: local.id, to: draft.to, body: draft.body)
        )
        try? await outbox.enqueue(kind: "sendEmail", payload: payload)
    }
}

I do not surface a "queued" indicator. The user pressed send. Their mental model is "it sent." Showing "queued, will retry" in the UI is a tax I refuse to charge the user.

Failure I hit. My first version did show a spinner per queued message. Users hated it. The spinner was honest and useless: "queued, retrying" is information the user can do nothing with. Removing the spinner did not change a single delivery outcome and improved the perceived speed of the app noticeably. The Outbox should be invisible until it fails for so long that a user-visible warning is warranted, which in my app is an hour and which I have triggered exactly once in ten months.

Common failures sidebar

A short list of things I have seen go wrong with variants of this design, gathered from my own commits and from two friends who shipped their own versions:

Filesystem case sensitivity. Naming files with the raw UUID().uuidString is fine on iOS but bites you the moment you copy your queue directory onto a macOS volume formatted case-insensitively for testing. Lowercase the filename if you ever read these files outside the app sandbox.
Codable evolution. Adding a new field to OutboxOperation without Optional will break decode for every envelope written by a previous app version. New fields are always optional, with a default.
Background time. The drain loop after a network-up event has roughly thirty seconds of background time before iOS suspends the app. Long uploads need URLSessionConfiguration.background, which is a different story I am leaving out here.
Clock drift. nextEligibleAt is wall-clock. A user setting their phone's clock forward six hours will trigger an immediate drain of every queued op. In practice this has never happened to me. In paranoid mode I would use ContinuousClock for the comparison.
Disk full. try data.write(.atomic) throws on a full disk. Handle the throw; do not silently lose the user's input. I show a one-time alert and keep the in-memory copy.

What I would do differently if I started today

I have now shipped this design across two apps. A few small changes I would make on a clean slate:

First, I would use SwiftData for the store from day one. When I wrote the original, SwiftData was not stable enough for me to trust on the critical path. It is now, and it gives you a real query language for diagnostics, which the file-per-op approach does not.

Second, I would expose a read-only AsyncSequence<OutboxState> from the Outbox so the UI could subscribe to overall queue health without polling. Today I poll from a hidden settings screen, which works, but a SwiftUI integration would be cleaner.

Last, I would write a fuzz test that randomly enqueues, drains, kills the app mid-drain, and replays the queue. Most of the bugs I shipped in this code would have been caught by one weekend of fuzzing.

If you want to take this further

Three things are worth your next afternoon, in order:

Add a hidden debug screen with a "retry now" button and a list of currently queued operations. You will use it more than you think when triaging real user reports.
Wire os_log with a category of "outbox" on every state transition. The signpost output in Instruments is shockingly informative once a queue starts misbehaving in the field.
Read the actor reentrancy section of the Swift Concurrency proposal one more time. The Outbox is the place in my codebase where I most often regret not having read it more carefully.

Captio-style Simple Memo is an iOS app I maintain on weekends. It turns whatever I type into an email and sends it before I can second-guess. I write here when a piece of code surprises me. App Store.

I version every prompt I send to Claude. Here's why.

Captio-Style Simple Memo — Fri, 22 May 2026 13:11:44 +0000

Q1: Why did I start logging every prompt I send to Claude and Cursor?

A. Because I lost a Sunday afternoon in September 2025 trying to reconstruct a prompt I had nailed down three weeks earlier. The model's built-in history was useless — I could not search by the shape of the prompt I half-remembered. After rewriting it from scratch and getting a worse answer, I decided to treat my prompts the way I treat my commits: append-only, plain text, lived in the editor.

Q2: What does each entry look like?

A. One block per non-trivial prompt. ISO timestamp, model, one-line task, the prompt verbatim, a few lines of outcome. No tags. No app. No CLI. A real entry from August 14, 2025:

## 2025-08-14T16:32+09:00  claude-sonnet-4-5  ios/captio
TASK: Make the share extension's preview card render in <50ms when the
host app passes a 4KB plain-text string.

PROMPT:
> I have an iOS share extension built in Swift. When the user shares
> plain text, I want to render a preview card showing the first 200
> chars and the character count. The preview is currently taking ~180ms
> and I think it is the AttributedString conversion. Show me a version
> that uses NSAttributedString and a CATextLayer instead, and explain
> the tradeoff in one paragraph.

OUTCOME:
- Worked first try. Dropped to 38ms median on iPhone 13.
- Tradeoff was correctly named: lost dynamic type support.
- Reused the pattern two weeks later for the keyboard ext.

The timestamp is the only required field. Everything else is optional. Half my entries have no OUTCOME: block because the prompt failed and I bailed. That's fine. A log that punishes you for being honest is a log you stop writing.

Q3: How is this different from what ChatGPT, Claude, and Cursor already give me?

A. Three histories, three search bars, three different relevance algorithms. None of them index by the thing I actually remember about old prompts — the shape, not the literal first sentence. I remember "the one where I asked it to write a property wrapper that throttled writes." Built-in searches are bad at shape. grep over my own plaintext log is good at shape, because I named the shape in the TASK: line.

Q4: When does the log start paying back?

A. Around month three. Months one and two are pure capture overhead — there is nothing to recall yet, so the work feels one-directional. The flywheel starts when I notice that I am looking things up in prompts.log more often than I am opening a model's sidebar. I tally-marked the "wait, what worked last time?" moments on a sticky note for two months: down from roughly five per day to under one. That is two of my daily 90-second context breaks reclaimed, which compounds.

The second-order payback is harder to measure but more interesting. Reading my own log end-to-end on a Saturday morning in March (ninety minutes total) surfaced three pattern clusters I had not noticed while writing them. One: roughly two-thirds of my failed prompts were failures of context, not capability. The model could have solved the problem; I had not given it the surrounding code or constraints. Two: my highest-hit-rate prompts cluster around naming the exact file and stating the constraint as a hard number. Three: I rephrase the same five questions every month across different projects. That observation gave me a small templates/ folder of reusable prompt scaffolds, and dropped my average turns-to-correct-answer on those repeating shapes from about 3.4 to 1.6 over the next two months.

Q5: When is it overkill?

A. If you write fewer than maybe 20 non-trivial prompts a week, the capture cost outweighs the recall benefit. If your team already shares prompts in a repo or doc, that shared store is more valuable than a private log. If your work is mostly one-shot ("write me a regex," "fix this typo"), the recall path doesn't matter — you'll never look the prompt up again. I am also not religious about the format. I piggyback on a journaling habit I already had. If you don't have a "open a text file and write something" muscle, a fancier tool may be a better starting point for you than a flat file.

Q6: What's the unexpected win that I didn't plan for?

A. The log became a personal RAG. In April I was trying to get Claude to write a Swift property wrapper, and after two unsatisfying turns I pasted about 60 lines from prompts.log (every previous time I had asked for a property wrapper, including the failures) into the conversation as context, and asked it to write a new one in the same style. The third turn was the answer I wanted. Now I run an 11-line shell function:

prompthist () {
  local q="$1"
  grep -B1 -A20 -i "$q" ~/notes/prompts.log \
    | head -n 400 \
    | pbcopy
  echo "Copied matching prompt history to clipboard ($(pbpaste | wc -l) lines)."
}

prompthist "property wrapper" puts the entire context of every previous time I asked about property wrappers into my clipboard. The model reads my past failures and writes around them. This is grep, not embeddings. For 14,000 lines and a sample size of one user, grep is enough.

Q7: What did I get wrong about it?

A. Three things. I assumed I would need tags. I don't. I tried JSON for "structure," and stopped within a month because schema decisions ate the writing energy. I assumed the log would teach me about the model; it actually taught me about myself. The highest-hit-rate prompts I write are uniformly under 80 words, second-person, name the exact file or function I care about, and state the constraint as a hard number. The clever, multi-example prompts I was proud of in 2024 had a worse track record than the boring ones. I had to read 200 of my own failures in one Saturday morning to see that.

Q8: What would I change if I started over today?

A. Two things. I would co-locate the log with my git repo from day one. Mine sits at ~/notes/prompts.log and is symlinked into every project, but for the first six months it lived only in ~/notes/ and I kept forgetting to look at it inside a Cursor session. The fix was a Cmd+T jump-to-file shortcut to prompts.log from any workspace. The second change: I would version it. The log itself is now in a private git repo with daily auto-commits. The commit history of my prompt history has answered "when did I last care about X?" twice already, and it cost me one afternoon to set up.

I would not start with anything fancier than that. Vector embeddings, RAG pipelines, a homegrown CLI: I have looked at all three and the marginal benefit over grep is, for one user and a five-figure number of lines, statistically indistinguishable from zero. The thing the log gives me is not retrieval; it is the habit of capturing in the first place. Every tool I have evaluated lowered the retrieval cost at the expense of raising the capture cost. That trade is bad for me.

Q9: This one's for you.

If you've kept a prompt log, or tried and abandoned one, I'd like to hear what made it stick for you, or what made you drop it. Especially if you switched away from a database or app back to a flat file, or went the other direction. Two sentences is plenty.

I build Captio-style Simple Memo — a one-screen iOS app that emails my note to my inbox in under half a second. I have shipped it alone since 2024. I post here whenever a habit changes how I work.

I shipped an iOS app with zero third-party dependencies

Captio-Style Simple Memo — Tue, 12 May 2026 13:48:09 +0000

At 11:47 PM on a Sunday, I deleted the last import Alamofire from my Xcode project. I replaced eight network calls with seventeen lines of URLSession code. The unit tests passed. The app cold-started about 80 milliseconds faster. I went to bed.

That was the moment I committed to a rule I have not broken since: the iOS app I'm shipping carries zero third-party dependencies. Twelve months later, it is the single most contentious thing about how I work as a solo dev.

TL;DR

Twelve months of zero third-party dependencies on a small iOS app got my IPA to about 2.1 MB and my cold start to 280 ms median, in exchange for roughly two weekends of work I would have skipped with off-the-shelf libraries.
The biggest win is not performance. It is that every line of Swift in the project is debuggable by me, with no source-map archaeology and no vendored module to apologize for at 1 AM.
The rule is not absolute. I would add a third-party library tomorrow if it solved a problem I could not reasonably solve myself in one weekend, with tests, and with a maintainer who actually answers issues.

The setup

I am a solo developer. I ship an iOS app called Captio-style Simple Memo. It does one thing: you type a note, you tap a button, the note is in your email inbox in roughly 0.3 seconds. No accounts. No sync. No cloud database. The whole product is a thin UI on top of MFMailComposeViewController, a small encryption layer for the local draft cache, and a handful of system frameworks.

The first prototype, in late 2024, used three third-party Swift packages: SnapKit for layout, KeychainAccess for secure storage, and a small async HTTP wrapper around URLSession I had cargo-culted from my last job. None of them were strictly necessary. All three were habits.

By month two, two things had happened. The IPA had drifted past 6 MB. Cold-start times measured on my old iPhone 12 mini moved from 220 ms to 410 ms. Neither number is ruinous on paper. But for an app whose entire identity is "you tap, the email goes," half a second of warmup is the product. So I started cutting.

What I tried first (and why it failed)

The obvious play was triage. Keep the libraries that earned their weight, drop the rest. I made a spreadsheet. Each row: a third-party dependency. Each column: bytes added, build-time added, time-to-replace estimated in hours, unique value over Apple's SDK.

It looked rational. It also failed. The triage spreadsheet got me to drop SnapKit, which I should have dropped on day one. It got me to keep KeychainAccess, because the time-to-replace estimate was four hours and I told myself four hours was too much. Three months later I needed to support an experimental share target that KeychainAccess did not handle cleanly in my setup. I burned six hours wrestling with the library before I gave up and wrote 60 lines of SecItemAdd / SecItemCopyMatching directly. The wrapper had saved me four hours up front and cost me six on the day I needed it most.

That was the moment the rule stopped being aesthetic. I was not removing dependencies because zero-dependency code is morally superior. I was removing them because every dependency I keep is a future morning I do not control.

The thing that actually worked

I rewrote the rule. Instead of "fewest dependencies possible," I wrote this in my project README:

A third-party dependency is allowed only if it would take me longer than one weekend to write a correct, well-tested replacement, AND the dependency is actively maintained, AND it has fewer than three transitive dependencies of its own, AND it ships with tests I can read.

The change is subtle but important. The old rule was a bias. The new rule is a gate. It forces me to do a tiny piece of estimation up front. It also forces me to confront an uncomfortable fact: most of the third-party libraries I had reached for in the past were not in the "longer than one weekend" bucket. They were in the "I never bothered to learn the system API" bucket.

Here is what fell out the other side of that gate, in twelve months of shipping:

Networking: 38 lines of URLSession plus a tiny Result-based wrapper. Replaced Alamofire and one custom in-house wrapper.
Keychain access: 62 lines wrapping SecItem*. Replaced KeychainAccess.
Layout: native Auto Layout with a small set of NSLayoutConstraint helper extensions, about 40 lines. Replaced SnapKit.
JSON: Codable. There was never a real reason to keep SwiftyJSON.
Logging: OSLog. There was never a reason to keep CocoaLumberjack.
Crash reporting: I do not have third-party crash reporting. I have MetricKit, a handful of TestFlight users who actually report issues, and a hard rule that any crash on launch is a release blocker.
Encryption for the local draft cache: AES-GCM via CryptoKit, plus about 90 lines of file-format glue I wrote myself. Replaced a small encryption helper library.

Total third-party packages in the shipping app today: zero. Total lines of code I wrote that exist solely to replace those libraries: roughly 300. Total time spent writing those 300 lines, including tests and rewrites: about 18 hours across twelve months. Two weekends, conservatively.

The numbers I care about, measured on a fresh install on an iPhone 12 mini:

IPA size: 2.1 MB
Cold start (icon tap to first usable frame): 280 ms median over 50 launches
Time-to-email-sent from first tap: median 312 ms
Build time, clean: 11 seconds
SwiftPM resolve time: 0 seconds, because there is nothing to resolve

I am not pretending these numbers are amazing. For an app that does one thing, they are roughly the floor. The point is that the floor was reachable, by one person, in evenings, without a heroic engineering budget, and without any meaningful sacrifice in code quality on the parts I actually care about. Most of that was simply the absence of work I would have otherwise been doing: no integration glue, no version-pin debates with myself, and no "this library moved to v3, here are the breaking changes" weekends I had not budgeted for.

Why does this matter for a small app?

There is a quieter reason I kept the rule. Every Swift Package Manager dependency I add is a small bet on someone else's calendar. If the maintainer of a 3,000-star library posts a deprecation notice next month, that is now my problem. As a solo dev I do not have the bandwidth to absorb other people's roadmap decisions on top of Apple's. Apple already gives me one platform whose roadmap I do not control. Adding a second is a tax I cannot afford to pay quietly.

There is also a debugging argument that I underrated until I lived it. When an iOS 17.x point release changed the behavior of MFMailComposeViewController on dismissal in a way that left my view controller stack in a strange state, I needed about 40 minutes with the debugger to figure out what had changed. If that flow had been mediated by a third-party "mailer" library, my best case would have been waiting for the maintainer to ship a fix, and my worst case would have been forking, patching, vendoring, and learning a codebase I had spent months pretending I did not need to read.

Zero dependencies, in this framing, is a debuggability decision. Every stack frame is mine. Every breakpoint lands in code I wrote and remember. The first time I hit a real production weirdness and the trace was entirely my own code, I noticed how much faster my brain moved. There was no library to be intimidated by.

What I'd do differently next time (counter-take)

I want to be honest about where this approach is wrong, because I have read enough "zero dependencies" essays to know they tend to be smug.

Three places I was wrong:

First, I was wrong about Sentry-style crash reporting. For a year I leaned on "if it crashes on launch, my few beta testers will tell me." That is fine at a few hundred users. It is not fine if I ever cross a few thousand. I will add a thin crash-reporting integration before any real marketing push, and I will accept that the "zero" in my rule becomes "one" the moment the product has scale.

Second, I was wrong to extend the rule to my server tooling. I run a tiny landing page on a small VPS. I spent a weekend writing my own static-site generator because of the rule. The site is fine. The weekend was wasted. The right answer was Hugo. The rule, I now think, applies cleanly to the shipping app and is mostly noise everywhere else.

Third, I underestimated the cost of "I'll write it myself" in the analytics layer. I have no third-party analytics. I have a single anonymous keepalive ping per app launch and a self-hosted PostHog instance I never finished setting up. I should either commit to running PostHog properly or pick a privacy-friendly hosted analytics product. Pretending the problem does not exist is not a strategy.

The honest version of the rule, after twelve months, is closer to: zero third-party dependencies inside the binary the user installs, while remaining boring and pragmatic about everything outside it.

Takeaways for other solo devs

If you are considering this for your own project, here is what I would do:

Run the gate at the moment you reach for any library, not after you have already typed import. The decision is cheap before it is in your code and expensive afterward.
Time-box the replacement. If your "I could write this myself" estimate is over one weekend, the library probably earns its place.
Write a one-paragraph block in your project README that names every dependency and the reason it survived the gate. Future-you needs the receipts.
Measure binary size and cold start before and after each library decision. Numbers protect you from your own taste.
Do not extend the rule to tools that never touch the user's device. Static-site generators, build scripts, and CI runners are not part of the product.

Open question for the comments

I am curious what other solo devs do here. Have you tried a zero-dependency rule on a shipping app, and did it survive contact with a real feature? Or did you have the opposite experience, a single well-chosen library that paid for itself ten times over?

What was the last third-party dependency you removed, and what did you replace it with?

I'm a solo dev building Captio-style Simple Memo, an iOS app that emails the note you just typed in about 0.3 seconds. I write here every few days about the messy parts of shipping things alone.

My inbox has been my only task tracker for 12 months

Captio-Style Simple Memo — Fri, 08 May 2026 11:19:05 +0000

A year ago I deleted Things, archived my Notion task DB, closed every kanban board, and made one rule for myself: every obligation lives in my email inbox or it doesn't exist.

I'm a solo dev. Nobody assigns me tickets. The only thing I have to coordinate is me-now talking to me-tomorrow. So I wanted to find out what actually happens when "task tracking" stops being an app and becomes a single, boring inbox.

Twelve months in, here's the honest report.

TL;DR

Treating my email inbox as the only task queue cut my daily app-switching from around 40 hops to under 10, measured with a tiny script for two weeks.
The model only holds if you commit to two rules: end-of-day zero-inbox, and any obligation that isn't already an email gets emailed to yourself within 5 seconds of thinking it.
It broke in three predictable places — multi-day backlog, multi-step projects, and recurring tasks — and the patches are smaller than building a "real" tracker on top.

The setup

The trigger was embarrassingly small. I was on a walk in March, thought of a one-line bug fix, and reached for my phone to add it to my Things inbox. By the time I had unlocked the phone, opened Things, tapped the plus button, waited for the input field, typed the thing, and chosen a list, ninety seconds had passed. The thought I started with was already softer.

That night I counted: I had 312 open tasks across Things, Notion, GitHub Issues, two Linear projects from old contracts, a Reminders list for groceries, and Slack saved items I'd been ignoring since January. None of these systems talked to each other. Each one demanded its own ritual to enter and its own ritual to clear.

So I tried something stupid on purpose. I deleted Things from my phone. I exported the rest into a single text file, archived that text file, and decided that for one quarter the only place a task could live was in my own email inbox. If I forgot it, fine. If it mattered, future-me would email past-me about it eventually.

That quarter became a year.

What I tried first (and why it failed)

This wasn't my first run at unifying task tracking. Over five years I had cycled through OmniFocus, Things, Todoist, Notion databases, Apple Reminders, GitHub Issues even for personal stuff, plain markdown files in a tasks/ folder, and the back of my paper notebook. Each one felt clean for about three weeks.

The pattern was always the same. I would set up a beautiful taxonomy. I would import old tasks. I would feel productive about the meta-work of organizing. Then within a month the system would split — some things in the app, some things in email, some things in Slack, some things in my head. The system that was supposed to be the single source of truth had become one of seven sources of truth.

The deeper problem wasn't the apps. The deeper problem was that capture and review were separate rituals. Capture happened on my phone, in apps I had to open. Review happened on my laptop, in a different app I had to open. The two rituals never aligned, so the queue I captured into was never the queue I reviewed from.

Email already solved that. Capture from anywhere, review from anywhere, single inbox, archive when done. I had been ignoring the most-used piece of software on my devices because it didn't have "task management" in the name.

The thing that actually worked

The whole system fits in two sentences:

The inbox is the queue. Anything not in it does not exist as a task.
End every workday with the inbox at zero — meaning every email is either replied to, archived, or scheduled-send back to myself for the day I actually want to deal with it.

That second rule is doing all the heavy lifting. Scheduled-send turns email into a deferred queue. "Email me on Tuesday with the migration checklist" is one keystroke away on Gmail and Apple Mail. The thing I would have put in a "Someday" list now arrives in my morning inbox on the day it becomes relevant.

For capture-from-anywhere I use the simplest possible rig: an iOS shortcut that opens a one-field compose window pre-filled with my own email address. One tap, type the thing, hit send. The note shows up in my inbox in under a second. The whole capture takes about three seconds, including unlocking the phone. That ninety-second walk-thought from March takes three seconds now.

I measured the impact in two ways:

A small script counted how often I switched between apps on my Mac during the day. The two weeks before deleting Things averaged 38 task-related app switches per day. The two weeks after averaged 9. The cost of every "let me check my system" moment is gone, because the system is the same window I already have open.
I kept a one-line journal note every Friday: "did I forget anything important this week?". In the year before the experiment that note had a "yes" 22 weeks out of 52. In the year of inbox-as-queue it had a "yes" 6 weeks out of 52, and three of those were obligations from people who texted me instead of emailing me — which is a different problem.

Where it broke (and the patches)

The honest part. Three failure modes.

Backlog days. Some days I cannot get to inbox zero. A trip, a sick day, a launch crunch. The inbox piles up and the next morning is psychologically heavy. The patch was banal: I gave myself permission to open the inbox, select all, archive everything older than 7 days, and trust that whatever mattered would email me again. In a year that "mass archive" move has nuked something genuinely important exactly twice. Both times the sender followed up. The cost of the rare miss is much lower than the cost of carrying a permanent backlog.

Multi-step projects. "Ship the new export feature" is not a task, it's a project. Email is bad at projects because each email is flat. I tried to make threads work as projects and gave up. The patch is that I keep one plain markdown file per active project, named 2026-export-rewrite.md, in iCloud Drive. The inbox holds a single email titled "Project: export rewrite (link in body)" with a link to that file. The email is the entry point. The file is the workspace. When the project ends, I archive the email and the file together.

Recurring tasks. "Pay the AWS bill on the 1st" doesn't fit. Email is event-based, not schedule-based. I tried scheduled-send to myself every month, and it works for low-volume things, but for ten or twelve recurring obligations it becomes its own admin job. The patch is to keep recurring tasks in Apple Calendar with alarms, and accept that calendar is a separate system. Two systems is still a lot fewer than seven.

What I'd do differently if I started today: I'd accept the calendar split from day one instead of pretending email could swallow scheduled events. That fight cost me a month.

Takeaways for other solo devs

If you're shipping alone and tempted to try this:

Stop searching for the perfect tracker. The cost of switching trackers is higher than the cost of any tracker's missing feature.
Make capture cheaper than thought. If your capture ritual takes longer than three seconds you will lose tasks no matter how nice the app is.
Trust scheduled-send. It turns the inbox from a flat queue into a time-aware one without adding a second tool.
Let recurring obligations live in the calendar. Don't try to unify everything.
Re-archive aggressively. A backlog you can't face is worse than a backlog you delete.

Open question for the comments

I'd genuinely like to hear how other solo devs and small teams handle this. Has anyone here tried treating their inbox as the single queue and stuck with it? Where did it break for you, and what was the patch?

If you went the opposite direction — committed harder to a structured tracker and got rewarded — I want to hear that too. I'm not religious about this.

I'm a solo dev. The capture rig described above is essentially the iOS app I built — Captio-style Simple Memo — which sends a note to your own email in about 0.3 seconds. I write here every few days about the messy parts of shipping things alone.