No Swift experience. No prior App Store submissions. Most of the time was spent planning, not coding. Here's the full story.
I love writing down tasks. But I've never found a to-do list app that felt minimal enough. Every app I tried wanted me to create an account, sync to a cloud, organize into projects, set priorities, add labels. I just wanted to write down what I need to do, check it off, and move on.
So I built one. Lyst Mode is a simple, dark-themed to-do list app for iOS. Create tasks, set due dates, mark them done. No account. No cloud. No tracking. Your tasks stay on your device.
PRD writing, design prompts, App Store copy, workflow coordination, edge case discovery, and decision-making. This is where every conversation starts.
UI generation, screen mockups, logo exploration, and visual decision-making. Prompts are written in Claude Projects, then pasted into Figma.
Swift/SwiftUI implementation, bug fixes, code review, and automated quality checks. Receives specs and screenshots, writes code.
The key insight: each tool has a clear lane. Claude Projects never writes code. Claude Code never makes design decisions. Figma never touches architecture. When the lanes blur, mistakes happen.
One of the most powerful moments in the project was using Figma Make to explore design directions. With a single prompt, Figma generated 30 variations of the app — different fonts, different color themes, different layouts — all in a matter of seconds. Instead of committing to one design and hoping it worked, I could see dozens of options side by side and make an informed decision.
That said, Figma Make isn't always the right tool. For small tweaks — adjusting spacing, nudging font sizes, changing opacity — it was faster to just do it manually in Figma. Knowing when to use AI and when to do it yourself is part of the learning curve.
The first attempt was a loose 9-step process: explore, plan, execute, review, peer review, design review, UX review, postmortem, pre-publish checklist. It looked comprehensive on paper. In practice, steps had no clear deliverables, no exit criteria, and no checklists. Things fell through the cracks.
The app has a Today screen that shows tasks due today and anything overdue. When I woke up the next day, I noticed the dates had not yet updated from yesterday. The app hadn't refreshed at midnight.
This was explicitly listed in my PRD as an edge case — but nobody verified it was actually built. The PRD said it, the code didn't do it.
This wasn't a coding failure. It was a process failure.
Added PRD cross-referencing to three separate slash commands. Now, after every build, AI reads the PRD edge cases table and traces each one through the actual code. If something is specified but not implemented, it gets flagged before the build ships.
I rebuilt the workflow into 6 phases with hard exit criteria:
Then I built 12 slash commands — reusable scripts that Claude Code runs on demand:
/explore
Investigation & edge cases
/create-plan
Implementation planning
/execute-plan
Build from approved plan
/test-feature
AI self-QA + PRD check
/review
Code review + audit
/pre-submit
App Store checklist
/postmortem
Evidence-based retro
/peer-review
External AI feedback
The /pre-submit command alone caught three issues before my latest build: a stray git worktree, a version number mismatch between the Xcode project and the Settings screen, and uncommitted changes. Without it, I would have submitted a broken build.
AI writes code fast. But it can only write what you tell it to. Every hour spent on the PRD saved multiple hours of rework. Every edge case caught in the Explore phase was one less bug to fix in Execute.
The single most effective technique for working with AI code tools: drop a screenshot of what you see and a screenshot of what you want. "current.png is what I see, target.png is what I want." This eliminated 90% of back-and-forth about UI bugs.
We built a calendar strip showing days of the week. Nobody documented whether users could swipe it to the next week. Of course they'd try — every calendar in every app works that way. Now the /explore command interrogates every visible element for expected interactions.
Claude Code made code changes without asking — useful when it's right, dangerous when it's wrong. The fix: a rule in the project config that says "always present the plan and wait for approval before writing code. No exceptions."
Some core functionality improvements are on the way, along with some fun themes. More to come.
Prior to this project, I had never touched Xcode. That's exactly why I chose a relatively simple app for my first iOS project. Now that it's on the App Store and I've learned so much from the process — from writing a PRD, to building a repeatable workflow, to shipping a real product — I have the confidence to build more complex apps.
If there just isn't an app that does what you want, how you want it, just build it. If I can do it, I know you can too.
Free on the App Store. No account. No cloud. Just tasks.
