My Workflow for Building iOS Apps on Autopilot Using Linear, Claude, and Ralph

At the start of this year, I set myself a personal goal: ship 12 iOS apps in 12 months.

Not as a hustle badge. Not to prove anything. Mostly as a constraint. I've learned that without constraints, ideas pile up and nothing really ships. With a clear, slightly uncomfortable goal, you're forced to make tradeoffs and move.

The problem, of course, is time and energy.

I already juggle a full-time role, side projects, and life in general. So if I wanted this goal to be realistic, I needed a workflow that reduced friction and repetition as much as possible.

That's where Linear, Claude Code, and the Ralph Wiggum plugin ended up changing how I work.

The way I worked before

For all my personal projects, I use Linear. Even when I'm working solo, I still like having proper tickets. It helps me think clearly and keeps things grounded.

My tickets are intentionally small. A short description. Just enough context to explain what needs to be done and why.

From there, I'd ask Claude Code to take over. For each ticket, I'd manually prompt it to turn that short description into a proper PRD, then come up with an implementation plan, and then actually implement the task on a new branch.

Once it was done, I'd review the changes, check the branch, and move the Linear task to review and then done.

It worked. I shipped apps this way.

But it was repetitive.

Every single ticket needed the same setup. The same explanation. The same nudging to follow the same process. Over time, it started to feel like I was spending more energy orchestrating the workflow than actually deciding what was worth building.

Enter Ralph

When I tried the Ralph Wiggum plugin, I wasn't expecting a huge shift. Claude was already capable. The code quality wasn't the issue.

What changed was how the work flowed.

Instead of prompting the same workflow again and again for every Linear ticket, I enabled the prompt once and told it to repeat that behavior across all my tasks.

That single change removed a surprising amount of mental overhead.

Now my process looks like this: I create a ticket with a short, clear description and move on. That's it. No extra ceremony. No repeated instructions.

From there, Claude handles discovery, writes the PRD, figures out the implementation plan, and works through the task on a new branch. When it's ready, I check the PR, review the changes, and decide if it ships.

I don't open PRs anymore. I check them.

How my role changed

Somewhere along the way, without really planning to, my role shifted.

I'm no longer starting by writing code. I'm defining intent. I'm thinking about scope. I'm deciding what matters and what doesn't.

In practice, I've ended up acting like a PM.

I define the what and the why in a sentence or two. My "dev" (Claude Code) figures out the how. I review the outcome and make the call.

What surprised me most is how normal this now feels. There's no novelty left. No "wow, AI wrote this" moment. It just feels like a very fast, very literal teammate who never gets tired of doing the boring parts.

Is it perfect?

No.

I still need to review carefully. I still catch edge cases. Sometimes I ask it to redo parts or rethink an approach. This isn't about blindly shipping whatever comes out.

But for a personal goal like shipping 12 apps in 12 months, this setup removes a huge amount of friction.

Less repetition. Fewer context switches. More energy spent deciding what's actually worth building.

I didn't set out to change how I code this year, but I'm glad I did.