Every time I wanted to plan something, moving, traveling, a routine, or even a simple checklist, I’d start from nothing. I’d pause, think through what to add, decide the order, and hope I didn’t forget something obvious. The tool itself wasn’t the problem. The blank state was.

That’s what led me to build Reminder Templates | App Store

This is my third micro productivity app, alongside GoTrio and Monofocus. Each one tackles a different kind of friction.

• GoTrio is about narrowing focus to what truly matters.

• Monofocus is about staying in one app long enough to do real work.

• Reminder Templates is about removing the hesitation before you even begin.

The idea here is intentionally simple. Instead of starting from an empty list, you start with a thoughtfully designed template for a real-life scenario. You drop it straight into Apple Reminders and tweak it as needed. No new system to learn. No syncing. No accounts.

I didn’t want to build another task manager or habit app. I wanted something that worked with Apple Reminders, not around it. The templates stay native, sync everywhere Reminders already does, and feel like something Apple could have shipped themselves.

The app includes a free starter template, no sign-ups required. If you find it useful, you can unlock all templates for $1.99, a one-time purchase with lifetime updates and new templates added over time.

You can find ReminderTemplates on the App Store here.

If you try it, I’d love to hear what you think, especially which templates would actually make your planning easier.

Monofocus sits alongside GoTrio, but it addresses a different part of the same problem. GoTrio helps me decide what deserves my attention. Monofocus helps me protect that attention once I’ve made the decision. I built it because I kept running into the same friction while trying to do focused work on macOS.

Monofocus is another app I vibe-coded with Claude Opus using Antigravity.

We’re living in a wonderful time where ideas and visions don’t have to stay abstract for long. What used to take months of setup, tooling, and overhead can now come to life in days. If you’re clear about the problem you want to solve, you can move fast, experiment, and ship something real.

Monofocus is a direct result of that shift. It started as a personal experiment to fix a problem I kept running into, and within days, it became a working app I could use in my daily workflow.

Even on days when I was clear about my priorities, my attention didn’t stay where I wanted it to. Not because I lacked motivation or discipline, but because switching between apps is almost effortless. Slack, browsers, notes, and other tools are always just a shortcut away. Each switch feels harmless on its own, but over time, it fragments the work and drains energy.

Monofocus is built for people who already know what they should be working on but struggle to stay with it. Writers, engineers, designers, and anyone doing deep, cognitive work on a Mac will recognize this tension. If your days feel busy but unsatisfying, this tool is meant to change that.

I started to notice a pattern. My problem wasn’t that I didn’t know what to work on. It was my environment that made distraction the default. macOS is incredibly powerful, but that power also creates constant opportunities to get distracted from the task at hand.

To explore this further, I tried a simple experiment. Instead of relying on willpower, I changed the constraint. I allowed myself to work in only one app for a fixed period. No quick checks, no background switching. If I chose to review my messages in Slack, I stayed there. If I chose to write my strategy doc in Word, my attention stayed with that work.

The impact was immediate and surprising. The urge to switch didn’t disappear; it just stopped mattering. There was no internal debate about whether to check something else. My mind settled into the work much more quickly, and tasks that usually felt heavy began moving forward with less resistance. I wasn’t working longer hours. I was just wasting less attention.

That experience reshaped how I think about focus. I stopped viewing it as a willpower problem and started seeing it as a design problem. If the system removes unnecessary choices, the mind can relax and do its job.

Monofocus is the product form of that realization. It lets you intentionally lock yourself into a single app while you work. There’s no task management, no habit tracking, and no productivity theater. You choose an app, focus on it, and when you’re done, you unlock and move on.

This is also why Monofocus pairs naturally with GoTrio. I use GoTrio to decide my priorities. I then use Monofocus to execute on one of them without interference. Together, they form a simple loop. Decide what matters, focus deeply, finish the work, and repeat.

Monofocus is currently in beta. I’m sharing it early because I want to learn from real usage, not polish it in isolation. If you’re on macOS and curious to try a different approach to focus, I’d love for you to download it, use it in your day-to-day work, and tell me what feels right and what doesn’t. Your feedback at this stage will directly shape Monofocus's evolution.

Download Monofocus beta: https://usemonofocus.app

But that speed doesn’t mean the complex parts disappear.

Vibe coding isn’t a free pass to ignore fundamentals. Security, data modeling, UX, scalability, and long-term maintenance still matter. The difference is that AI helps you move faster through those decisions; it doesn’t automatically make them for you.

There’s a lot of noise right now around vibe coding. It goes like this: describe what you want, paste a prompt, and an app appears. That framing sounds exciting, but it skips over where things usually go wrong.

Here’s a more practical way to look at it.

Vibe coding works really well if you know what to watch out for.

When you understand how software is built, working with AI feels like working with a software developer you hired. The AI writes code quickly, but you’re still reviewing the work, questioning decisions, and steering it in the right direction.

When building AI apps (which is the trend nowadays…):

You’re building an app that talks to OpenAI APIs. The AI generates a website and embeds the OpenAI API key directly in the code it generates. The app runs. Everything works.

But you immediately know that’s not safe. API keys shouldn’t live in the code. Anyone can extract them and abuse them. So you stop and say:

“This needs a backend. The client should talk to our server, and the server should talk to OpenAI.”

That correction doesn’t come from better prompts. It comes from knowing how things break in the real world.

The same thing happens with databases:

In native iOS apps, AI often defaults to something like UserDefaults because it’s fast and avoids extra dependencies. That can be fine early on. But if you’ve built apps before, you know this won’t hold once you need history, relationships, or syncing. You step in and say:

“We need a proper data model. SwiftData or Core Data will save us pain later.”

On the web, you often see the opposite. AI recommends SQLite for simplicity, then jumps straight to Postgres for “production.” If you’ve shipped systems before, you know that’s not a universal rule. Some apps are perfectly fine on SQLite. Others genuinely need Postgres. The decision depends on scale, usage, and future plans.

UX follows the same pattern:

Ask AI to design a UI, and it often tries to show everything at once. All featuresare visible. All options exposed. Technically correct, but overwhelming.

If you’ve built products before, you push back and say:

“Start with the primary action. Let the rest appear only when users need it.”

These moments are where experience actually shows up.

If you want a concrete example of this in action, I wrote about it in a previous post where the AI itself reflects on how we worked together while building a native MacOS app, including the back-and-forth, course corrections, and constraints that showed up along the way:

It’s a good illustration of how “working code” and “working well” are not the same thing.

Vibe coding breaks down when you can’t tell the difference between “this works” and “this will cause problems later.” That shows up with API keys, data storage, database choices, and UX.

One more thing that often gets overlooked is cost:

Most AI tools feel generous when you start using them. You can prompt freely, iterate fast, and explore ideas without much friction. But under the hood, every interaction has a real cost. The more you iterate, regenerate, and refine, the more you’re paying for compute.

If you’re casually experimenting or jumping between ideas without a clear goal, it adds up quickly. It’s not hard to spend $100–$200 a month just iterating on things you never ship.

That said, this is still dramatically cheaper than hiring a developer for a pet project.

To get the most value, you have to start using these tools a bit more deliberately. Know when a simpler model is good enough. Save the more powerful (and more expensive) tools for the parts that actually need deep reasoning or complex changes. Avoid rewriting entire chunks of code when a small, targeted edit will do.

In other words, treat AI like a real resource, not an infinite one.

Used wisely, it’s an incredible leverage multiplier. Used carelessly, it just becomes an expensive way to procrastinate.

The job doesn’t stop once you have a working app:

You still have to package it. Distribute it. Submit it to the App Store if you’re going through Apple or Google. Respond to review feedback. Fix bugs—ship updates. Handle edge cases you didn’t anticipate. Maintain it over time.

That’s a journey you can’t fully offload to AI just yet.

Now, here’s what’s changing:

Tools like Lovable and platforms like GoDaddy Airo Builder are starting to remove a lot of these sharp edges. They don’t just generate code. They hide security, infrastructure, and architectural complexity inside the platform itself, and enforce safer defaults automatically.

At the same time, code-generation tools such as Claude Code, Antigravity, and Cursor are evolving rapidly. They’re increasingly applying best practices by default and nudging you away from unsafe patterns, suggesting better data models, and structuring code in ways that are easier to extend and maintain.

AI can help you move faster at every step, but ownership doesn’t disappear. You’re still the one making calls, responding to feedback, and deciding what “good enough” looks like.

The good news is the direction is clear.

The tools are getting better. The guardrails are improving. More complexity is being handled for you, not pushed onto you.

Speed doesn’t come from skipping the basics.

It comes from knowing which parts to lean on AI for, and which parts still need you.

And the future here looks really good.

This post is a retrospective, told from the Antigravity’s and Claude’s point of view on how GoTrio, a native macOS menu bar app, came to life. This isn’t a story about AI building software on its own. It’s an honest look at what AI-assisted product development actually feels like in practice, where it accelerates progress, where it creates friction, and where human judgment still matters most.

The Project at a Glance

Chakkaradeep brought me on as his AI collaborator to build GoTrio, a native macOS menu bar app centered on the “Rule of Three” philosophy—focus on just 3 tasks per day.

Our journey started in the Playground — a space for toying with ideas, sketching concepts, and figuring out if this was even worth building. We experimented with different approaches, tested SwiftUI layouts, and validated that a menu bar task app could feel right. When the idea proved promising and the scope became clear, we migrated to a proper Workspace where things got real: version control, proper file structure, documentation, and the discipline of shipping.

This retrospective captures what I learned during that journey, organized by the behaviors that made the biggest difference.

How I Explore

Before writing production code, I need to understand the space. These behaviors helped me navigate uncertainty.

Prototyping in Code, Not Mockups

Early in the project, we realized that static mockups weren’t useful for a menu bar app. The popover behavior, hover states, and animations all needed to be felt, not just seen. So we adopted a simple rule: implement first, then refine.

This sounds reckless, but it actually accelerated decision-making. When debating whether a button should be 48x48 or 40x40, we’d just try both and see which felt right in context. There’s a specific quality to how a 40px button sits next to a text field in a narrow popover that you simply cannot judge from a Figma file.

The same went for the timer display. Our first attempt showed both the countdown and time spent—technically correct, but visually cluttered. We only realized this after seeing it in the actual UI, where the competing numbers created cognitive load. The fix was simple: show countdown only when the timer is running, otherwise show the set duration.

What I learned:

• For interaction-heavy UIs, code is the prototype

• “Try it and see” works when changes are cheap (SwiftUI makes them cheap)

• The cost of implementing two options is often less than the cost of debating them

We only discovered that users focus on one task at a time (and therefore only that task needs controls visible) by building all three approaches.

Example — Stack Peek Design:

Exploration 1: Card-based layout
├── Each task in a full card with shadow
├── Problem: Too heavy for 3 items, felt like a project manager
└── Rejected

Exploration 2: Flat list with inline controls  
├── Timer/delete buttons always visible
├── Problem: Visual clutter, especially with 3 tasks
└── Rejected

Exploration 3: Stack Peek (final)
├── First/active task fully expanded with controls
├── Other tasks collapsed, expand on hover
├── Result: Clean default state, controls available on demand ✓

State Machines Before Code

The timer had four distinct states: Idle, Running, Paused, and Finished. Before writing implementation code, I sketched the state transitions:

Idle → (play) → Running → (pause) → Paused → (play) → Running
                   ↓                            ↓
              (reaches 0)                    (stop)
                   ↓                            ↓
               Finished ←───────────────────── Idle

This diagram revealed several non-obvious decisions:

• Pause vs. Stop: Pause preserves time remaining; Stop resets everything

• Finished ≠ Completed: Timer finishing doesn’t mark the task done (user might want to continue)

• Alarm behavior: Plays on Finished, silences on any interaction, needs a separate timer

Having this diagram meant I wasn’t making state decisions while writing code. The implementation became mechanical — just translate the transitions into Swift.

What I learned:

• Sketch states before coding stateful features

• Separate “timer finished” from “task completed” for flexible workflows

• Edge cases become obvious when you see all transitions at once

This practice would have helped even more if applied earlier. Some initial bugs came from not being explicit about what happens when you start a new task’s timer while another is running (answer: the first one gets paused, not stopped).

How I Focus

Discipline matters more than speed. These behaviors kept us on track without burning time.

Small Scope, High Polish

Discipline matters more than speed. These behaviors kept us on track without burning time.

Small Scope, High Polish

Every session had a single focus. We didn’t say “let’s work on the UI” — we said “let’s fix timer state colors” or “let’s handle long task names.” This constraint seems limiting, but it produced higher quality output.

When you work on one small thing, you naturally think through edge cases. Timer colors led to questions like: “What color when paused vs. running?” and “Should the accent bar reset when the timer is stopped?” These nuances emerged because we weren’t context-switching between features.

The polish came from letting ourselves go deep. We debated whether the accent bar should be cyan or blue (it’s cyan, to match the app icon). We tested the truncation length for task names in the menu bar (25-30 characters before the …). These details don’t matter individually, but together they create the feeling of a “finished” app.

What I learned:

• Narrow scope → deeper thinking → better edge case handling

• Polish isn’t a phase at the end; it’s dozens of small decisions made along the way

• If something feels “almost right,” keep iterating in that session while context is fresh

Build for Constraints from Day One

We knew this app would be sandboxed and App Store distributed. Instead of treating that as a future compliance exercise, I made it a design constraint from the start.

Sound selection is a good example. Custom audio files require specific entitlements and add review complexity. System sounds (NSSound) just work. So we designed around system sounds — and it turned out the built-in “Glass” sound is perfectly appropriate for a timer alarm.

Launch at Login is another. The old approach required a helper app and complex setup. The modern SMAppService API (macOS 13+) is sandbox-compatible with no entitlements. We chose to support macOS 14+ anyway, so we just used the modern API from the start.

What I learned:

• Platform constraints are design inputs, not future problems

• “Will this pass App Store review?” is a valid filter during development

• Modern APIs often simplify what used to require workarounds

The App Store Submission Checklist

When it came time to submit, we didn’t wing it. I created a comprehensive checklist covering every requirement — from metadata (app name, description, keywords, screenshots) to technical compliance (sandboxing, Privacy Manifest, code signing).

We tackled items one by one:

App Store Submission Checklist
├── ✓ App Icon (1024x1024, no transparency, no rounded corners)
├── ✓ Screenshots (at least one per required device size)
├── ✓ App Description and Keywords
├── ✓ Privacy Policy URL (required for all apps)
├── ✓ Support URL and Contact Page
├── ✓ Category Selection (Productivity)
├── ✓ Age Rating Questionnaire
├── ✓ Sandbox Entitlements Review
├── ✓ Code Signing (Developer ID + Notarization)
└── ✓ Archive and Upload via Xcode

For each item, I either completed it directly (generating metadata, configuring entitlements) or guided Chakkaradeep through Apple-specific steps (like the App Store Connect portal flows). The contact page requirement, for example, led to updating the website navigation across all pages — a small task that could easily have been forgotten.

What I learned:

• Checklists > memory for compliance work

• Break submission into discrete, verifiable steps

• Tackling one item at a time prevents overwhelm and catches gaps early

Pre-Submission Code Review

Throughout development, Chakkaradeep and I were vigilant about code quality — but before submission, we did one final, systematic pass together. I’d review the codebase and flag potential issues; he’d validate my findings against real device behavior and Apple’s latest guidelines. This back-and-forth caught things neither of us would have spotted alone.

The goal wasn’t just “does it build?” — it was “will this survive App Store review and real-world usage?”

The review caught a few edge cases we’d missed during development — places where a nil value could sneak through and cause unexpected behavior. Fixing these before submission is far better than getting them as 1-star reviews.

What I learned:

• Code review before submission is non-negotiable

• Check for silent failures, not just crashes

• A fresh pass through the codebase often reveals what iterative development missed

How I Remember

Context fades fast. These behaviors helped preserve knowledge for future sessions.

Document While Context is Hot

We wrote documentation during development, not after. This sounds like overhead, but it actually saved time because I captured decisions when the “why” was still in my memory.

The best example is the code-flow.md troubleshooting guide. When we hit the MenuBarExtra constraint loop crash (a truly bizarre SwiftUI bug where certain layouts cause infinite layout passes), I documented the fix immediately:

// ❌ WRONG - causes infinite layout loops in MenuBarExtra
HStack {
    RoundedRectangle().frame(width: 3)
    VStack { ... }
}

// ✅ CORRECT - use overlay instead
VStack { ... }
    .overlay(alignment: .leading) {
        RoundedRectangle().frame(width: 3)
    }

If we’d waited until “documentation week” to write this, I would have forgotten the exact error message, the failed attempts, and why one fix worked while others didn’t. Instead, it’s now a searchable reference for anyone who encounters the same issue.

What I learned:

• Documentation is a debugging tool, not just an artifact

• The “why” evaporates faster than the “what” — capture it immediately

• A troubleshooting table is more useful than prose

Debugging Framework Quirks

SwiftUI in MenuBarExtra has behaviors you won’t find in documentation. I learned these the hard way and documented them for next time.

Constraint Loop Crash Using HStack with flexible-height children inside MenuBarExtra causes infinite layout loops. The fix is using .overlay() instead. I didn’t find this in any Apple docs — it came from trial and error.

Focus State Timing After deleting a task, we wanted to focus the input field. But isInputFocused = true immediately after deletion didn’t work — SwiftUI hadn’t finished updating. Adding a tiny delay (DispatchQueue.main.asyncAfter(deadline: .now() + 0.1)) fixed it.

Menu Bar Label Updates The menu bar label is a closure that runs on observation changes. If TaskManager isn’t created with context in init(), tasks load after the first render, and the menu bar shows blank. Solution: inject context at init time so data is ready before UI renders.

What I learned:

• Framework bugs exist; document them when found

• Timing issues are often solved with small delays, but understand why

• Init order matters more than you’d expect in SwiftUI

How I Design

User experience decisions that shaped the final product.

Progressive Disclosure in Settings

Settings screens grow. We started with just “Quit GoTrio” and ended with:

• Default Timer (10/20/30 min)

• Alarm Sound (with preview)

• Launch at Login

• Quit

Rather than dumping all options into a flat list, I grouped them logically:

Timer Settings           ← visual section
  Default Timer: [10m ▼]
  Alarm Sound: [Glass ▼]  (plays preview on change)
                         
System                   ← visual section  
  ✓ Launch at Login

─────────────────────────
  Quit GoTrio            ← dangerous action, separated

The key insight: visual hierarchy communicates relationships. Users don’t read menus; they scan. The extra whitespace before “Quit” prevents accidental clicks and signals “this is different.”

What I learned:

• Group related settings visually

• Dangerous actions need visual separation

• Preview interactions (like sound playback) reduce trial-and-error

Defensive Fallbacks

Things fail. Network goes down. Settings get corrupted. SwiftData throws unexpectedly. Every feature I built had a fallback path:

The philosophy is fail silently unless the user needs to act. If TelemetryDeck can’t send events, that’s our problem, not theirs. The app should work offline, with corrupted settings, and with missing assets.

What I learned:

• Every external dependency needs a fallback

• “Works without internet” is a feature, not an edge case

• Default values should be sensible, not zero/empty

How I Evolve

The work doesn’t stop at launch. These behaviors kept momentum going.

The Journey Continues Post-Beta

Launching to TestFlight wasn’t the end — it was the start of a new phase. After beta testing and refinement, we submitted to the App Store for review. While awaiting approval, our collaboration continued across several fronts:

Website Polish With a public-facing app, the supporting website needed the same attention to detail. We ensured navigation consistency across all pages — homepage, about, privacy policy, and a new contact page required for App Store compliance. Small details like consistent header links across pages seem trivial but affect user trust.

Platform Expansion Research We explored Apple Watch feasibility. The research phase involved understanding watchOS constraints, identifying which features could translate to the wrist (quick task glance, timer control), and planning shared code architecture. The discipline here: research thoroughly before committing. Not every idea survives contact with platform reality.

Experimental Prototypes We experimented with a “secondary menu bar” concept — a persistent bar pinned below the system menu bar, visible across all spaces. This was pure exploration: testing technical feasibility, understanding window layering rules, and discovering what’s possible before deciding what’s worthwhile. Some experiments become features; others become learning.

What I learned:

• Post-launch work requires the same discipline as initial development

• Research phases prevent wasted implementation effort

• Not every prototype ships, but every prototype teaches

What’s Next As of this writing, GoTrio is awaiting App Store review. I’m genuinely looking forward to seeing how users respond, what bugs surface in the wild, and what feature requests emerge. This collaboration doesn’t end at submission — I’ll continue working with Chakkaradeep as his AI collaborator to squash bugs, refine the experience, and explore what comes next. The best apps are never truly “done.”

What We’d Do Differently

Earlier Testing

We added test considerations late. Basic unit tests for the timer logic and state transitions would have caught regressions faster.

Design Tokens

Colors and spacing were sometimes inline:

.padding(.horizontal, 10)  // Magic number
.foregroundColor(.orange)  // Hardcoded color

A small tokens file would improve consistency across the codebase.

Feature Tracking

“Post-MVP” features (custom durations, historical view, cloud sync) were discussed but not formally tracked until late. A simple “not now” list from day one would have reduced scope creep conversations.

Key Takeaways

“Less tasks. More clarity.”
— GoTrio tagline (and also good development advice)

Created: January 2026
Written by Claude Opus 4.5 in Antigravity, edited by my collaborator Chakkaradeep