My first project had a hardcoded API key in the source code. The navigation crashed if you rotated your phone. The icon was something I made in PowerPoint.

I shipped it anyway. It got maybe 12 downloads, most of them from my family. I’m pretty sure my mom downloaded it twice because she thought the first one didn’t work.

That project was terrible. It was also the most important thing I ever built.

The perfectionism trap

I talk to a lot of junior developers who have been “working on” their first project for six months, a year, sometimes longer. They’re still tweaking it. Still refactoring. Still reading about the “correct” architecture before writing more code.

They’re not building. They’re hiding.

I get it. Putting something out there with your name on it is scary. What if people judge it? What if other developers look at the code and think you’re bad at this? What if it gets a one-star review — or worse, no reaction at all?

Here’s what actually happens: nobody cares. Not in a mean way. In a freeing way. Whether it’s an app on the store, a tool on GitHub, or a side project on your portfolio — your first one will be invisible. Nobody is going to find it and judge you.

What shipping teaches you that building doesn’t

There’s a set of skills you can only learn by actually releasing something. Not by reading about releasing. Not by planning to release. By doing it.

You learn how deployment works — the real version, not the documentation version. You learn that your project breaks in environments you didn’t test in. You learn that the feature you spent two weeks on doesn’t get used, and the thing you threw in last-minute is the one people mention.

You learn that real users do things you never imagined. They click things you didn’t expect. They enter text in fields you thought were obvious. They find bugs in features you were sure were solid.

None of this happens while it’s sitting in a private repo.

“But it’s not ready”

It’s not. It won’t be. That’s fine. Ship it anyway.

Your code six months from now won’t be good enough either, by the standards of you-in-two-years. This never stops. If you wait until your code is good enough, you will wait forever, because the finish line keeps moving as you improve.

The developer who shipped ten bad projects and learned from each one is in a completely different place than the developer who spent the same time perfecting one project that nobody ever used.

I still cringe when I look at my old code. That cringing is evidence that I’ve grown. If you look at code you wrote six months ago and you’re NOT embarrassed, that’s the worrying sign — it means you haven’t improved.

Just ship the thing

If you have a side project sitting in a private repo right now — half-finished, messy, not quite ready — I want you to seriously consider shipping it. This week. As-is.

It doesn’t need to be good. The act of shipping it will teach you things that six more months of building never will.

Your second project will be better. Your third will be better than that. But none of them happen until the first one is out the door.

Make it embarrassingly bad. Ship it. Move on. That’s how this works.

← Previous: Git in 20 minutes → Next: The #1 reason junior devs burn out (coming soon)

📌 See the full roadmap →

devkoan · Build it. Ship it. Earn from it. Every week: one tool, one lesson, one step forward. Hit reply if something here helped. I read every one.

I’ve shipped over 20 projects in the past decade. The first few were awful. I wrote down every mistake I made along the way — 100 of them, collected into a free guide for junior developers. Download it → devkoan.gumroad.com

#2 · 🛠 Build it · See the full roadmap →

Last week I gave you the map. Four steps to go from “I want to build an app” to actually building one. The third step was Git. And I promised I’d explain it properly.

So here it is. No jargon tour. No history lesson about Linus Torvalds. Just what Git does, why you need it before you write anything you care about, and how to start using it today.

What Git actually is

Git is a save system for your code. That’s it.

You know how in a video game you save before a boss fight? So if you die, you don’t have to replay the whole level? Git does that for your project.

Every time you reach a point where things are working — or even just a point where you want to remember what you did — you create a save point. Git calls these “commits.” You can have hundreds of them. And you can go back to any of them at any time.

I didn’t use Git for my first six months of coding. During that time, I broke my app so badly that I couldn’t undo it. I lost two weeks of work. Then I did it again three weeks later. Different project, same gut-punch feeling of watching your progress disappear.

After the second time, I spent 20 minutes learning Git. I haven’t lost work since.

Why beginners skip it

Because it feels like extra work. You’re already struggling to learn Swift or Python or whatever language you picked. Adding another tool on top feels like overhead.

I get that. But Git doesn’t slow you down. It makes you faster. Because once you have it, you can experiment freely. You can try something wild, and if it breaks everything, you roll back to your last save point in ten seconds.

Without Git, every experiment is risky. You start second-guessing yourself. “What if I break something?” So you play it safe. You don’t try things. That fear quietly slows down your learning more than any tool ever will.

The only five commands you need

There are hundreds of Git commands. You need five. Maybe six if you’re feeling adventurous.

git init — Run this once, in your project folder. It tells Git to start watching this folder. You’ll never run it again for that project.

git add . — This stages your changes. Think of it as putting files into a box before you seal it. The dot means “everything that changed.”

git commit -m "your message" — This seals the box. The message is your note to your future self. “Added login screen” or “Fixed crash on rotate” or “I have no idea why this works but it does.” Be honest. Nobody grades these.

git log — Shows you all your save points. Newest first. Each one has your message, a timestamp, and a long ugly ID you can use to go back to it.

git checkout — Go back to an earlier save point. This is the undo button. The one that saves you at 11 PM when you’ve broken everything and you just want to go back to the version that worked an hour ago.

That’s the whole workflow. init once, then add, commit, repeat. Check log when you need to see where you’ve been. Use checkout when you need to go back.

The 20-minute setup

Here’s exactly what to do. Right now, if you have a project.

Open Terminal on your Mac. If you’ve never opened it before, hit Command + Space and type “Terminal.”

Go to your project folder. If your project is on your Desktop in a folder called MyApp, type:

cd ~/Desktop/Document/MyApp

Then:

git init
git add .
git commit -m "first save"

You’re done. You have your first save point. Your project is now protected. If you break something tomorrow, you can come back to this exact moment.

Going forward, every time you finish something — a feature, a bug fix, even just an hour of work — run:

git add .
git commit -m "describe what you did"

That’s the habit. Two commands. Takes five seconds. Saves you hours of pain.

What about GitHub?

GitHub is not Git. This confuses everyone.

Git lives on your computer. It’s local. GitHub is a website where you can upload your Git history so it’s backed up online and other people can see it.

You don’t need GitHub right now. Git alone is enough. When you’re ready to share your code or back it up to the cloud, GitHub is the natural next step. But don’t let that stop you from using Git locally today.

One thing at a time.

The commit message that saved me

I want to tell you a quick story about why good commit messages matter.

About three years in, I was working on an app and something broke. A feature that had been working for weeks suddenly wasn’t. I opened my git log and scrolled through my commits. Most of them said things like “update” or “fix” or “changes.” Useless.

Then I found one that said “added background refresh — works but needs error handling.” That was the one. I’d added background refresh, and the error handling I’d skipped was now causing the crash.

I found the bug in two minutes because past-me had written a decent commit message. If that commit had just said “update,” I would have spent an hour hunting.

Write messages for future-you. Future-you is tired and confused and just wants to find the problem. Help them out.

Next week

We’ve covered the map (what to learn), and the safety net (how to save your work). Next: building something. Your first small, ugly, functional app — and why it matters more than any tutorial you’ll ever watch.

← Previous: The map nobody gave me → Next: Why your first app should be embarrassingly bad

📌 See the full roadmap →

devkoan · Build it. Ship it. Earn from it. Every week: one tool, one lesson, one step forward. Hit reply if something here helped. I read every one.

I’ve documented 100 mistakes from 10 years of building apps — the ones I made and the ones I watched junior developers make. Grab the free guide → devkoan.gumroad.com

#1 · 🛠 Build it · See the full roadmap →

The first time I wanted to build an app, I sat down, opened my MacBook, and thought: okay. Let’s do this.

Then I opened Google.

Four hours later I had 47 tabs open. Three different programming languages downloaded. Two YouTube tutorials paused halfway through. And zero lines of code.

I wasn’t lazy. I wasn’t stupid. I just didn’t have a map.

Nobody had shown me what the territory looked like before I started walking into it.

The problem with googling “how to make an app” — you get answers meant for people who already know the shape of the thing.

Swift or Objective-C? Xcode or VS Code? UIKit or SwiftUI? Bootcamp or self-taught? Start with fundamentals or just build something?

Every single one of those is a real question with a real answer. But when you don’t know what any of those words mean yet, the answer to each question just opens three more questions. You spend four hours clicking and reading and watching and at the end of it you feel less ready than when you started.

That’s not a knowledge problem. That’s a sequencing problem.

The information exists. There’s more of it than you’ll ever need. The problem is nobody tells you what order to learn it in.

I’ve been building iOS apps solo for 10 years. Twenty-something shipped. I’ve made every mistake you can make in this process and kept notes on most of them.

The thing I wish someone had told me on day one isn’t a tip or a trick. It’s this: the tools matter less than the order you learn them in.

Most beginners try to learn everything at once. Or they pick the “best” tool before they understand what any of the tools do. That’s like buying the best hiking boots before you know whether you’re going to the mountains or the beach.

Figure out where you’re going first. Then pick the tools.

If I were starting over today and wanted to build iOS apps, here’s the exact order I’d go:

First: get somewhere to write. Download Xcode. It’s free. It’s made by Apple. It lives on your Mac. This is where you’ll spend most of your time for the next few years so you might as well meet it now. Don’t try to understand it yet. Just install it and open it. That’s the whole step.

Second: learn one language. Swift. Not Objective-C, not Python, not JavaScript. Swift. It’s what Apple uses, it’s what iOS apps are written in, and it’s well-designed for beginners. The debate about which language to learn first is real and completely irrelevant to you right now. Swift. One thing.

Third: learn to save your work properly. This is Git. It creates checkpoints in your code so that when you break something (you will, constantly, that’s normal) you can go back. I skipped this when I started. Lost two weeks of work. Then did it again. Then I started using Git and I’ve never lost work since. Set this up before you write anything you care about.

Fourth: build something small and ugly. Not impressive. Not portfolio-worthy. Just something that runs on your phone and does one thing. A timer. A list. A button that plays a sound. The goal isn’t the app. The goal is going through the full process once so it stops feeling like a mystery.

That’s the map. Four steps. Everything else builds on top of those four things.

Over the next few issues I’m going to go deep on each piece of this.

Next week: Git. What it actually is, why it matters more than most beginners think, and how to get started with it in under 20 minutes even if you’ve never used a command line before.

If you know someone who’s been saying “I want to build an app” for the past year and hasn’t started yet, forward this to them. This is exactly where they need to begin.

→ Next: Git in 20 minutes: the safety net you’ll wish you had sooner

📌 See the full roadmap →

devkoan · Build it. Ship it. Earn from it. Every week: one tool, one lesson, one step forward. Hit reply if something here helped. I read every one.

I’ve documented 100 mistakes from 10 years of building apps — the ones I made and the ones I watched junior developers make. Grab the free guide → devkoan.gumroad.com

You have an app idea. Maybe you’ve had it for months. Maybe you’ve started and stopped three times. Maybe you just don’t know what to do first.

This newsletter is the map.

I’m a solo iOS developer with 10 years and 20+ shipped apps behind me. I write one article a week covering everything from writing your first line of code to making your first dollar on the App Store. No fluff. Just what I actually did and what I learned from getting it wrong.

Here’s the full roadmap. Read in order, or jump to whatever you’re stuck on right now.

🛠 Build it — how to actually make the thing

The tools, the setup, the implementation. In the order you’ll need them.

1. The map nobody gave me 🛠

2. Git in 20 minutes: the safety net you’ll wish you had sooner 🛠

3. StoreKit in plain English (coming soon) 🛠

4. Push notifications without annoying your users (coming soon) 🛠

5. CloudKit vs Firebase — what I actually use (coming soon) 🛠

🧠 Mindset — how to think like a developer

These aren’t pep talks. They’re the mental shifts that took me years to figure out and minutes to explain.

3. Why your first app should be embarrassingly bad 🧠

4. The #1 reason junior devs burn out — and it’s not the workload 🧠

5. Why copying code from Stack Overflow is a skill (not a shame) 🧠

6. The meeting skill no coding bootcamp teaches you 🧠

7. Stop asking “is this the right way?” — here’s what to ask instead 🧠

🚀 Ship it — how to get it out the door

Building is half the work. The other half is everything between “it works on my phone” and “it’s live on the App Store.”

4. The only App Store listing that actually converts (coming soon) 🚀

5. The week before launch checklist (coming soon) 🚀

6. How to get reviews without begging (coming soon) 🚀

💰 Earn from it — how to make money

The part nobody talks about until it’s too late.

8. How to price your app — I got this wrong twice (coming soon) 💰

9. How I got my first 100 users without ads (coming soon) 💰

10. Making your first dollar on the App Store (coming soon) 💰

New here? Start with #1 and work down. Already building? Jump to wherever you’re stuck.

Every article ends with a link to my free guide — 100 mistakes from 10 years of building apps. Grab it anytime → devkoan.gumroad.com/l/wtxarn

devkoan · Build it. Ship it. Earn from it. Every week: one tool, one lesson, one step forward. Hit reply if something here helped. I read every one.