Will AI Build Me an ERP When I'm Not a Developer? — The Honest Answer and the Security Risks

It happens most weeks now. A business owner sits across from you, pleased with himself, and says: "I don't need to buy a system — I tried AI and it built me an invoice screen in an hour. I'll have someone here finish it and save a hundred thousand pounds."

Six months later he is back. Not pleased this time.

This article is not going to tell you AI is bad at writing code. That would be untrue, and you would work out it was untrue yourself. What it will do is show you exactly where the line sits — where AI genuinely excels, and where relying on it puts your company and your data at a risk you cannot currently see.

First, an admission: we use AI every day

So this is an honest conversation: we use AI in our own work at Hunt ERP, daily. It saves us real time and turns week-long jobs into day-long ones.

So we are not going to tell you the tool is bad. The tool is excellent.

There is exactly one difference — and that difference is the whole story:

We are developers. The person reading what the AI produces is a developer who can say "no, that part is wrong" before it ever reaches a customer's data.

AI does not get things wrong because it is unintelligent. It gets things wrong because it answers the question you asked, not the question you should have asked. And if you are not a developer, you do not know that question exists.

Before we go on: some things you genuinely should build yourself

To be completely fair — there are things where building it yourself with AI is absolutely the right call and will save you real money:

• A company website — build it yourself, honestly. If it breaks, nothing happens, and you fix it in an hour
• A landing page for a campaign — excellent use
• A small internal tool — a quote calculator, a task tracker, a KPI board
• A prototype to clarify what you actually need before you buy — genuinely smart
• Extra reports on top of a system you already have — great

The difference between those and an ERP is simple but decisive: if your website goes down, you lose visits. If your financial records are wrong, you lose the company.

Why an ERP is a different case: it is not "a program"

This is where the misunderstanding starts. People think an ERP is a set of screens. It is not. An ERP is your company's financial and legal memory. It determines:

• What the product you are selling actually costs
• Who you owe, how much, and who owes you
• Exactly what is in the warehouse right now
• Who did what, and when
• The tax return you will sign your name to

A bug on your website? You fix it and move on. A bug in your ERP? It compounds silently in your data for years, and by the time you find it, every decision you made on those numbers was wrong.

Try it yourself

Ask any AI tool: "build me a sales invoice screen". You will have it in minutes and it will work. Now ask yourself these — each one is an accounting decision, not a programming one:

1. When you sell an item, how is its cost relieved? FIFO or weighted average? That choice changes your reported profit
2. A customer returns goods two months later and the price has moved — at which price? And how do you reverse the entry?
3. Two cashiers sell the last unit in the same second — who wins? How do you prevent negative stock?
4. ETA rejects the invoice after the customer has left with the goods — now what?
5. At year-end close, what closes and what carries forward?

AI will answer all of these if you ask. The problem is that you will not know to ask.

The 80% trap — the most dangerous part of this

There is a well-worn line in software engineering: "the first 80% takes 20% of the time, and the remaining 20% takes the other 80%." With AI, that first 80% now takes about 2% of the time. That is what fools people.

Seven things that break the moment real data arrives

1. Product cost comes out wrong — you sell at a loss believing you are profitable

The most dangerous one, and it does not show quickly. If the costing method is wrong, your price is built on a wrong number. You can spend a year selling below true cost while the reports tell you that you are winning. See how many accounting decisions sit behind a single figure.

2. No audit log — internal theft becomes undetectable

An AI-built system will have a delete button, because that is normal in any application. In an ERP it is a disaster. A company lost EGP 2.1 million to exactly this.

3. Numbers duplicate under load

Invoice 1050 issued twice to two customers, because two people hit save in the same instant. It is called a race condition, and avoiding it takes an understanding of database transactions and locking.

4. ETA rejects your invoices

The platform does not accept arbitrary JSON — it wants a UUID, an accredited digital signature, GS1/EGS codes and an exact format. Fines run to EGP 50,000. The full requirements.

5. The backup turns out to be empty

Everyone takes backups. Very few ever test a restore. The most painful case we have seen: a full year of backups, and the day they were needed, every file was zero bytes.

6. It slows to a crawl as data grows

Perfect on 1,000 items. At 50,000, every click takes 30 seconds. See what it takes to run 300,000 SKUs at speed.

7. Nobody but you can carry it forward

The employee who was pasting the code has left. No documentation, nobody understands its structure, and nobody dares touch it. Your company is now hostage to a system no one understands.

🔒 The part nobody talks about: security

This is the most serious section in this article, and it is the one a business owner does not know exists. That is precisely what makes it dangerous.

When you build a system yourself, you are not just writing code — you are opening a door into your company from the internet. If nobody knows how to close that door properly, the people looking for it will find it. Not because they are targeting you: because automated scanners sweep the entire internet around the clock looking for open doors.

A brand-new server on the public internet starts getting probed by automated scanners within minutes of coming online. Not weeks — minutes.

Twelve security risks in a system built without a developer

1. The database is exposed to the internet

The single most common mistake. The database gets configured to "just work" — meaning it listens on every address (0.0.0.0) with no firewall. Anyone, anywhere, can connect and pull your entire customer list, pricing and accounts.

2. Passwords written into the code

AI puts the database password in the code so it runs. Then you push the code to GitHub to "keep it safe". There are bots dedicated to scanning GitHub that find those keys within minutes of the push.

3. The .env file readable from a browser

Deploy it the wrong way and anyone can type yoursite.com/.env and read every secret you have. It is one of the most heavily scanned paths on the internet.

4. The site runs without HTTPS

Which means your staff's passwords travel the network in the clear. Anyone on the same Wi-Fi can read them. This is not theoretical — we see it constantly.

5. SQL injection

AI writes the happy path — the case where the user types what they are supposed to. But when someone types a crafted string into a search box instead of a word, they can drop a whole table or extract everything. Protection comes from knowing the risk exists and asking for it.

6. Change the number in the URL, read someone else's data

It is called IDOR. Your link is /invoice/1050 — change it to 1051 and you are reading another customer's invoice. The system checked that you were logged in but forgot to check the invoice was yours. The distinction between authentication and authorisation is obvious to a developer and invisible to everyone else.

7. File uploads blow the door off

An "upload product image" screen, if it is not validated properly, lets someone upload an executable instead of an image — and take the whole server. One of the most severe and most easily exploited flaws there is.

8. No limit on login attempts

A bot trying ten thousand passwords a minute against your login screen. Without rate limiting, it has unlimited time.

9. Passwords stored badly

Stored as plain text or weakly hashed, anyone who reaches the database has every one of your employees' passwords — many of which they also use on personal email and banking.

10. Debug mode left on in production

Errors display to the visitor in full detail: file paths, table names, sometimes the credentials themselves. A single error page hands an attacker a complete map.

11. Outdated libraries nobody updates

Every system uses dozens of third-party libraries. Vulnerabilities are found in them constantly and fixed by updates. With nobody responsible for tracking that, your system sits exposed to flaws that are published and known worldwide.

12. Ransomware

Put all of the above together: someone gets in, encrypts your data, and demands payment. Without a tested backup held away from the same server, your business stops.

"AI will deploy it and handle the passwords"

No. This is a fundamental misunderstanding worth correcting directly.

AI writes text. It does not hold your server, and it does not do any of this:

No tool, however capable, does any of these on its own. This is ongoing work, not a step that finishes.

And the legal responsibility is yours

In Egypt, the Personal Data Protection Law (No. 151 of 2018) obliges any organisation holding personal data to protect it with appropriate measures. Your employee and customer records fall under it.

If data leaks from a system you built yourself:

• The responsibility is yours, not the AI vendor's
• No company carries it for you
• No contract or insurance covers you
• And the damage to your reputation with customers is not recoverable

When you buy a system from a vendor, part of what you are paying for is somebody else carrying that responsibility with you — under a contract, with a team, and with continuous security updates.

💡 And the hard truth: the code is the cheapest part

Suppose, for argument's sake, that AI wrote you perfectly correct and perfectly secure code. You still would not have a system.

Because code is the last step, and the cheapest one. What comes before and after it decides whether the system succeeds or gets abandoned.

1. The concept and functional design — "what am I actually building?"

Before a line of code, somebody has to decide: which screens does a distribution company need? How does the document cycle run from customer order to collection? What gets recorded and what does not? Who approves what?

Those answers are not imagined. They come from having seen 200 companies and knowing which thing always goes wrong in this sector. Ask AI to "build a distribution system" and you will get a reasonable generic outline — but it will not know your reps take stock on consignment and settle at end of day, or that a set of customers return 30% of every shipment.

2. The chart of accounts and the document cycle

The most consequential item after security. The chart of accounts is the foundation of every number the system will ever produce. Get it wrong at the start and:

• Your income statement produces figures that tell you nothing
• Cost centres will not tell you which branch is profitable
• The tax return needs manual work every month
• And fixing it a year later means reposting every entry

That is the work of an experienced accountant who knows Egyptian standards — not the work of a tool. See the income statement broken down and how many accounting decisions sit behind each line.

3. Design judgement — not a luxury, it is money

Your cashier will use the sales screen 300 times a day. If that screen has two more clicks than it needs, that is 600 wasted clicks daily — hours a month of your staff's time.

More dangerous still: a system that looks poor or confuses people gets resisted by staff. They fall back to Excel, they record things later, they leave fields blank. And the best system in the world, used badly, is no system at all.

AI will produce a screen that "looks nice". The gap between "looks nice" and "comfortable for someone using it eight hours a day" is an entire discipline called user experience.

4. Training — the part that decides success

This is what separates projects that worked from projects that failed, and almost everyone underestimates it.

Someone has to sit with the accountant and walk them through the new cycle. And the storekeeper. And the sales rep. And answer their questions when they get stuck, and review their work through the first month and correct it.

If you built the system yourself — who trains them? You? While you are not certain the system works correctly in the first place.

5. Continuity — the system has to grow with you

Next year you will open a branch, or add a production line, or the tax rules will change. The system is supposed to evolve with you. That needs somebody present and accountable — not a project that finished and ended.

Code might be 20% of a system's value. The other 80% is the concept, the accounting design, the usability, the training and the continuity. AI helps with the 20%.

The real cost nobody adds up

A mid-sized company, 25 staff:

Against a ready system at EGP 1,000/month = EGP 12,000 a year, running from day one, ETA-compliant, secured and monitored.

The story that repeats in the same order

Month 1: "Incredible! I built invoicing and inventory in a week."

Month 3: "A few issues, but we'll sort them. The warehouse shows odd numbers sometimes."

Month 6: "The accountant says the figures don't reconcile. We keep an Excel alongside it to be sure."

Month 9: "The person who was building it has left. Nobody understands any of it."

Month 12: "We want to buy a system. But last year's data — we have no idea how to move it."

Notice the painful part: month 12 is harder than month 1. Had he bought at the start, he would have migrated from a tidy Excel file. Now he is migrating from an inconsistent database whose logic nobody understands.

Use AI well — it will help you enormously

The message is not "don't use AI". It is "use it where it belongs":

• Have it write your requirements document — before you call any vendor, sit with it and write out what you need in detail. It will save you months
• Have it review the proposal you received — paste it in and ask "what is missing? what should I be asking?"
• Have it analyse your reports — give it your sales data and ask about patterns and anomalies
• Have it clean your old data before migration
• Have it explain the terminology — unclear on FIFO or cost centres? Ask
• Have it build your website — go ahead, that is exactly where it belongs

Let it strengthen your decision, not replace your company's foundations.

Twelve questions to ask yourself first

Answer "no" to three or more and building it yourself is the wrong call:

1. Do you know the difference between FIFO and weighted average, and its effect on your profit?
2. Do you know what has to happen at year-end close?
3. Do you understand what a database transaction is and why it matters?
4. Have you actually restored a backup?
5. Do you know the difference between authentication and authorisation?
6. Do you know how to verify your database is not exposed to the internet?
7. Do you know where passwords are stored and how?
8. Who patches the libraries every month?
9. What is your plan if the person building it leaves tomorrow?
10. Do you know the ETA requirements and how to handle a rejection?
11. If data leaks — who is legally responsible?
12. If the system is down for a day at month-end — what does that cost?

The bottom line

AI is a genuinely powerful tool — we use it every day. But there is a fundamental difference between "it can write the code" and "it can carry responsibility for your financial data and its security".

The first is a question of skill, and AI has become genuinely good at it.
The second is a question of sector experience, legal responsibility, continuous security work and continuity — and that does not live in a tool. It lives in a team that has worked with 200 companies and seen every way this goes wrong.

You are not buying code. You are buying somebody else carrying the responsibility that your numbers are right and your data is safe.

Build your own website. Build your own small tools. But your financial system of record — put someone accountable behind it.

And if you are at month six of that story right now — you do not have to reach month twelve. The earlier you move, the easier and cheaper your data migration will be.

Book a live demo and we will look together at what you have built, what is worth keeping, and what needs to be rebuilt properly. And if it turns out yours is one of the cases where building it yourself is right — we will tell you so.