Building is easy now. Shipping still isn't.
AI-assisted app builders have made it trivially easy to start an app. Write a prompt, and something working comes back in minutes. That part of the problem is solved.
And yet, when I look around at other solo builders, a pattern keeps repeating: folders full of half-finished prototypes, each one stuck at about 70% completion, never shipped. This isn't a failure of effort. It's usually a failure of decisions made — or not made — before any building began.
This article is for beginners using no-code or AI-native tools (Rork is my main example) who want to get their first app out the door. It's less about technique and more about three upfront decisions that set whether you actually ship. I've collected these from both the apps I managed to release and the ones that stayed unreleased on my laptop.
Decision 1 — whose problem, at what moment?
Before anything else, answer this: whose problem does this app solve, and at what specific moment does that problem occur?
This is not "who is my target user." Slicing audiences by demographics ("women in their 30s") contributes nothing to app design. Instead, pin it down to a specific moment: "can't check today's items one-handed on a crowded train," or "can't capture a quick note while in the middle of reading without switching apps."
Once the moment is explicit, every subsequent decision gets easier.
- How much information should be on screen? → If it's a few seconds of one-handed use, minimal.
- Which features go in, which don't? → Anything not needed at that moment gets cut.
- Is push notification needed? → If users will open the app at that moment, notifications matter less than the entry point.
Experienced developers run this question implicitly. Beginners get stuck because they skip it and start listing "features that sound useful." What results is an app where every feature is 70% done and none are finished.
The technique — start from "10 things that annoy me every day"
Imagining other people's problems is hard for a first app. A more effective starting point is writing down 10 specific annoyances in your own daily life.
Pick one from that list where you can articulate the exact moment. In my case, an early app came from "I want to take notes while reading, but opening a dedicated notes app takes too many taps." When you're the person who has the problem, your requirements have natural resolution.
Decision 2 — decide what "done" means before you start
The second decision: what does the first publicly released version contain? Decide this before building. Skip this step and the app almost never ships.
No-code and AI-native tools are especially seductive because new features are one prompt away. The temptation to add "just one more thing" is huge. Eventually you reach a state where you can't tell what to work on next, and motion stops.
Prevent this with a written minimum-release requirements list before starting.
# Version 1.0 — minimum for release
1. Add book title and author
2. Attach notes to each book
3. View the list of books
(Post-release additions)
- Tag search
- Star rating icons
- Cloud syncThe "post-release additions" section matters. By explicitly naming things as "needed later, not now," you inoculate yourself against scope creep during the critical building phase.
If the minimum feels embarrassingly small
Writing out the minimum often triggers a "is this really enough to release?" panic. That anxiety is, in nearly every case, not worth trusting.
Most solo-dev app launches are quiet. Nobody notices for a while after release. That gap is precisely when you add features in response to real usage. The completeness of version 1.0 matters less than whether version 1.0 exists at all. Chasing perfection without shipping costs you far more in lost learning.
My first shipped app had genuinely limited functionality. Two downloads on launch day (one of which was me). From there, iteration produced everything. But iteration can't start before release.
Decision 3 — how much time will you keep giving it?
The third decision: how much time per week will you invest in this app after it's released?
Most first-time shippers don't realize that "the moment of release" matters far less than the continued operation that follows. User feedback in the first two weeks to a month is what determines whether the app survives or quietly dies. Whether you can respond to that feedback is gated by whether you have scheduled time to spend.
Most of us have day jobs, other projects, or finite personal energy. Saying "I'll just find time" doesn't work. You need a realistic commitment up front: "2 hours every Saturday," "1 hour on Tuesday evenings." Something that fits the rest of your life.
If you can't honestly secure this time, consider whether shipping now is even the right move. Unreplied-to bug reports pile up surprisingly quickly, and the psychological weight of ignoring them is real.
How to actually defend the time
What worked for me is blocking the time on my calendar with a boring name — "app maintenance." Saturday 22:00–23:00 is the recurring slot. Once it's on the calendar, it fights back against competing options more effectively than intentions do.
Also useful: decide in advance what you'll do in that slot. Re-deciding each week wastes the slot. "This week, only bug fixes." "Next week, exactly one feature." A decided agenda is what lets the hour actually be productive.
Keep the three decisions somewhere visible
After nailing down the three decisions — the moment/person being helped, the minimum release requirements, and the weekly time commitment — keep them somewhere visible while you build.
A physical sheet taped to your desk. A Notion page you check each session. The format is irrelevant; visibility is everything. When tempted to add a feature, you can quickly check: "does this actually align with the three things I wrote down?"
AI-native tools make adding features frictionless. That's precisely why you need the constraint of "what was I actually building?" in front of you. These three decisions serve as that anchor.
Tools come after, not first
A common beginner mistake: starting from "which tool is best?" That's exactly the wrong order.
Make the three decisions first. The result is a sketch of the app you actually want: "this kind of app, with these features, in this time budget." Now pick the tool that fits that sketch.
- Want to ship as a mobile app, want some logic flexibility → Rork
- Straightforward data-display app → Glide
- Complex web app with heavy logic → Bubble
You can also go tool-first and shape the app around what the tool prefers. This works, but for solo developers, motivation sustains better when "what I wanted to build" is clear and the tool is just the vehicle.
Your first action today — the 10-item list
One small, concrete first step.
Open a blank note (paper or app — doesn't matter) and list 10 things that annoy you daily. Don't polish. Just write. When you're done, pick one entry where an app could help at a specific moment.
That entry is the seed of your first app. From there, walking through the three decisions in this article will give it shape. AI-era app building rewards the thinking you do before the tools. The tools can keep up with you later.
Shipping the first app is the hardest barrier in solo development. Whether you get through it changes the trajectory of every app that follows. If this article is the nudge that gets your first one out, that's exactly what it was written for.