In 2015, I wrote “So you want to build an App..” because a few times a month someone asked me to build their app for them. Today, someone with that same idea can skip the ask and build a working prototype over a weekend with Claude Code or Cursor. Sure, it’s not going to be perfect or complete but it will be a rough cut. The most clueful will be further along while others are going to have the most basic UI that is little more than CRUD. That said, it’s impressive they have something.
That’s a big change. Some of my 2015 advice is now flat wrong. Most of it isn’t. Let’s sort it out.
Let’s Recalibrate who I Think You Are
Just like last time, let’s start with some assumptions:
- First, you probably still aren’t a developer. You might be a doctor, lawyer, or engineer with deep domain knowledge, but you don’t cut code. And you don’t have to anymore.
- Next, you have a working prototype in Lovable, Replit, Claude, or something similar. It has screens. It has buttons. Some of the buttons even work.
- Next, you still aren’t a Kardashian. (Some things never change.)
- Finally, you think the hard part is over because the code exists.
AI made the first version of your app cheap, but finding customers, protecting their data, and keeping the app running still cost what they did in 2015.
What Changed: The First Version Is Cheap
In the original post, I told readers to set aside money early, in the “five figures” and sometimes “six figures,” and not to expect developers to work for equity. For a first version, that’s no longer true.
A non-developer who can describe a problem clearly can now get working code from Claude, Cursor, or Copilot, try it, complain about it, and get a better version an hour later. I covered this in “Developers are Solving The Wrong Problem“: customers don’t know or care how clean your code is. All they know is whether it solves their problem. Vibe coding gets you to that test faster and cheaper than ever.
I also said writing code was the easiest part. (Easiest, not easy.) It’s even easier now. The cost of the code dropped. The cost of everything around the code didn’t.
The good news is you can test five ideas for the cost of one. The bad news is so can everyone else.
What Didn’t Change: Your Idea Still Isn’t Special
In 2015, I argued your idea probably wasn’t that good and your real problem was keeping it secret for too long. Both matter more now. If you can build it in a weekend, so can 500 other people, and some of them started last weekend.
The first two steps from the original post still apply word for word. Write a paragraph describing what the app does. Then write a paragraph describing what the app is NOT. “Facebook for X” still doesn’t count. For bonus points, those two paragraphs are now your first prompt. A coding assistant builds what you describe, and a vague description gets you a vague app.
Then talk to potential customers instead of your friends or family. ChatGPT doesn’t count either. An AI will happily tell you your idea is brilliant. A customer who won’t pay tells you something useful.
What Got Harder: Selling It
Selling was harder than building in 2015. Today the app stores and Product Hunt are flooded with weekend builds, so getting noticed takes more work than it used to.
First, find 10 people with the problem who will pay to have it solved. Not “would use it.” Pay.
Next, build only what those 10 people need. In 2015 I described the MVP as launching a 50-level game with 5 levels. That still holds, and now you can build those 5 levels in a day. Your Version One sucks anyway, so get it in front of people to make it suck less.
Finally, plan how the next 100 customers find you: a website, search, a community you’re already part of, or referrals. If you don’t have an answer, the code doesn’t matter.
What Got Dangerous: Data, Security, and Maintenance
My 2015 post said to budget for maintenance: updates, security patches, new features, and testing all over again. Generated code you didn’t write and don’t understand makes that bill bigger, not smaller.
The risks are concrete. A Stripe secret key ends up inside the mobile app where anyone can pull it out. A Firebase or Supabase database goes live with rules that let any user read every other user’s records. Someone builds their own login instead of using Okta, Auth0, or another identity provider, and stores passwords badly. A coding assistant will write any of these without complaint if you don’t know to ask. None of them break in the demo. They break once you have real customers and real data. You might get lucky and just embarass yourself. In some jurisdictions, you could face actual financial penalties.
When I rebuilt ScottAdamsSaid.com with Claude, I wrote zero lines of code. Claude handled the extraction, cleanup, and loading of over 2,000 posts. I still spent real time on quality control: catching about 100 posts the downloader had missed, fixing internal links by hand, and deciding what not to change. AI did the typing. I did the checking.
That’s why the advice from my vibe coding post matters even more for non-developers. If you didn’t write the code, you need tests that prove it does what you think: business logic, interfaces, security, and performance. And be willing to throw the code away and regenerate it once you understand the problem better.
Finally, it still isn’t passive income. Refunds, reviews, and complaints didn’t get automated away. Somebody answers those emails, and early on that somebody is you.
So What Should You Do Now?
Here’s the 2015 list, updated:
- Write a paragraph describing what your app does.
- Write a paragraph describing what it is not.
- Research competitors for at least a few hours, including the ones that died. Note what you’d do differently.
- Talk to 10 potential customers. Get at least a few to say they’d pay.
- Build the smallest useful version with Claude Code, Cursor, or a similar tool.
- Budget for the parts AI doesn’t cover: a security review, hosting, support, and marketing.
A real developer still pays off in one place. Before you take anyone’s money or data, pay someone who knows what they’re doing to review your auth, your secrets, and whether the app survives 1,000 users instead of 10.
If you’ve made it this far, you should feel a little less overwhelmed than readers did in 2015. The first version got cheap. The rest still takes work.
AI will happily build your app. It won’t find your customers, protect their data, or answer their refund emails.
Note: the original “So you want to build an App..” is still worth reading. Most of the advice still applies.
