You describe your business, choose a style, and watch AI put a website together. The pages look polished. The buttons respond. It seems ready to share. Why pay an engineer for something you can now build yourself?
An AI website builder can be a sensible starting point. The decision depends on whether you can check the result, manage its data, handle failures, and maintain it after launch. A low setup price does not tell you who will do that work.
Imagine a service business with a request-a-quote form. Visitors see a success message, but their requests are never saved. The owner discovers the problem when a prospective customer asks for an update. This is an illustrative scenario, not a client incident. A convincing interface does not establish that the business process behind it works.
I am Dicky Ibrohim. I offer website development and repair with direct discussion of your business needs and the work involved. If you already have an AI-built website, we can use it as a starting point. Its condition determines whether focused improvements or a larger change are worth considering.
Can AI replace a website developer?
AI can help produce code, content, and early designs. For a straightforward information site, an appropriate tool can reduce the work involved. Decisions about what data to store, who may access it, and how the service will recover still need to be made and tested.
It helps to distinguish three uses of AI:
| How AI is used | What needs attention |
|---|---|
| Generating code or page designs | Functional correctness, code security, usability, and maintenance |
| Giving an agent access to files, servers, or services | Permissions, possible actions, and approval for changes with significant consequences |
| Providing visitors with a chatbot or another AI feature | Model inputs, instruction manipulation, usage costs, and actions the feature can trigger |
A static website created with AI assistance does not necessarily run an AI model when someone visits. Chatbot risks and model usage charges apply where those features or services exist. Human-written software also needs appropriate review.
What does research tell us about AI-generated code?
A study by Perry and colleagues, published at ACM CCS 2023, involved 47 participants completing security-related programming tasks. In that setting, the AI-assisted group produced less secure code overall while being more confident about its security. Most participants were university students, and the model was an older version of Codex. These findings are limited to the study conditions, not a measurement of websites in 2026. Authors’ paper, published at ACM CCS.
Research presented at USENIX Security 2025 examined 16 code-generating models and found recommendations for software packages that did not exist. Such names can create a dependency risk if someone later publishes a malicious package under the suggested name and a user installs it without checking. This establishes a risk mechanism, not a claim that every AI package recommendation is false. USENIX research on package hallucinations.
For a business owner, these findings support a practical requirement: ask for verification you can understand. A confident answer, code that runs, and a finished design are different from evidence that the important cases have been checked.
Risks 1 to 8: the website looks finished, but its foundations need checking
The following 20 risks help you assess the features your website actually uses. They are not an exhaustive catalogue of failures, and not every risk applies to every project. The business examples are illustrations to make the decisions easier to understand.
1. Confidence arrives before evidence of secure code
An AI message announcing completion can feel like a review result. It is not independent verification. Ask which functions were tested, which failure cases were examined, and which findings remain unresolved before relying on the site for business.
2. The design gets your business rules wrong
Suppose a change to an appointment requires staff approval, but the website confirms it immediately. The interface may do exactly what its code says while still breaking the business process. OWASP includes business logic weaknesses within insecure design. Engineering support can help turn your requirements into explicit rules and testable outcomes before the feature goes live. OWASP: Insecure Design.
3. People can reach records they should not access
Hiding an admin button is not sufficient access control. The system needs to check permissions when it processes requests, including whether the person may read or change a particular record. Missing checks can expose customer information or allow unauthorised changes. This matters wherever the website separates access between customers, staff, or administrators. OWASP: Broken Access Control.
4. Sign-in works, but account recovery and sessions are weak
The login screen is only part of account management. Password recovery, credential protection, and ending a session after logout also need attention. Errors in these areas can create routes to account takeover. The checks should reflect the privileges and information available through each type of account. OWASP: Authentication Failures.
5. User input is treated as an instruction
Forms, search tools, and comments accept information from outside the application. Incorrect handling can let that input affect database commands or content executed in a browser. Injection and cross-site scripting risks need review wherever input is processed or displayed, including when it differs from what the developer expected. OWASP: Injection.
6. HTTPS is mistaken for complete data protection
HTTPS protects communications on connections that use it. Protecting stored information and managing encryption keys involve additional work. A form can use HTTPS while storing sensitive details inadequately. Establish what information is necessary, where it is kept, and how it is protected. A secure connection indicator is not a complete assessment of the website. OWASP: Cryptographic Failures.
7. Development settings reach the live website
Detailed error messages, overly broad storage permissions, or default accounts can reveal information and access that should be restricted. A code review does not cover every hosting or service setting. Review the live environment’s configuration against the website’s actual needs before publishing it. OWASP: Security Misconfiguration.
8. Dependencies are installed without checking their origin or support
Beyond packages invented by AI, real components may be unmaintained or vulnerable. Their distribution and update processes can also introduce risks. Know which components the website uses, where they come from, and who follows security changes. Every additional package adds something that may need maintenance. OWASP: Software Supply Chain Failures.
Risks 9 to 12: AI access, information, and spending need boundaries
9. Sensitive information is shared while asking AI for help
Pasting logs, customer records, or complete configuration files into an AI tool may disclose information the task does not require. Storage and processing policies vary across products and account settings. Use sample or redacted data where appropriate, and check what you are allowed to share. Do not assume that every service handles information on the same terms. OWASP: Sensitive Information Disclosure.
10. An agent receives more authority than its task requires
The stakes change when a tool can modify servers, delete files, or act within business services. A mistake can become an operational change rather than an incorrect answer. Limit access to the work involved and require approval for actions with significant consequences. This applies to agents with those capabilities, not every conversation with AI. OWASP: Excessive Agency.
11. External instructions redirect an AI feature
An AI feature reading messages, documents, or external pages may encounter instructions intended to redirect its task. This is prompt injection. The consequences depend on the information and capabilities available to the system. A static site does not acquire this risk simply because AI wrote its code; establish whether a model or agent processes untrusted material. OWASP: Prompt Injection.
12. Service usage grows without clear spending controls
Excessive API requests can consume capacity and increase operating costs. If visitors use a metered AI feature, decide on quotas, access limits, and what happens when those limits are reached. A subscription to a development tool is separate from charges for services used by the live website. OWASP API Security: Unrestricted Resource Consumption.
Check whether a budget setting only sends an alert or actually limits usage. Google Cloud documentation, for example, distinguishes alerts-only budgets from budgets with a spend cap. The configuration and covered services need to be understood. Google Cloud budget documentation.
Risks 13 to 16: the harder work can begin after launch
13. The website handles service failures badly
Lost connections, delayed email delivery, and incomplete data need sensible failure handling. In the form example above, the success message should reflect what the system actually completed. Test failure conditions and agree what visitors will see and how recovery works. OWASP describes security and reliability problems caused by mishandled exceptional conditions. OWASP: Mishandling of Exceptional Conditions.
14. Problems go unnoticed and backups are difficult to restore
Activity records need appropriate review and alerts if important events are to be noticed. They also need to avoid exposing sensitive information. OWASP: Security Logging and Alerting Failures.
Backups serve a different purpose: providing a copy for recovery. NCSC guidance stresses knowing how to restore a backup and checking that it contains the important data. For a business website, agree what is backed up, who can restore it, and what recovery testing is needed. NCSC backup guidance.
15. Nobody owns maintenance after handover
Someone still needs to make decisions when components change, support ends, or a problem is reported. The UK Government’s Software Security Code of Practice includes communicating support and maintenance arrangements to customers. This voluntary guidance offers useful questions for assessing a service proposal; it does not imply that a provider is certified. GOV.UK software security guidance.
Agree who receives reports, service hours, included work, and extra charges. Handover to your own maintainer may be sufficient. If you do not have one, discuss ongoing support before launch. The article on websites failing after security updates explores that situation further.
16. Moving away from a platform requires substantial work
Convenience at launch needs to be weighed against exporting data, moving features, and keeping the service running elsewhere. GOV.UK guidance on technical lock-in considers the benefits of managed services alongside switching costs and difficulty. Those principles are useful when evaluating website platforms, although the guidance concerns cloud services. GOV.UK: Managing Technical Lock-in.
Custom websites can also depend on frameworks, licences, and a maintainer’s knowledge. Ask for written details about access, documentation, and available handover arrangements. The guide to website vendor dependence can help you prepare those questions.
Risks 17 to 20: a published website may still let customers down
17. Persuasive content contains unchecked claims or assets
AI can produce inaccurate product details, invented testimonials, or material whose origin and usage rights are unclear. NIST identifies inaccurate outputs and intellectual property risks in its generative AI risk profile. Verify factual claims, asset permissions, and the terms of your offer before publication. Generated material is not automatically infringing, but it still needs review. NIST AI 600-1.
18. Some visitors struggle to use the site
A design that looks appealing to its creator may be difficult for people with different access needs. W3C provides testable WCAG criteria for evaluating web accessibility. Include keyboard use, forms, and readability in the planned checks. A single automated result is not sufficient grounds to claim that the entire website meets the standard. W3C: WCAG.
19. The site looks good on your computer but feels slow to customers
Images, scripts, and third-party services need to be assessed for their effect on actual use. Core Web Vitals cover loading, interaction responsiveness, and visual stability. Laboratory results can also differ from real visitor experiences. Ask for checks that reflect relevant devices and conditions instead of relying on a preview on the creator’s computer. Web Vitals guidance.
20. Search engines struggle to discover or index the pages
A website needs to be accessible to crawlers, return an appropriate response, and offer indexable content to meet Google Search’s basic technical requirements. Incorrect settings can prevent that process. Meeting the requirements still does not guarantee indexing or rankings. Page structure, useful content, and technical SEO need deliberate work and verification. Google Search technical requirements.
AI website builder vs developer: which fits your business?
Start with the complexity of the website and the consequences of errors. A profile page without customer accounts has different needs from a booking system that stores information and controls staff access.
| Your situation | An option worth considering | What you still need to arrange |
|---|---|---|
| A simple information site with few integrations | Build it yourself using a suitable tool or platform | Time to check content, access, design, and domain management |
| Standard requirements covered by a managed platform | Use the service with help where needed | Review features, costs, support boundaries, and data export |
| Custom workflows, several user roles, or important integrations | Engineering support and development around your requirements | Business priorities, access rules, test scenarios, and maintenance budget |
| An existing AI-built site of uncertain quality | A focused assessment before choosing the next step | Its URL, intended purpose, available access, and visible issues |
This is a decision guide, not an assessment of any particular platform. For transaction-based systems, see the discussion of AI-built online stores without engineering oversight.
What are you paying an engineer to do?
You should receive work that can be examined: clear requirements, explainable technical decisions, tested functions, and a plan for ongoing operation. NIST’s Secure Software Development Framework treats secure development as practices throughout the software lifecycle. Writing code is one part of that work. NIST: Secure Software Development Framework.
When we discuss a project, your business needs help define its scope. A custom website can be useful when requests, approvals, or information management must follow your own workflow. Its visual design can also reflect your identity and give prospective customers the information they need to decide.
Before agreeing to a service, ask for concrete deliverables: included functions, integration boundaries, checks before launch, and arrangements afterwards.
Hiring an engineer makes sense when the work, evidence, and responsibilities are clear.
A professional title or choice of tools alone does not establish quality.
Engineering support can include AI tools while retaining human judgment. A managed platform or a small repair may also suit your requirements. Rebuilding should have a reason that can be explained against the condition of the existing website.
Compare costs through to ongoing operation
When comparing options, include initial development, your management time, domain registration, hosting, licences, paid services, and future changes. The amounts depend on the design and usage. A website package should explain which costs it includes.
I discuss scope, pricing, and timing before work begins. Ongoing support, response times, and additional tasks follow the agreed arrangement; not every project includes continuous monitoring. Access to data, accounts, documentation, and usage rights should be explained. Source code transfer is not automatically included and depends on the proposal and applicable licences.
The aim is to make the work and the route to help clear. Testing and maintenance can reduce risks, but they cannot guarantee permanent freedom from failures or a particular search ranking.
If you have already built something with AI, bring it to the discussion. We can start with the functions your business relies on, identify what needs examination, and work out an appropriate scope of help.
Frequently asked questions
Is building a website with AI always risky?
No. The relevant risks depend on its functions, data, permissions, components, and operation. A simple information page differs from an application with customer accounts or important integrations. Assess the result and its verification process, including when humans write the code.
How does an AI website builder differ from hiring an engineer?
A website builder helps produce pages or functions through its available tools and features. Engineering work can cover business requirements, design review, testing, integrations, and technical operation. Check the proposal for the actual deliverables and support, because services differ.
Do I need to discard a website I already built with AI?
That decision should follow an assessment of its condition. The existing site can help explain your goals, functions that are not working, and areas needing review. A rebuild should have a stronger justification than focused improvements to what you already have.
Are AI-built websites automatically bad for SEO?
How the code was created does not by itself determine a page’s suitability for search. Check crawler access, page responses, indexable content, structure, and usefulness. Meeting technical requirements does not guarantee indexing or a particular ranking.
Does an engineering fee include maintenance and source code?
The proposal determines what is included. Clarify initial fees, recurring services, support, response times, access, documentation, and source code terms. Source code transfer is not automatic and may depend on licences or a separate agreement.
How can I discuss my website with Dicky Ibrohim?
Share your business goal, the functions you need, and the URL or a description of what you have already built. Explain the problems you see and what you can manage yourself. This helps define the discussion; avoid sending passwords or private customer records in your initial message.
