Part 1 of **Building Apps Without Code. This should have been my first article, because this is where it all started.
I can't code. Not "I code a little." I mean I have never written the code behind anything I've shipped.
And I have an app — a real one, submitted to the App Store.
It's called Steamy Dumplings, and it's the reason everything else I'm doing exists. So let me tell this one properly, from the start.
What Steamy Dumplings is
Steamy Dumplings is a virtual blind-box app. If you've ever bought a mystery toy and felt that little rush before you open it, that's the feeling we built around.
You open a bamboo steamer, a dumpling is revealed, and it goes on your shelf — your collection, your trophies. Simple on purpose. The fun is in the reveal and in collecting.
By October 7 we had 500 dumplings wired into the app. Five hundred. I didn't build a system for managing 500 collectibles in code, because I couldn't. I kept saying what the next one should feel like, and we kept going until the shelf was real.
The idea came from my son. He was bringing home these dumpling toys, and then we found out something inside them was harmful — causing burns or something like that to kids when they burst open. I thought the idea was cool, being able to collect all these different kinds of dumplings, but I didn't like the idea of having a harmful toy in the house. So I decided to make a game where you could still collect them — but it was on the phone.
How building with AI actually worked, day to day
I work with an AI partner — Forge, my Muse agent. Forge writes the code. We don't pretend otherwise.
My job is everything else:
- The ideas. My brain goes a thousand miles a minute. That's my ADHD, and for years it meant a head full of ideas and not enough finish-line bandwidth to learn to code and build the thing. This partnership changed the maths: the ideas could finally get out of my head.
- The decisions and the taste. What the steamer should look like, what's too much, when a reveal doesn't feel right. An AI can generate a hundred versions — somebody still has to point and say "that one, and here's why the others are wrong."
- The testing. On a real phone, in real hands — including my son Jack, who's 12, and was one of our playtesters. Kids do not protect your feelings about your app, which is exactly why you want them testing it.
That's what "building without coding" actually looks like. Not one magic sentence. A conversation, over and over: I describe it, Forge builds it, I say what's wrong, we go again.
And Jack did more than test it. He gave me a lot of good ideas that have been put into the game — most of them about how the game looks, and things that improved how it plays.
The hardest parts were not the parts I expected
I assumed the hard part would be "the code." It wasn't — I never touched it. The hard parts were:
1. Saying exactly what I meant. "Make it feel better" is not an instruction. Learning to describe what was in my head clearly enough to build took real practice. That skill, honestly, is most of the job now.
2. Knowing when to stop adding things. Every idea sounds good at midnight. Half of building this app was deciding: does the first version need this feature, or does it need to exist first? It needed to exist first.
3. The unglamorous Apple stuff. Turning a working web build into a real iPhone app is a whole second project. We started with a web build and demo so people could try it. Going native meant buying the Apple Developer Program on October 14 — $99 a year, real money out before the app had earned a cent. Then Forge hit a wall: Apple's API simply wouldn't create the App Store Connect record for the app. So I created it myself, manually. The human had to do the one step the automation couldn't. That happens more than people admit.
4. Problems you only find on a real phone. Our builds ran on cloud Macs — I don't own a Mac — and went up to TestFlight. One build had a sound problem we only caught by testing on an actual phone; the fixed build was confirmed working on device before it became the one we submitted.
The milestone: submitted
On October 19, Steamy Dumplings v1.0 was submitted and sat at "Ready for Review," set to release automatically if Apple approves it.
As I write this, Apple hasn't approved it yet, and I'm not going to pretend otherwise. That's fine — the thing I set out to prove is already proved. A person who cannot code described an app, made the calls, tested it on his phone and with his kid, paid the $99, did the manual step Apple required, and got a real app through the real submission door.
What I'd tell another non-coder
Your job isn't code. Your job is knowing what you want. If you can describe it, judge it, and keep deciding, you have the skills that can't be handed off.
Expect a conversation, not a vending machine. We built this together, in loops, with plenty of wrong versions. Expect one prompt to do it and you'll quit at the first bad build.
Test it in real hands early. Especially a kid's, if you can borrow one. They'll find what's boring and what's broken faster than anyone.
Budget for the boring gates. The $99, the accounts, the records you create yourself — that's not a sign you're doing it wrong. It's the toll booth, and everybody pays it.
Ship the first one small and real. Steamy Dumplings is not everything I imagined on day one. It's the version that exists. Everything I'm building now exists because this first one got finished.
You don't need permission from a skill you don't have. You need a first app.
This was mine.
Patrick Hawkins builds apps, books, and products with AI as a creative partner — no code background. He writes about the real builds, including the failures, here on DEV.
Follow-up article: "Make Your iPhone Into a Mac to Create Apps for the App Store" — how I kept building and submitting apps without ever owning a Mac.
See what I'm building: Hawkins Crafting Co. — Steamy Dumplings and all my other projects live there.
Top comments (0)