Describe the outcome, not the implementation

Amateur prompt: “add a useState and a button that calls saveDraft.” Better prompt: “users should be able to save a draft and come back to it later.” Tell it what should be true for the user, and let it propose the implementation. You will often get a cleaner approach than the one you would have dictated, because you stopped constraining it to your first idea, and you stay focused on the product instead of the syntax.

The deeper reason this works: when you specify the implementation, you cap the quality at your own first guess. When you specify the outcome, the model can bring patterns you did not think of. You are hiring it for its breadth, so do not handcuff it to your narrowest instruction.

Give it the context it cannot see

The model does not know your stack, your conventions, or last week’s decisions unless you tell it. Most “the AI did it wrong” moments are really “I did not give it the context to do it right.” Up front, hand it:

• the language and framework, and the key libraries you are using,
• the relevant files or patterns to follow, for example “match how auth.ts does this,”
• any hard constraints, like “no new dependencies” or “this must work offline.”

Context is the cheapest quality improvement available. Thirty seconds of setup prevents an hour of fixing a technically-correct answer that ignored how your project actually works.

Work in small, reviewable slices

Ask for one thing at a time. A single function, screen, or behavior produces a diff you can actually read and verify. Giant “build the entire feature” prompts produce output you will either rubber-stamp, which is dangerous, or spend longer untangling than you would have spent writing it yourself, which defeats the point. Small slices keep you in control and keep the AI’s mistakes small and obvious instead of large and buried.

Show, do not just tell

If you have an existing pattern, point at it: “do this the same way the settings screen handles state.” Concrete examples constrain the model far better than adjectives ever will. “Make it clean” means nothing, because the model has no idea what clean means to you. “Follow the structure of this file” means everything, because now it has a target. When in doubt, give it an example to imitate rather than a quality to aspire to.

State the constraints and the “do not"s

Models default to adding things, more libraries, more abstraction, more cleverness. If you do not want that, say so explicitly: “do not add a dependency,” “do not change the public API,” “keep this component presentational.” A few clear guardrails prevent most of the scope creep that quietly bloats a project over time. The model is not going to guess your boundaries, so draw them.

Ask it to explain, not just produce

When a change is non-trivial, ask “why this approach?” or “walk me through what this does.” You get two wins. First, you catch flawed reasoning before it ships, while it is still cheap to fix. Second, you actually learn the code you are responsible for, instead of accumulating mystery. And if the explanation comes back hand-wavy or contradictory, that is a loud signal to slow down and look harder, because the model may be papering over something it does not actually understand either.

Treat the first output as a draft

The first response is a starting point, not a verdict. “Good, but handle the empty case.” “Simplify this, it is overengineered.” “That works, now do the boring version.” Iteration is the normal, expected path, not a sign you prompted wrong. Some of the best results come from three rounds of “almost, but” rather than one perfect prompt, so do not treat the first answer as final just because it looks finished.

Keep a context file you reuse

Maintain a short document, your stack, your conventions, the things to never do, and feed it at the start of sessions. It stops you from re-explaining yourself every time and stops the model from re-introducing the same mistakes you corrected yesterday. It is the single highest-leverage prompt you will write, because unlike every other prompt, you write it once and it improves every session that follows.

When the AI gets stuck, change the question

Sometimes the assistant loops, producing slight variations of the same broken thing. That is your cue to stop repeating the prompt and change it. Give more context, break the task smaller, paste the actual error, or describe the goal a different way. Hammering the same prompt harder rarely works. Reframing it almost always does, because the model was missing information, not effort.

Verify before you trust

One habit underpins all of the above: never let good prose lull you into skipping verification. A confident, well-formatted answer is not evidence that the code is correct, only evidence that the model writes fluently, which it always does. So after every non-trivial change, run it, read it, and check the part that actually matters against reality: the real API, the real data, the real edge case. The assistant’s job is to produce a strong draft, fast. Your job is to be the one who confirms it is actually true before it ships. Keep that division of labor sharp and the speed of vibe coding never curdles into a steady stream of confident, plausible bugs.

The mindset

Good prompting is just good delegation: a clear outcome, enough context, a tight scope, and verification at the end. Treat the assistant like a fast junior developer you trust to draft but not to decide, and you will get most of the speed of vibe coding with little of the mess. The broader philosophy behind all of this is in what vibe coding actually is, and the specific traps to avoid are in 9 vibe coding mistakes.

AI coding: the engine

This is the heart of the whole operation. I lean on an AI coding assistant that can read my entire project, not just a single file, so it understands context and can make changes across the codebase, run commands, and check its own work. A tool that only sees one file at a time is a glorified autocomplete. One that understands the whole repo is a collaborator.

But the tool matters less than the skill of using it. Small slices, clear outcomes, and reading every diff will beat a fancier tool used carelessly every single time. A great assistant with lazy prompting still ships bugs, fast. If you take one thing from this list, make it that. The details are in what vibe coding actually is.

Frameworks I reach for

The rule here is boring on purpose. Boring means well-documented, which means the AI has seen a million examples and gets it right, and means Stack Overflow already has the fix when something breaks.

• Mobile: a cross-platform framework so one codebase ships to both iOS and Android. As a solo developer, maintaining two separate native apps is a non-starter. One codebase, two stores.
• Web tools: whatever is mature and conventional. I avoid the framework that came out last month, no matter how exciting, because the AI does not know it well yet and neither do I.
• Static sites (like this blog): Hugo. Markdown in, fast static HTML out, free to host, and nothing to patch at two in the morning. Perfect for content and for app splash pages.

Hosting and infrastructure

The guiding principle: the best infrastructure for a solo developer is the infrastructure you never have to think about.

• Static hosting: a CDN-backed static host (Vercel, Cloudflare Pages, Netlify all have generous free tiers). My blog and every app splash page live here for free.
• DNS and CDN: Cloudflare. Cheap, fast, and the dashboard does not fight me.
• Backend, only when needed: a managed backend-as-a-service so I am not running and patching servers. Many of my apps need no backend at all, which is the cheapest and most reliable backend there is.

A lot of my apps run entirely on-device, which means there is no server to scale, no database to secure, and no monthly bill that grows with users. That is not an accident. It is a deliberate choice that keeps a one-person operation sane.

The splash-page pattern

Every app gets a subdomain with a single static page that does two things:

• detects mobile and routes straight to the App Store or Google Play, and
• shows a description, screenshots, and a help or FAQ section on desktop.

One link works everywhere, it costs nothing to host, and it doubles as the app’s SEO landing page. I drop that one link in any post or thread and it just does the right thing for whoever clicks it.

The glue that holds it together

This is the unglamorous layer that makes the rest survivable.

• Git, committed constantly. This is my undo button for vibe coding. When a prompt makes things worse, and it will, I roll back in seconds instead of losing an afternoon. Frequent small commits are not optional in this style of building.
• A project context file. A short doc of stack, conventions, and “do not do this” rules that I feed the assistant at the start of a session. It stops the AI from reintroducing the same mistakes and re-explaining the project every time.
• A plain notes file for the backlog. Half of shipping is deciding what not to build this week. A running list keeps the good ideas from derailing the current one.
• Analytics that respect privacy. Just enough to know which articles get read and which apps get used, without turning my users into a product.

What I deliberately do not use

• Heavy project management tools. For one person, a Kanban board with seven columns is procrastination with a nice UI. A text file and a short memory work better.
• Bleeding-edge frameworks. I want the AI to know the answer and the internet to have the fix. Popular and slightly boring beats new and shiny every time.
• Anything that needs a server I have to babysit, unless there is genuinely no way around it. Every running service is a thing that can break while I sleep.

A word on choosing tools

Notice that almost none of this is about picking the single best tool. It is about picking tools that get out of your way and that you can replace without drama. I deliberately avoid anything that locks me in: a proprietary format I cannot export, a host I cannot leave, a framework only one company truly understands. The reason is simple. As a solo builder, my scarcest resource is attention, and every tool that demands ongoing care is a tax on it. So I optimize for boring, swappable, and well-documented over clever and trendy, every time. The best tool is usually the one you stop having to think about the day after you adopt it, and the worst is the impressive one that quietly becomes a part-time job to maintain.

The takeaway

The stack matters far less than the loop: describe, generate, read, run, commit, repeat. Pick boring, well-documented tools so your assistant is fluent in them, host on free static tiers until you have real traction, and keep your operation small enough that one person can hold the whole thing in their head. That last constraint is the real secret. Every tool I choose is chosen to protect it. When you can fit the entire system in your mind, you move fast and you sleep at night, and as a solo builder those two things are the whole game.

1. Not reading the diff

This is the single most expensive habit, and it is the root of most of the others. If you accept changes you have not read, you are not building software, you are accumulating mystery. Each unread change is a thing you do not understand sitting in your codebase, waiting. Read every change. If you do not understand it, ask the AI to explain it or rewrite it until you do. The moment you start rubber-stamping diffs to go faster is the moment you start going slower, you just will not find out for a week.

2. Asking for too much at once

“Build the whole app” produces a thousand lines you cannot review and cannot debug. The output looks impressive and is nearly useless, because you have no idea which parts are right. Work in small slices, one feature, one function, one screen at a time. Small diffs are reviewable. Mega-dumps are just hope wearing a confident face. Slicing the work small is not slower overall, it is what keeps you from drowning later.

3. No version control, or rare commits

Vibe coding is intensely iterative, and iteration goes sideways constantly. Git is your undo button. Commit every single time something works, so that when the next prompt makes things worse, and it regularly will, you roll back in seconds instead of trying to manually un-break a tangle. Builders who commit rarely lose whole afternoons to a change they cannot cleanly reverse. Cheap, frequent commits are not bureaucracy here, they are the safety net that makes fast iteration survivable.

4. Trusting confident wrong answers

AI will invent an API that does not exist and present it like established fact. It will be just as fluent and self-assured when it is wrong as when it is right, which is what makes it dangerous. Confidence is not correctness. Anything load-bearing, a library call, a config value, a security assumption, gets verified against the real documentation, not trusted because it sounded authoritative.

5. Skipping the run-it loop

Generating code without running it constantly is just producing plausible-looking text. It compiles in your imagination and breaks in reality. Run the app after every meaningful change. The feedback loop is the work. Skip it and you will eventually run everything at once and discover ten broken things tangled together, with no idea which change caused which failure.

6. Letting the architecture drift

Every prompt nudges the structure a little. Twenty unsupervised nudges later your codebase is mush, with duplicated logic, three different ways to do one thing, and no clear boundaries. The AI optimizes for making this change work, not for the long-term shape of your system, so that responsibility is yours. Periodically step back and steer: “consolidate this,” “extract that,” “keep this layer thin.” Architecture is the one thing you cannot delegate.

7. No project context file

Without a short document of your stack, your conventions, and your “do not do X” rules, the AI cheerfully reintroduces the same mistakes and ignores the patterns you have already established, because it has no memory of yesterday. A small context file you feed it at the start of each session saves you from correcting the identical thing forever. It is the highest-leverage thing you can write, because you write it once and it pays off in every session after.

8. Vibe coding the critical 20 percent

Auth, payments, data integrity, anything security-sensitive, these are exactly where a subtle generated bug is catastrophic rather than annoying. This is the part of the app where “looks right” is nowhere near good enough. Slow down here. Read every line twice, test the edge cases deliberately, and do not hand the keys to an autocomplete. The speed you gain everywhere else is what buys you the time to be careful here.

9. Outsourcing your understanding

The deepest trap of all: shipping code you fundamentally cannot explain. It works in the demo, so you move on, and then the day it breaks in production, “the AI wrote it” does not help you fix it and it does not help your users whose data is stuck. You are still the engineer of record for every line, and understanding your own system is not optional. If you could not, in a pinch, explain what a piece of code does and why, you do not actually own it yet.

The meta-mistake: assuming the rules do not apply to you

Underneath all nine is one final trap: believing that because the AI is so capable, you get to skip the discipline the rest of us need. You do not. The more powerful the assistant, the more damage a single unreviewed, untested, unloved change can do, precisely because it can touch more of your codebase faster. Capability raises the stakes of carelessness, it does not lower them. The builders who get burned worst are usually the ones who were most impressed by the tool and therefore trusted it the most, skipping the diff and the test run because surely something this smart would not be wrong. Stay a little skeptical, keep the habits, and you stay safe no matter how good the model gets.

The thread connecting all nine

Every one of these mistakes is really the same lesson wearing a different outfit: vibe coding moves the work up a level, it does not remove it. You stop typing boilerplate and start spending your attention on review, direction, and judgment. That is a fantastic trade, but it is still a trade, not a free lunch. Builders who treat the AI as a fast junior developer they actively supervise ship genuinely great things, quickly. Builders who treat it as an infallible oracle ship bugs at record speed and call it productivity.

The good news is that avoiding all nine is mostly a matter of discipline, not talent. Read the diff, slice the work, commit often, verify the risky parts, and keep understanding what you ship. For the positive version of this, the workflow and tools that make it go right, see what vibe coding actually is and how to prompt an AI coding assistant.

A working definition

Vibe coding is describing what you want in plain language and letting an AI write most of the code, while you stay the architect, reviewer, and tester. You are still in charge. You are just not typing every line.

The real shift is from author to editor. For most of software history, your value was in producing code: remembering syntax, wiring up boilerplate, looking up the API for the hundredth time. Vibe coding takes that production cost close to zero and moves your value to judgment: deciding what should exist, recognizing whether the output is correct, and steering when it drifts. You spend less time typing and more time thinking about the product.

That sounds small. It is not. It is the difference between writing a paragraph and editing one. An editor with taste and a fast writer can produce a book quickly. An editor with no taste and a fast writer produces a fast pile of nonsense. The writer got faster either way. Whether that is good depends entirely on the editor.

A concrete example of the loop

Say I want a “save draft” feature. The old way: I open the file, remember the state management pattern, write the handler, wire the button, add storage, debug the typos. Twenty minutes if I am lucky.

The vibe-coding way: I tell the assistant, “Let users save a draft and reopen it later. Match how the settings screen persists data.” It produces the handler, the storage call, and the button in seconds. Then my real work starts. I read the diff. Does it handle the empty draft? Does it collide with an existing key? Is the storage call the one we already use elsewhere, or did it invent a second pattern? I fix what is off, run the app, confirm it works, and commit. Total time: maybe five minutes, and the thinking happened where it mattered.

Where it genuinely shines

• First drafts of anything. A new screen, an API endpoint, a config file. The AI gets you to 80 percent in seconds, and 80 percent of something is far easier to finish than a blank file.
• Unfamiliar territory. New framework, new language, a library you have never touched. The model already knows the idioms you would otherwise spend an hour googling, so the learning curve flattens.
• Boilerplate and glue. CRUD, forms, parsers, scripts, tests, type definitions. The boring 60 percent of every project that you have written a hundred times before.
• Refactors you have been avoiding. “Extract this into a service, add error handling, keep the behavior identical.” Tedious by hand, quick to supervise.

This is the reason a solo builder can now ship what used to take a small team. The production bottleneck is gone, so you are limited by how fast you can decide and verify, not how fast you can type.

Where it bites

• Confident wrong answers. The AI will invent an API that does not exist and write it like gospel. If you cannot tell, you will ship it. Confidence is not correctness.
• Silent drift. Each prompt nudges the code. Twenty prompts later the architecture is mush, with duplicated logic and three ways to do one thing, if you were not watching.
• The 20 percent that matters most. Auth, payments, data integrity, security. The parts where a subtle bug is expensive are exactly where you must slow down and read every line.

I learned the drift one the hard way. Early on I let an assistant add feature after feature to an app without stepping back, and a week later I had three different ways of storing the same data and a bug that touched all three. The fix took longer than building it properly the first time would have. Now I steer the structure deliberately instead of letting it accrete.

The rule I live by: you are responsible for every line you ship, whether you typed it or not. “The AI wrote it” is not a defense to your users when their data is gone.

The loop I actually use

1. Describe the outcome, not the implementation. “Users can save a draft and come back to it” beats “add a useState and a button.” Let the model propose the how.
2. Work in small slices. One feature, one screen, one function at a time. Small diffs are reviewable. Thousand-line dumps are not.
3. Read the diff every time. Non-negotiable. If I do not understand a change, I ask the AI to explain it or I rewrite it until I do.
4. Run it immediately. Vibe coding without running the app constantly is just generating hope. The feedback loop is the work.
5. Commit when it works. Frequent commits give me a safe point to roll back to when the next prompt makes things worse, which it regularly does.
6. Keep a project context file. A short doc of stack, conventions, and “do not do X” that I feed the assistant so it stops reintroducing the same mistakes.

What actually changes about the job

The fear is that vibe coding makes engineering skill worthless. The opposite is true. When anyone can generate code, the scarce skills become the ones the AI does not have: knowing what to build, recognizing a bad solution, understanding the system well enough to catch the subtle break, and having the taste to keep things simple. Those are senior skills, and vibe coding rewards them more, not less. The junior who only ever copied the generated answer never develops them. The builder who reads, questions, and steers gets sharper with every project.

The mindset that makes it work

Treat the AI like a fast, eager junior developer with no memory and no judgment about your product. It produces a lot, quickly, and it will confidently do the wrong thing if you let it. Your job did not disappear. It moved up a level, to direction, taste, and verification.

That is the trade. You give up typing, you keep the thinking. Done right, you ship in a weekend what used to take a month. Done lazily, you ship bugs at the same impressive speed. The entire difference is how carefully you stay in the loop. For the specific habits that keep it on the rails, see how to prompt an AI coding assistant and 9 vibe coding mistakes to avoid.

The quick version

• Cloud AI means your app sends data to a server running a large model, which sends back a result. It is easy to build and gives you access to the most powerful models, but every call costs money, needs a connection, and sends user data off the device.
• On-device AI means a smaller model runs directly on the phone. It is harder to build and limited to smaller models, but it is private, free to run, and works offline.

Now the details, because each axis matters differently for different apps.

Privacy

This is the starkest difference. With cloud AI, user data leaves the device and passes through someone’s servers, where it may be logged, retained, or used for training. For a casual app that may be fine. For anything sensitive, voice notes, health data, private documents, it is a real liability and a hard sell to privacy-conscious users.

With on-device AI, the data never leaves the phone. You can make a credible promise that you do not see, store, or transmit it, because architecturally you cannot. That promise is not just ethics, it is a marketing advantage, and it is the entire premise behind apps like my offline transcription app and on-device chat app. When privacy is the selling point, on-device is not a preference, it is the requirement.

Cost

Cloud AI charges you per request, forever. Every user, every interaction, adds to a bill that grows with your success. That can be sustainable with the right pricing, but it also means a free app with a viral spike can hand you a frightening invoice. You are renting intelligence by the token.

On-device AI costs you nothing to run after the user downloads the model. A million users cost the same as one: zero marginal inference cost. For a solo builder who wants to give an app away or charge once without an ongoing bill, that economics is liberating, and it is closely tied to how you can price the app.

Latency and reliability

Cloud calls depend on the network. They add round-trip latency and they fail when the connection is bad, which for a mobile app is often: subways, planes, elevators, rural areas, spotty wifi. Your app is only as reliable as the user’s signal and your server’s uptime.

On-device runs locally, so there is no network round trip and no dependency on a server staying up. Response time depends on the phone, but it is consistent and it works in airplane mode. For anything users expect to “just work” anywhere, offline capability is a genuine feature, not a nice-to-have.

Capability

Here the cloud wins, clearly. Cloud servers run the largest, most capable models, the ones that write essays, reason through hard problems, and handle enormous context. On-device models are necessarily smaller to fit in a phone’s memory, so they are less capable on the hardest tasks. A small on-device model is great for focused jobs, transcription, classification, summarizing, quick chat, and weaker at open-ended reasoning that demands a frontier model.

So the honest question is not “which is smarter,” it is “how much capability does my feature actually need?” Many real app features need far less than people assume, and a small local model handles them perfectly.

How to decide

Run your app through these questions:

• Is the data sensitive? If yes, lean on-device. Privacy is hard to retrofit.
• Do users need it to work offline? If yes, on-device, because the cloud simply cannot.
• Will inference costs threaten your economics at scale? If yes, on-device removes the bill.
• Does the feature genuinely require a frontier-level model? If yes, you may need the cloud, at least for that piece.
• Are you optimizing for fastest time to ship a prototype? Cloud is easier to start with, so it is a reasonable first move you can replace later.

A useful pattern: prototype with the cloud to validate the feature quickly, then move the parts that handle sensitive data or need to work offline onto the device once you know they are worth keeping. You do not have to choose globally. You choose per feature.

The hybrid path is often the real answer

In practice, the choice is rarely all or nothing. Many of the best apps mix the two deliberately: the sensitive, frequent, or offline-critical work runs on the device, while the occasional task that genuinely needs a frontier model reaches out to the cloud, with the user’s clear awareness. A note-taking app might transcribe entirely on-device for privacy, but offer an optional cloud summary that the user explicitly triggers. The trick is to make the boundary intentional and transparent, so the user always knows when their data stays local and when it leaves. Done well, a hybrid gives you most of the privacy and cost benefits of on-device with an escape hatch to cloud power for the rare cases that truly need it. Just be honest about where that boundary sits, and default to the device whenever you reasonably can.

The takeaway

Cloud AI is the easy default and the right call when you need maximum capability and your data is not sensitive. On-device AI is more work, but it wins decisively on privacy, cost, offline reliability, and the ability to make promises you can actually keep. For a solo builder, that combination, no server bill, no privacy liability, works anywhere, is often worth the extra engineering, which is why so much of what I build runs on the phone rather than in someone else’s data center. Match the architecture to what your feature truly needs, and do not pay the cloud’s costs for capability you were never going to use.