At the start of February 2026 I had one iOS app live in the App Store. As I write this at the end of May, I have ten, and a sustainable working pattern. Ten apps in roughly four months, built solo, on my Mac plus an iPad when in coffee shops.
In this post I will try to extract the actionable insights from this sprint. It’s a smaller and more focused companion to my longer post on vibe coding iOS apps on my iPad with Claude from my favorite coffee shop, which describes my setup and the actual processes. This one is about things I couldn’t see at the beginning, but which might be useful for someone starting to do the same thing — especially if they already know how to ship software. These are notes on vibe coding for senior developers specifically — not for beginners, not for people learning to code.
Intended Audience
Most vibe coding content out there is written for people who never coded before. That’s a fast growing and legitimate audience, but I’m not addressing it here. Vibe coding for senior developers is a completely different topic, and that’s where I’m heading with this article. Ideally, you’re not using AI to learn how to code – you already did this for years. You’re just delegating something you already know how to do, and the delegation skill is what’s new.
The guidelines below are what I’d send my past self at the start of February. They assume you know the language, the coding platform, and master the basic processes.
1. Use Two Models
The change that most improved my workflow was running two models in parallel — Claude Code as the primary, MiniMax M2.7 as the backup, accessed through OpenRouter.
The split is:
Claude Code handles architecture, agentic loops, spec interpretation, and anything that needs to hold the whole project in context. Memory files, genesis prompts, testing and versioning approaches.
MiniMax M2.7 is used to do refactors, boilerplate, a second opinion on complicated codebases (treating it like the code review guy in my team), and just a backup when I hit my Claude quota.
Claude Code Max is $100/month, MiniMax 2.7 is $20 on the Token Plan, which is more than enough for a backup model (I reckon I could even use it as the main actor, if I really had to, but it would be tight). Beyond pricing, the main reason for this is continuity. Losing steam midday because Claude Code decided to eat half of my tokens on useless stuff, leaving me naked in the middle of that big feature build, that is something that I find highly demotivating.
This is the simplest of the vibe coding for senior developers guidelines, and the one I’d act on first: at least two models, with a clean separation approach.
2. Optimize At the Root
Most of the friction in my coding sessions eventually traces back to underspecification in the first prompt. Every “actually, also…” in turn eight is usually a sign that turn one wasn’t clear enough.
So I came up with a single genesis prompt that describes the app before any code is written. App name, bundle ID, monetization model, tech stack, architecture, file structure, color palette, IAP product IDs, App Store metadata — all of it in one document. The prompt I use is open-sourced as the iOS App Genesis Mega Prompt. It has 23 sections, and it is basically a general purpose template. It only needs the actual app functionality, something you can define in Claude chat or your agent of choice. Then throw that in the genesis prompt and feed the mix to Claude Code. Most of the time, Claude Code is able to do 95% of the work in the first pass.
The time spent on the genesis prompt has the highest leverage in the project. An hour of careful spec writing avoids a day of mid-session corrections. Don’t assume the model has your work history, your experience, your skills. Feed it good, feed it early.
3. Keep Your Mental Mode Light
Shipping at this pace is hard to sustain if you try to hold every project in your head. There’s simply not enough mental capacity to do so. I learned this the hard way. Eventually, I decided I needed an externalized way to know what mental mode I’m in at any moment.
The framework I use for this is Assess-Decide-Do, a mega prompt built on a methodology I’ve been teaching for fifteen years. The short version: at any moment you’re in one of three modes. You’re assessing (what’s the state, what are the options?), deciding (which option, at what cost?), or doing (executing the chosen option). The common failure is doing all three at once. Multiply this by 10 projects simultaneously and you’re free falling.
When I open a session with an Assess-Decide-Do flavored Claude Code, I know immediately which mode we’re in – and I can steer it in the mental mode I want in that specific moment. “We’re in Assess mode for the next 20 minutes — don’t write code, just model the trade-offs for the IAP layer.” Or: “We’re in Do mode on the breath-sync feature — the spec is locked, just implement, nudge me when you’re done.” The framework does the same thing for the AI that it does for me: it names the correct next action.
That’s what keeping the mental mode light means in practice — not memorizing some ruleset, just overlaying a solid cognitive framework over your processes, so you and the agent are in sync.
4. Shrink Building, Expand Verification Time
With AI doing the coding, the time spent building shrinks. The time spent verifying needs to grow in proportion, and that’s the adjustment most senior developers are slow to make. This shift in where the actual work lives is the part of vibe coding for senior developers practice that catches the most experienced people off guard.
My current ratio is roughly 30% spec, 20% generation, 50% verification. After every major feature build: read the diff carefully, run the build, scan for the specific failure modes this model produces, document everything, and only then move to the next step.
The reason verification matters more than it used to is context drift, which is the main hazard of long sessions. The more code generated inside a session, the more the model’s attention dilutes across what it has already produced. The frequency – and impact – of these issues rises as sessions get longer:
- silently breaking something built earlier in the same session
- forgetting a constraint from the genesis prompt
- regressing on a fix it just made
- “improving” a working file in a direction nobody asked for (this kinda drives me crazy, honestly)
In my experience, around the third, fourth hour of an intense session, more time goes to un-doing than to doing, because context drift compounds with every additional generation. What works is: shorter sessions, aggressive commits, fresh contexts started on purpose, thorough documentation of everything that was built so far and review of every generation.
If you came up writing every line by hand, which most, if not all, senior developers out there did anyway, you already built the verification reflex. You just need to redirect it from your own typos to the model’s drift.
5. Pivot Toward Marketing Earlier than Feels Natural
When the build compresses, the bottleneck moves forward. Before, the most important question used to be “do I have the app yet?” Now it’s: “does anyone know it exists?”
I now start ASO scaffolds the moment the genesis prompt is locked, before any code is written. App name candidates with keyword research, subtitle variations, screenshot copy, the first three sets of keyword fields for Applyra to A/B against, a one-line pitch for Product Hunt. The app build and the marketing build run more or less in parallel.
Marketing also has its own tooling now. While migrating dragosroua.com from WordPress to Astro I built a small set of Claude Code skills for content work — an SEO metadata batch updater, a CTA injector with placement strategies, and a link analyzer that finds orphan pages. They’re open-sourced.
The point isn’t those specific skills; it’s the principle: the same discipline and approach that ships apps also ships the marketing infrastructure around them. Skills, prompts, and scaffolds for content, ASO, and distribution belong alongside the genesis prompt, not after it.
The senior-developer instinct is to build the thing well and let it speak for itself. With the build time compressed (and going asymptotically to zero, for everyone), that instinct produces apps with no downloads. The scarcer resource is not coding anymore, it’s attention. So, marketing counts.
6. Treat Every App as an Experiment
This portfolio approach – or, as I call it, an “ecosystem of apps” – tends to work if you stay light enough to move on when an app doesn’t produce any meaningful result, basically treating it as an experiment, not as the final product.
In my case, monthly revenue is concentrated in two, three apps: Zen Tales, addTaskManager, MosquiGo. The others earn a few dollars per month, each. If I had focused just on a single one, it would be really just about luck. Hit and miss. But treating each as an experiment gives back very good data every week — about ASO, monetization, category dynamics, and which features users actually pay for. That keeps me lean, and I can pivot to something better very fast.
The right metabolism for senior developers doing vibe coding work is: ship fast, measure honestly, and be ready to either double down or walk away on each app independently. The AI lowered the cost of building, so the cost of abandoning a project dropped too.
My 10 Apps and What Each One Required
Here’s the actual lineup from this 4-month sprint, with the specific coding challenge each one forced me to solve.
addTaskManager — productivity built on the ADD framework. Challenge: CloudKit sync across iOS, iPad, and Mac; a realm-state machine that gates UI based on which mode the user is in, and the Zen Status feature: inferring user’s mental state from the actual data in the app. This is the one app I already had, the vibe coding sprint involved mostly adding features like import from other apps
MosquiGo — ultrasonic mosquito deterrent. Challenge: a frequency engine that runs reliably in the background under AVAudioSession constraints, plus anti-habituation patterns so the sound stays effective over hours of use.
AI Kiddo First Words — kids’ first words in 8 languages. Challenge: full localization including Japanese and Korean, child-safe Text-to-Speech routing, and a UI simple enough that a one year old will actually use it.
Zen Tales — Buddhist stories with AI reflection. Challenge: Text-to-Speech generation stories without bloating the app size, real-time AI reflection with careful cost control, while keeping the UI extra simple
Just 5 Words — pick 5 words, get an AI story and image. Challenge: fully on-device generation via Apple Intelligence Writing Tools and Image Playground. No backend, no API key, no network round-trip.
Light Njoy — your iPhone as an ambient lamp. Challenge: five distinct rendering layouts (aurora bands, radial pulses, liquid meatballs, full glow, grid), AI-generated color palettes from natural language, breath-sync haptics, and a custom .njoy file format for sharing lighting sequences.
Hacking Habits — financial resilience habits, companion to my Gravitational Habits ebook. Challenge: a habit-graph data model, integration with the existing Hacking Habits hub on dragosroua.com, and ADD-driven user flows.
Flight Lens — AI-powered flight intelligence. Challenge: Aviation API global polling, the Pulse anomaly index calculation, Apple Intelligence summarization of flight events, and Travelpayouts integration.
999 Wise Quotes — premium wisdom app, sibling to Zen Tales. Challenge: curating ~999 copyright-clean quotes with primary-source attribution as the Scholar tier moat, three AI actions per quote, same Text-to-Speech challenges as in Zen Tales.
Shape Walk — gamified GPS walking app. Challenge: real-time location tracking with low battery overhead, a shape-matching algorithm that grades how closely a walked path traces a target shape, MapKit overlays, and background location handling.
Different categories, different stacks, different monetization paths. But all built following the guidelines above.
Closing Thoughts
These are my notes from a specific four-month sprint. I’m not sure if it qualifies as a final method. The model landscape will change for sure. The tooling will change. Some of these guidelines may be obsolete by the end of the year.
But I hope this 6-point approach will survive:
- writing tight specs
- two-model setup (main + backup/verifier)
- mental modes management (ADD)
- heavy verification
- marketing early (or in parallel)
- every app is an experiment
If you’re a senior developer thinking about doing something similar, my take is the work hasn’t gotten easier — it just moved. The value you add now sits in the spec, the verification, and the distribution, which is where most of us were not very experienced to begin with.
That’s the honest summary of vibe coding for senior developers practice four months in: same craft, different shape.
