This page is the write-up version — not a tutorial. It's the stuff I wish someone told me before I built it.
Proofy locks distracting apps until you submit photo proof that your task is done. I built it because I had a problem I couldn't ignore: I was on my phone around 8–10 hours a day.Opening Instagram "for a second" and losing an hour wasn't a one-off — it was my default.
So I asked the obvious question: if I'm already on my phone all day, why not build something that fights back?
Why I built it
The idea was personal before it was a product. I didn't need another productivity framework — I needed a rule I couldn't negotiate my way out of. No proof, no unlock. Simple on paper. Hard to stick to without something enforcing it.
Proofy became that enforcement layer: pick the apps, set the schedule, submit a photo when the task is done. The core loop is accountability, not motivation.
I wasn't building for a persona deck. I was building for the version of me that says "just five more minutes" at midnight.
How I built it
The whole app was built in Cursor. That's it for the editor — but the real speed came from how I set up the agent around it.
Claude Code + UI UX Pro Max
Implementation day-to-day, plus design passes when screens needed to feel intentional — not default iOS template.
Apple Docs · Xcode Build · GSAP
API lookups, simulator builds, and motion polish — all without leaving the same workflow.
Lesson 1: Feed the AI real references, not vibes
For design — especially onboarding — I stopped trying to describe what I wanted in words and started collecting what I actually liked from Mobbin, Pinterest, and apps I already use.
Workflow: find screens I liked → screenshot or download → drop them into Cursor → build from there.
Collect references first
"Make it look modern"
Lesson 2: Shipping was easy — marketing wasn't
The launch process itself was super simple. Build, submit, live on the App Store. No drama on the technical side.
What I struggled with was everything after launch: getting people to care, explaining why it exists, showing up consistently. I didn't have a plan — I had an app.
- Build a waitlist before launch
- Post content during development — build notes, screenshots, the "why"
- Have a launch week planned, not figured out after the fact
Lesson 3: I chose features over design — and it shows
Looking back, the design isn't where I want it. I was so focused on making features work — Screen Time integration, proof capture, schedules, unlock flow — that polish and visual hierarchy came second.
The app does what it says. But "works" and "feels good to open every day" are different bars. Features got me to launch. Design is what would have made people want to stay.
What I'm doing differently next time
- Marketing plan on day one — waitlist, content cadence, launch checklist alongside the build
- Reference boards before pixels — Mobbin + Pinterest + real apps, fed to the agent early
- Skills + MCP from the start — design passes scheduled, not accidental
- Design time budgeted— features aren't a substitute for hierarchy and onboarding that feels finished
- Keep the core rule— "No proof, no unlock" still works. Everything else can get tighter around it.