ReportWire

Tag: coffee shop work

  • How I Build iOS Apps from Coffee Shops Using Claude Code

    [ad_1]

    It’s 9AM and I am sitting in my favorite coffee shop. Somewhere in Mekong Delta, or
    in Lisbon, or in Seoul, doesn’t really matter. What matters is that my espresso was
    already tested and approved as high quality, the internet connection in the coffee shop
    is decent, and I am ready to start my vibe coding session on my iPad – using
    Claude.

    But let’s stop for a second.

    I’ve been writing code for more than 35 years. Went through the whole shebang, from
    2 floppy disks Slackware, through PHP and Laravel, and then Objective C, Swift and
    React Native. I coded apps with more than 100,000 monthly users (for me or for my
    clients). So, do you think I can still be called a “vibe coder”? Let’s keep this
    question in mind, and revisit towards the end.

    The Actual Vibe Coding Workflow

    Without further ado, let’s go into what I’m actually doing.

    First and foremost, I look at my yesterday’s priorities file. I keep between 4 and 6
    projects alive at the same time, which means I’m juggling through them as I build, in
    real time. Sometimes I can remember yesterday’s session, but most of the days I need
    reminders to know the context, the features I’m building, the blockers and the
    priorities. That’s why, at the end of the day, I’m writing down my priorities for
    tomorrow.

    In a way, I’m starting backwards.

    After that, I select whatever I’m committed to do in the next 3-4 hours. Yes, no
    more than 3-4 hours – and you’ll see why, again, towards the end of this article. In
    Assess-Decide-Do terms, I’m staying in the Decide realm. I’m trying to evaluate what
    can be reasonably done in that time slice and sometimes I leave some projects out. On
    average, in a week, each project gets at least 3-4 days of consistent work.

    Once I have a clear understanding of the features, I start my working sessions.
    Which are unfolding in this order:

    • the actual coding (the technical mumbo-jumbo)
    • the review stage (kind of the second Decide stage)
    • the committing: writing logs and setting priorities for the next session

    Let’s take them one at a time.

    The Technical Mumbo-Jumbo

    If you’re the technical type, this is for you. But even if you’re not, you may get
    some insights (otherwise feel free to skip to the next section).

    I work with Claude Code on my iPad, using the remote repos. On each app, I maintain
    a different branch, usually named version/X.x.x, and then I set up XCode
    Cloud workflows that will trigger builds on merging to master.

    All coding happens in the version branches, until the app compiles, and the feature
    I’m working on is ready to test.

    Then, still on my iPad, I open my Github app and start a PR, aiming at merging the
    version branch into master. If there are no conflicts, I hit merge, and that triggers
    XCode Cloud builds. I am on the normal developer plan, so I get around 25 hours per
    month. If you are conscientious about what you’re doing, even with 3-4 apps developed
    at the same time, this is more than enough.

    A build is usually taking between 2 minutes and 10 minutes, and then there is a
    little bit of processing time. I use these gaps to enhance the prompts and write logs
    as the features are implemented. Once the builds are up in the App Store and processed
    in TestFlight, I just open, you guessed, the TestFlight app on my iPad, and begin
    playing with the apps.

    Most of the time, bugs are found, or incomplete implementations are revealed, so I
    get back to Claude Code and start the whole process anew.

    By now, half of my espresso is gone, but I just keep going, until I hit the review
    stage.

    The Review Stage

    Around this time, my espresso is more than 80% gone, just maybe two more sips left.
    That means I can get out of the technical workflow and look at what was actually
    achieved. This usually involves a thorough end to end testing of the features, but this
    time without any pressure to add code. I’m going again through all the projects I’m
    working, and take time to write down any quirks, improvement ideas and leftovers, and
    then mark as done anything that’s already done. I’m using addTaskManager for this.

    This is also the stage where my mind can start resting. It’s a big step from
    focusing deep down on one project and writing uninterrupted sessions of 1-2 hours, like
    before, to actually juggling between 3-4 apps, all with very different requirements
    and at very different stages. The biggest bottleneck of this vibe coding thing is not
    the actual code implementation. It’s the mental clarity and the strength of focus. At
    this stage, both of them are starting to fade out, which means it’s time to stop.

    The Productivity Throughput

    In very simple numbers, my throughput is now 5x-7x higher. I can code 3-4 iOS
    projects in parallel and cut time from idea to deployment from months to weeks. It’s
    not unusual to do a cold start of a new project at the beginning of the month, and by
    the end of the month it is ready for App Store.

    On top of the iOS apps layer, I’m also maintaining this blog and a little bit of
    marketing around it (and around the apps, of course). Here, I think I’m around 2x-4x
    more productive. I can maintain the 2-3 articles / week posting speed and most of the
    time my audience on social media is up to date with what I’m doing – including blog
    readers like you.

    So, I’m revisiting the opening question: even though I have a 5x-7x throughput, can
    you really say I’m a vibe coder? I dare to say no, because behind this dramatic
    productivity increase is not only the AI, but mostly my 35 year coding experience.
    Maybe the special workflow too (I’m talking Assess-Decide-Do here),
    but honestly, I think it’s the hard earned ability to know what to pick, how much time
    to dedicate, what to cut out and, generally, how to maintain a consistent architecture
    that’s slim enough to not slide out, but strong enough to produce results. Without
    these, I would probably be at 1 app at a time.

    Closing Out – Commits and Priorities

    It’s around 1-2 PM and the coffee shop audience is slightly changing towards lunch
    eaters. That’s my cue to prepare to go home. The coffee shop will become busier and,
    sometimes, noisier and harder to concentrate in.

    By now, the changes have been committed, the logs have been written and the
    priorities for tomorrow’s “vibe coding” session have been set. My espresso is long
    gone, and I’m ready to head back to my one-year-old son.

    See, using AI to amplify my productivity is a great use case, but for me, the best
    use case is to get more time. I need more time to spend with my family, to be there for
    my one-year-old. At 50+ you don’t get too many second chances.

    [ad_2]

    dragos@dragosroua.com (Dragos Roua)

    Source link