More and more organizations are experimenting with Claude Code, Cursor, Lovable, Bolt, and other tools. Often this helps quickly see an idea's potential and better understand what solution is actually needed.
However, there's a significant difference between a working prototype and a reliable business system.
A system can have login, a database, document uploads, and a neat user interface, but at the same time have risks that are easy to miss without technical experience.
For example:
improperly managed access
publicly accessible documents
unreliable backups
incorrect financial calculations
unclear data storage location
dependency on a single employee or single account
The purpose of this article is not to stop such initiatives, but to help organizations recognize in time the moment when a prototype is worth professionally evaluating before starting to use it with real data, employees, or clients.
Next – 12 key things worth checking.
1. Check that uploaded files are not publicly accessible
This is one of the most dangerous and easiest to overlook mistakes.
The system may require login for a user to see a list of documents, but the file itself may be stored in a public directory. In this case, a contract, invoice, or other document can be opened by anyone who has a direct link.
How to check this
Open a document, copy its link, and try to open it:
logged out of the system
in a private browser window
on a different device
If the document opens without logging in, it is most likely not properly protected.
It is also necessary to check whether one logged-in client can change the document number in the link and open a file belonging to another client.
2. A login screen doesn't mean that access controls are working correctly
Authentication establishes who the user is. However, the system must still determine what specific data they can view and what actions they can perform.
For example:
an employee should only see data from their department
a client – only their company's orders
a manager should not be able to modify administrative settings
a former employee can no longer log in
Simply hiding a button is not enough. The system must verify permissions every time data is accessed, modified, downloaded, or deleted.
Testing should cover not only what a user should be able to do, but also what they should not be able to do.
3. Don't use real sensitive data when experimenting
To quickly test a system, it's tempting to upload a few real contracts, invoices, or customer data.
However, an experimental system may lack proper security, and uploaded information can end up in:
external AI models
system logs
error monitoring tools
poorly managed data storage
third-party service provider systems
Use fictitious or anonymized data for testing. Real data can only be uploaded with explicit knowledge of where it is stored, to whom it is transmitted, and who can access it.
4. Do not store passwords and API keys in code
Secret API keys are used for integrations with AI, email, payments, accounting, or other systems.
When developing with AI, it is very easy to write such a key directly into the code to make the integration "just start working." However, it can end up in a public code repository, system logs, or be visible in the browser.
A leaked key can allow:
use of your paid services
sending emails on behalf of the company
access to customer data
perform actions in other systems
cause significant expenses
Secret data must be stored in dedicated secure configurations. If a key has already been exposed, simply deleting it from the code is not enough – the key must be revoked and replaced with a new one.
5. Maintain backups and actually test recovery
A system can run without issues for months until one incorrect change deletes customer data, documents, or order history.
It's not enough to know that backups "should be made."
You need clear answers to:
how often they are made
where they are stored
whether both the database and files are backed up
how long backups are retained
who is responsible for recovery
whether recovery has ever been tested
A backup that no one has ever attempted to restore is not yet a reliable protection plan.
6. Separate the testing system from the live environment
New functionality should not be tested in a system that is already working with real data.
One experiment can:
send a real email to a client
create an invoice
change the order status
transfer incorrect data to accounting
delete documents
stop the system from functioning
The testing environment should use test data, and payments, emails, and other integrations must operate in testing mode.
7. Check the business logic, not just whether the button works
The system can technically function flawlessly, yet calculate incorrectly.
For example, it can:
incorrectly calculate VAT
apply the wrong discount
confuse prices with and without VAT
fail to evaluate minimum order quantity
allow exceeding the customer's credit limit
bypass mandatory confirmation
Such errors often don't trigger any technical alerts. The system simply produces an incorrect result.
Critical calculations and rules must be verified against pre-prepared real scenarios, including non-standard and edge cases.
8. Ensure the system logs important actions
When something changes in the system, it must be possible to determine:
who performed the action
when it was performed
what was changed
what was the previous value
whether the action was performed by a person, AI, or another system
Without action history, it may be impossible to determine who changed the price, deleted a document, or granted administrator rights.
However, logs must not store passwords, API keys, or other redundant sensitive information.
9. Plan how departing employees' access will be revoked
In custom-built systems, accounts are often created quickly, but reviewing them later is forgotten.
This leaves in the system:
former employees' accounts
old administrators
external partners' access
shared team passwords
API keys with unclear purpose
Even before launch, it must be clear who creates accounts, who grants administrator rights, and who immediately revokes access when an employee leaves.
Multi-factor authentication should be used for administrators, and each person should have an individual account.
10. Evaluate not only how the system works now
A solution may work perfectly with three users and a few dozen records, but start to struggle as more data accumulates.
As the system grows, it may become apparent that:
search becomes very slow
a report blocks the entire system
files fill up storage
a single user generates thousands of API requests
external service costs become uncontrollable
concurrent actions corrupt data
It's necessary to anticipate the number of users, data and files in advance, set usage limits, and configure cost alerts.
11. Ensure the system belongs to the organization
The system should not remain in the personal account of the individual employee who created it.
The organization must know:
where the source code is stored
who controls the domain
who has access to the server and database
in whose name external service accounts are created
whether data can be exported
whether another team could take over system maintenance
A personal account, personal payment card, or a single employee holding all information creates significant dependency.
12. Recognize the moment when a prototype becomes a business system
The biggest mistake is to evaluate a solution as a small experiment simply because it was built quickly.
A professional technical assessment becomes necessary when the system:
stores customer or employee data
allows uploading internal documents
is used by external clients
has different access levels
integrates with accounting or other critical systems
processes payments or generates invoices
performs important financial calculations
becomes part of daily operations
must operate reliably and without interruptions
From this moment on, it's no longer just a prototype. It's a business system for which the organization is responsible for security, data, and operational consequences.
15 questions you should ask before launching the system
Can a logged-out user access uploaded documents?
Can one client see another client's data?
Where is data and documents stored?
Is real data used for testing?
Who is this data transferred to?
What would happen if important information was accidentally deleted?
Has recovery from backup been tested?
Who has administrator rights?
How are departing employees' access rights revoked?
Are passwords and API keys not in the program code?
Can the testing system perform real actions?
Is the history of important changes logged?
Can all of your data be exported?
Who will notice if the system stops working?
What's the biggest damage a single error could cause?
If there are no clear answers to these questions, the system should not yet be used for critical business processes.
Summary
AI tools today can very quickly create a convincingly looking and seemingly working solution at first glance. However, this is exactly what can create a false sense of security.
Most of the most dangerous problems are not visible in the user interface. The system may display the correct buttons but improperly restrict access. It may have login functionality but store documents publicly. It may accurately execute a described formula, even though the formula itself is incorrect from a business perspective.
Therefore, an independently created prototype should not automatically be considered a production-ready business system.
If a solution starts using real data, connects with other systems, becomes critical to employees, or opens up to customers, it should be evaluated by experienced technology specialists before launch.
Such an evaluation is not an attempt to stop the idea. Its purpose is to help preserve what's valuable in the prototype and eliminate risks that could later cost much more than a professional review at the very beginning.