Every few weeks someone claims they rebuilt an entire platform over a weekend with AI. Replaced Salesforce, killed the SaaS tool they were paying for, all from a couple of prompts. Most of the time there's no product behind the claim. It's positioning: looking like a frontrunner on AI, maybe fishing for consulting work, mostly wanting to be a voice in the room.
A small number are the real thing. They've got serious infrastructure behind them, a cluster of well-briefed AI agents running in parallel, and they can stand up a working proof of concept over a weekend. They're also burning a fortune in credits and they didn't sleep, and what they've got on Monday is a PoC, not a polished product. Keep those people separate from the ones narrating a fantasy.
I've led development teams and a technical practice long enough to know what "build me a better [pick any product]" takes, and here's the part that gets lost in the hype: it's now possible. Before AI, replacing a core platform with something custom wasn't a serious conversation. Today it is. The lie isn't the ambition, it's the weekend and the single prompt.
The real version still needs research, scoping, and far more planning than people expect. That last part caught me off guard. I used to plan just enough to get from A to B and make calls as I went. Now you've got the fastest development team on the planet waiting on you, and the more you plan up front, the better their first pass comes back. It won't be great, but it'll be a solid foundation, and it shows up in 20 minutes instead of six weeks.
What the one-shot shortcut gives you is the other thing entirely. Something that looks the part: a clean screen, a confident demo, enough polish to survive a LinkedIn scroll. A pig in makeup. It looks great until real work touches it, and then it falls over.
Here's the shape of it. You can get to 80% of almost anything fast, and that speed is intoxicating. The last 20%, the part that makes something robust and secure and ready for real use, is where the work lives, and it's closer to 95% of the effort. A developer named Addy Osmani calls this the 70% problem, and honestly his 70/30 is probably nearer the mark than my 80/20. Either way, that last stretch is where most weekend projects quietly die, because people get bored or assume the tool will carry it home. It won't. That part is on you, so here's how I handle it.
How I build real software with AI
The real work is mostly setup and discipline: give the AI your standards, plan before it writes a line, build one feature at a time, and make it prove the parts it would rather skip.
I don't start by prompting for features. I start by giving the AI the rules it has to follow, the same baseline on every project, so it opens each session already inside my standards for security, git hygiene, testing, and how I want problems approached. That context lives in the repo, not in my head and not retyped every morning. It's the same idea as building a detailed persona for the AI, scaled up to a whole codebase.
Then comes the part everyone wants to skip: requirements, research, and decisions. Before a feature gets built I write down what it needs to do and why, and every real architectural decision gets recorded, the choice and the reasoning both. When the AI comes back to that area three weeks later, it reads the decision instead of guessing at it, and so do I.
The build runs in phases, one feature at a time, against a checklist. Each instruction is small and scoped: build this module, review it, harden it, then move to the next. A big reporting section goes in as its own phase. Billing goes in as its own phase, broken into chunks. The AI is quick, but you steer one feature at a time or it wanders off and builds you a mess.
I push it hardest where it's weakest. Left alone it will write something that works and quietly skips the parts that keep you out of trouble. So I run a security pass before launch, make it strip personal data from the logs, put every file download behind an auth check, and patch dependencies the moment a vulnerability shows up. With AI generating the volume, you review and test more, not less.
And I keep working notes, so the next session starts where the last one ended instead of relitigating what we already settled. On something I build in bursts, weeks apart, that handoff is the difference between momentum and starting over.
What it costs
None of this is free, and I don't mean your time. To build a full-featured product with an AI coding engine I'll spend USD $1,200 to $1,500 a month in credits, for three or four months of focused work. That's the real number, and you are not doing this well on a $20 ChatGPT plan. The tools that make a seasoned developer dangerous right now are metered, and the meter runs fast when you're generating and regenerating real code all day.
So which model should I pay for?
At the top end the tier matters, but for most of the work the leverage is your plan and context, not the newest model. Deep multi-step reasoning, long context windows, and gnarly code are where the frontier models pull ahead, and if that's your daily work the better model earns its price. Most of what decides whether the output is any good, though, happens before you pick a model. Point the best model on the market at a thin, unplanned prompt and all you've done is teach it to build the wrong thing at 200 mph. The gap lives in what you told it and what you checked afterward.
If you're not building software
Maybe none of this is your world. You're not standing up a platform, you only want a chatbot to be more useful for the ordinary stuff. The principle doesn't change, only the scale does. Your everyday answers come back bland for the same reason a rushed prompt produces a shaky app: the model had to guess at everything you didn't tell it.
Before you ask for something that matters, give it four things it would otherwise invent: who the answer is for, what to avoid, what a good version looks like, and the limits it has to respect. "Give me a meal plan for the week" gets you something generic, built around ingredients you don't have. "Plan four weeknight dinners for two kids, one who won't touch anything green, 30 minutes max, using the chicken and pasta I already have, and skip the tacos we're sick of" gets you something you'll use. Same free model. The difference is the brief. The longer version of this habit is the two-message rule, and if you want somewhere to keep those briefs, here's how to turn a Google Doc into a knowledge base for Gemini.
Then do the smaller version of what a developer does: don't accept the first draft. Ask it what it assumed and what it left out. That's the agreement problem: the model will tell you it's finished long before it is.
Demand less genius
The how is becoming a commodity. Anyone can generate the first 80%. The value is in the why, and in the willingness to finish the 20% that everyone else walks away from. That's true whether you're building the bespoke platform that finally fits, or trying to get a straight answer out of a chatbot on a Tuesday.
So the next time you wonder which model to pay for, ask the better question first. What did I actually give it, and did I check what it gave back?
The people getting the results you keep hearing about aren't holding a secret model. They're doing the part nobody posts about.
Share more context. Demand less genius.