TL;DR: AI has made the first 80% of a business app genuinely easy to produce and has changed almost nothing about the last 20%. That last stretch is where the cost always lived. Knowing which part of the problem you're actually facing tells you whether to build it yourself, hire someone, or start with AI and hire later.
A year ago the honest answer to "can I build this myself" was almost always no.
It isn't anymore, and any agency telling you otherwise is protecting its own revenue. You can describe an application in plain English and get working software back. For a genuinely large class of business problems, that is now the correct starting move.
What has not changed is the part nobody sees in the demo.
The 80% that got easy
Producing a first working version. Screens, forms, a database behind them, a login. Two years ago that was weeks of paid work. Now it is an afternoon and a subscription.
If your problem is a spreadsheet that three people share and keep overwriting, you should try to build it yourself before you hire anyone. Seriously. Worst case you lose a weekend and arrive at a developer with a working prototype, which makes you a dramatically better client because you now know what you actually want.
The prototype is worth more than the code. Most projects go wrong at the requirements stage, and building something badly is the fastest way to discover what you should have asked for.
The 20% that didn't
Here is what the demo doesn't show you.
Somebody else's data. The moment your app talks to your accounting software or your supplier's system, you are negotiating with an interface you don't control, which may be badly documented and may change without telling you.
What happens when two people click at once. This sounds like an edge case. It is not. We had to fix exactly this in our own platform: two people approving the same document simultaneously could produce two approvals where there should be one. The fix was making the update conditional on the current status so the second attempt changes nothing and reports a conflict. AI will not write that unless you know to ask, and you only know to ask if you have been bitten.
Security you can't see missing. Working software and safe software look identical from the outside. The gap only becomes visible when it costs you.
What happens in month seven. Dependencies get security patches. Browsers change rendering. The service you built on changes its pricing. Software does not finish; it runs.
That is why our own build carries 88 test files and why 137 features have a written threat model produced before the code. Not because it's fun. Because 907 commits into a platform, the only thing that lets you change one part without breaking another is having proven the other parts still work.
So which should you do?
Build it yourself when the tool is internal, the data isn't sensitive, nothing critical breaks if it stops for a day, and you're the main user. Equipment logs, internal checklists, simple trackers. The category where a spreadsheet is the current answer.
Hire when it touches customers, money, or records you're obliged to protect. When it must integrate with systems you don't control. When downtime costs real money. Or when it's going to outlive your interest in maintaining it, which is the one people misjudge most.
Start yourself, then hire when you're unsure. Build the rough version, use it, find out what you actually need, then hand a working prototype and a real list of requirements to someone who can harden it. This is the cheapest path to a good outcome, and it's the one we'd recommend to most people reading this.
The trap in the middle is building something yourself that succeeds. It gets used. It becomes load-bearing. And now the business depends on software with no tests, no backups anyone has verified, and one person who understands it. That is a worse position than either buying properly or staying on the spreadsheet, because the failure arrives later and with more attached to it.
What a vendor should tell you and usually won't
If your problem is solved by an existing product, buy the product.
Custom software earns its cost when the thing you do differently is the thing that makes you money, or when a workaround is eating real hours every week. Not when you dislike an interface.
We turn down work on this basis, and it is not charity. A build that shouldn't have happened is a client who resents the invoice.
The version of that advice worth keeping: name the specific thing your current tools structurally cannot do. If you can't, the answer is probably better configuration of what you have. If you can, and you've been working around it for over a year, the maths usually favours building.
Does AI change the vendor's price?
It changes the mix more than the total.
Writing code was never the expensive part. Understanding your process, integrating with systems you don't control, testing, and supporting it are what fill a budget, and AI has moved none of those much. Treat a quote that is dramatically below market on the basis of tooling with suspicion, and ask what it excludes.
Where it does change things is speed of iteration. Showing you a working version in week one instead of week six means you correct course early, and early correction is where most of the waste in software projects lives.
Frequently Asked Questions
If I build the first version with AI, can a developer take it over?
Usually, with a caveat worth checking up front. Ask a prospective developer to look at what you've built before quoting, and ask directly whether they'd extend it or start again. Both answers can be legitimate. What you want is the reasoning, not the verdict, and you want it before you're committed.
What if the AI tool I built on changes its pricing or shuts down?
This is the real risk with no-code and AI platforms, and it's worth resolving before you depend on one. Ask two questions: can you export your data in a usable format, and can the application run somewhere else. If either answer is no, you are renting the business process, not owning it.
How do I know when my self-built tool has outgrown me?
Three signals. Someone other than you needs it to work on a specific day. It holds data you'd struggle to reconstruct. Or you've started avoiding changes because you're afraid of breaking it. That last one is the clearest, and it usually shows up first.
Should I tell a developer I built a prototype myself?
Yes, and lead with it. A working prototype is the most useful brief you can bring. Any developer who treats it as an insult rather than a specification is telling you something useful about how the project would go.
Is there a size below which hiring anyone is a waste?
Roughly, if the process involves one person and no customer data, and you can describe it in a paragraph, try it yourself first. The cost of trying is now low enough that not trying is the expensive choice.
The question isn't whether AI can build your app. Increasingly it can build a version of it. The question is what happens on the day it breaks and whether that day matters.
If you're unsure which category you're in, that's a short conversation rather than a project. See custom app development, our AI services, or start a discovery call. If you're leaning toward hiring, the eight checks for vetting a developer and what custom development actually costs are the next two things to read.
Sources
- ClickWerxs platform repository — 907 commits between 6 April and 15 July 2026, 137 STRIDE threat models, 88 test files, concurrent-approval conflict resolved by predicating the status update on current status. First-party operator data.
ClickWerxs builds custom software and AI workflows for businesses and earns revenue from those engagements. This post reflects our direct experience building and operating our own platform, not independent third-party research. This is operator opinion and not legal or financial advice.
Kaleb Dickhaut — Founder, ClickWerxs. Kaleb built ClickWerxs from the ground up, from payment processing ISO to the Command Center platform to the AI SEO methodology the blog runs on. He has onboarded hundreds of small businesses onto payment and CRM systems. linkedin.com/in/kaleb-dickhaut