When to hire an expert
vs vibe-code it yourself.
You can now build a working app by describing it in English. Some of those apps you should build yourself. Some you absolutely should not. Here is how to tell.
A few years ago, getting software written for your business meant hiring a developer or paying an agency. That is no longer the only option. A small business owner with no coding experience can now describe what they want in English and get a working app back the same afternoon. The tools that do this go by various names; the shorthand most people have settled on is “vibe coding.”
Some of what these tools produce is good. Some of it is disastrous. The question is not whether they are useful. The question is when to use one and when to reach for a human instead. This is a short guide to deciding.
What vibe coding actually does well.
Prompt-to-app tools are excellent for a specific band of problems. If your project fits the band, build it yourself. You will save money and you will learn something.
- A one-off internal tool you will use for a month, maybe six. The build cost matters more than the maintenance cost because there is no maintenance.
- A prototype you will show a client or a collaborator so they can tell you what they actually want. You are going to throw this away and build it properly later.
- A static page, a form, a small calculator, a checklist. Anything small with no database, no accounts, no integrations with your real tools.
- Something you want to use alone, on your own machine, with nothing at stake if it breaks.
- Anything where the data never leaves your computer and no client will ever see the thing.
If the project fits this list, hiring someone is overkill. Describe what you want, iterate on it for an afternoon, move on.
Where vibe coding quietly fails.
The problem is not that these tools cannot produce code. They can. The problem is that the code they produce, by default, rots in specific ways:
-
Everything in one file.
A thousand lines. Two thousand. Five thousand. Whole app in a single file. Fine while you are adding new things. The moment you want to change one small part, the tool has to rewrite the whole file and something else breaks. Nobody, human or AI, can make a surgical fix.
-
No structure to come back to.
The code has no sensible separation of concerns, no tests, no documentation of why choices were made. A new builder looking at it six months later will not be able to tell which parts are important and which are accidents.
-
Brittle on real data.
Prompt-to-app demos work beautifully on the three example rows the tool generated for you. They fall over the first time your real data has a field with a comma in it, or a missing value, or an unusual date format.
-
Locked in to the tool that built it.
Many of these tools host the finished app themselves and make it painful to take the code elsewhere. If the tool changes its pricing, or goes out of business, or locks your account, you lose the thing.
-
Plausibly wrong.
The output looks confident and clean. It is often subtly incorrect in ways that only become obvious when a customer or an auditor notices. Software that looks right and is wrong is worse than software that obviously does not work.
Hire someone when any of these apply.
- A customer will interact with the thing. Their first impression of your business is now partly your software’s problem.
- The thing touches money. Quotes, invoices, subscriptions, payroll. A quiet bug here is expensive in a way that matters.
- The thing touches private data. Client notes, medical records, immigration files, HR. Where the data lives and who can see it is a real question, and vibe-coded apps rarely get this right.
- You will depend on it for more than six months. Long-running software needs to be possible to change. Vibe-coded single-file apps are not.
- You need it to connect to tools you already use (your email, your calendar, your accounting app) in a reliable way. Integrations are where prompt-to-app tools break most often.
- You cannot afford for it to look amateur. Software that feels off communicates more about your business than the marketing copy next to it.
The honest middle path.
For most small business owners, the best answer is not one or the other. It is both, used sequentially:
Use a prompt-to-app tool to sketch the thing. Build a rough version yourself, in an afternoon, with no plan to keep the code. This teaches you what you actually want before you pay anyone. Most first ideas change a lot once you see them working.
Then hire someone to build it properly. Send the sketch to a builder along with a short brief. The sketch tells them what it should do. The brief tells them what your business needs. They build it as real software, with real structure, on your computer, with you owning the code.
The sketch takes an afternoon. The proper build takes a few weeks. The combined cost is lower than hiring without a sketch, because you are not paying a professional to figure out what you want. You already know.
Warning signs you made the wrong call.
If you vibe-coded something and should have hired someone, you will see these within three months:
- You are afraid to change anything because the last change broke three other things.
- You have a workaround for a bug you cannot find. The workaround has been there for weeks.
- You are keeping a second copy of your data “just in case” the app loses it.
- You are paying the prompt-to-app tool a monthly fee that is higher than a proper build would have cost, once.
- A client saw the thing and said something polite but puzzled.
If you hired someone and should have vibe-coded it, the sign is even simpler: you are three weeks in, you have spent a few thousand dollars, and what was delivered is a thing you could have described in a single sentence.
The short version.
Small, private, short-lived, or throwaway? Build it yourself. Customer-facing, money-touching, private-data-handling, or something you will run a business on? Hire someone. Most small businesses should do both, in that order, for any significant project.
If you want help working out which side of the line your project falls on, email below. I will tell you honestly, even if the honest answer is “you can do this one yourself.”