In short
AI makes code faster and cheaper to write. It does not make it safe to run. Where it genuinely helps a small company, and the four things that still decide.
I get asked some version of the same question every week. If AI can write software now, why would a small company still pay people to build and run it?
It is a fair question, and I want to answer it honestly, because we use AI heavily ourselves. Our own products are written with AI coding agents every day, and they run with real users and real payments. So I am not writing this from outside. I am writing it from the middle.
My short answer: AI has changed how fast and how cheaply code gets written. It has not changed what it takes to run software safely. For a small company, that second part is still where things go right or wrong.
What AI really changes
Writing code is faster and cheaper than it was. A first version that used to take weeks can now take days. A founder with no engineering background can get a working demo out of Lovable, Bolt, Cursor or Replit. An experienced engineer with a good AI agent gets through routine work much faster than before.
That is a real change and I think it is a good one. It means more ideas get tested, and fewer small companies have to choose between building something and not building it at all. It also means the price of the first version is no longer the main cost in most projects.
What it does not change
A demo and a system that runs are different things. The hard part was never typing the code. It is everything that comes after: real data, real users, who is allowed to see what, what happens when a step fails, testing, going live, and years of upkeep.
When we review apps that were built mostly by prompting, we tend to find the same kinds of gaps:
- Users who can see or change data that is not theirs, because the checks were done in the browser and not on the server.
- API keys and secrets sitting in the frontend code, where anyone can read them.
- Payments and webhooks (the messages a payment provider sends back to your app) that are not checked as genuine, or that break if the same message arrives twice.
- Every new prompt fixing one thing and breaking two others, because there is no test copy and no tests around the parts that earn money.
- Nobody on the team who can explain what the code does.
None of these show up in a demo. All of them show up with paying users. AI makes it easy to produce code faster than anyone reads it, and code nobody has read is code nobody owns.
Four things that still decide
Ownership
Someone has to be responsible for the system: the code in a repository you own, the accounts in your name, and a person who answers when it breaks. This was true before AI and it is more true now, because there is more code and fewer people who have read it.
Maintenance
Software keeps changing after launch. Libraries release security fixes, providers change their APIs, browsers move on. AI can help write the update. It does not decide to run it, test it on a copy first and watch what happens after.
Data
AI is only as good as what you let it read. Whether it can answer from your own documents depends on whether those documents are organised, current and stored somewhere it can reach safely. Most of the work in a useful AI feature is getting the data right.
Security
AI features bring new risks on top of the old ones. People can try to trick a model with crafted text, a model can reveal information it should not, and an assistant that can take actions can take the wrong one. The OWASP Top 10 for LLM applications is a sober list of these risks and worth reading before you put a model in front of customers.
Where AI genuinely helps a small company
I do not want this to read as a warning label. There are places where AI earns its place in a small company today, and I would encourage most of our clients to try them.
- Answers from your own documents. Manuals, spec sheets, policies, price lists, past answers. An assistant that finds the right passage and answers from it, with a link to the source, saves real time for staff and customers.
- Drafting. First drafts of replies, product descriptions, quotes and reports that a person then checks and sends. The person stays in charge; the blank page goes away.
- Internal tools. Small tools for your own team, sorting incoming requests, pulling details out of emails and forms, filling a spreadsheet. The risk is lower because the users are your own people, and the time saved is easy to see.
The rule I apply to all of them: the model should look things up, not make things up. On Real Estate Club Dubai, one of our own products, the AI advisor cannot answer freely. It uses eight tools that search our own database, and each one returns source links so the answer can cite them. On Humainbox, another of ours, rules score each message first and a language model is only asked when the rules cannot decide. If the filter still cannot reach a decision, the message is delivered. Those choices are not clever. They are just what makes an AI feature safe to leave running.
What I would do as a small company today
- Use AI to build the first version, if you want to. It is cheaper than ever to find out whether anyone wants the thing.
- Before real users, real data or real payments arrive, have someone read the code. Not the demo, the code, the database rules and the hosting.
- Put the code in a repository you own, set up a test copy, and make changes reach the live app only through it.
- Decide who owns the system every month. It can be you, a hire or a team like ours, but it has to be a named person.
- Add AI features where they answer from your own data or save your team time, and keep a person in the loop for anything a customer sees.
If you already have an AI-built app with users, our page on fixing a vibe-coded app has the checklist we run first. You can keep prompting your own prototypes after that; the point is that what reaches production is safe.
If you want to talk it through, write to us through the contact page.
FAQ
Frequently asked questions
Tagged
