I created a website using an AI prompt without applying prior knowledge of website structure or technical foundations. I then inspected the finished code as an SEO professional to evaluate what the AI built correctly, what it assumed, and what important elements it left out.
Manus offers an optional SEO feature that can prerender page content for search-engine crawlers, but I did not enable or use that feature in this experiment. The website was created and published from the original prompt without an additional SEO configuration layer, so the exported application relied on client-side React rendering.
This distinction shapes the entire review. The case study evaluates the website as it was generated, configured, and exported during this experiment. It does not treat every feature available elsewhere in Manus as though it had been enabled in this project, and it does not treat a missing file in the ZIP as proof that Manus lacks the capability at the platform level.
Manus platform capabilities were reviewed separately from the downloaded code. At the time of this review, Manus supported managed publishing and hosting, custom domains, SSL/TLS, built-in analytics, third-party API integrations, optional GitHub synchronization, and optional SEO tooling. Those capabilities provide important context, but only the features actually used or represented in this project were evaluated as part of the website itself.
The result was a real, deployable React website built with modern technologies, including React, Vite, TypeScript, Tailwind CSS, and Express. Visually, the site had a strong foundation. It used semantic HTML, reusable components, logical heading structure, responsive breakpoints, focus styles, and an organized design system.
However, the website was much closer to a polished landing-page prototype than a completed telehealth platform. Its technical SEO, crawlability, content depth, performance readiness, independent hosting portability, and healthcare functionality were underdeveloped within the configuration reviewed. The exported code clearly identified Manus-specific tooling, but it did not record the exact public URL, custom-domain configuration, active hosting mode, publishing history, or optional platform settings used for the live version.
The experiment showed that AI can create an attractive and structurally organized starting point, but it may not automatically include the technical foundation, functionality, accessibility, or SEO requirements needed for a production-ready website. Human review is still essential, especially for healthcare websites where performance, trust, accessibility, and compliance matter.
The website is built from a real, deployable codebase, but it is currently much closer to a polished landing-page prototype than a finished telehealth website.
The project can be deployed and made publicly accessible. I did not purchase a custom domain for this experiment. Manus provided the managed publishing environment: when the site was published, the platform handled the cloud infrastructure, production build, deployment, and future redeployments. At the time of this review, Manus also documented multiple managed hosting options for different application needs. Those platform-level services made the website publishable without requiring me to create a separate external deployment pipeline.
Manus also supports purchasing or connecting a custom domain. Once a domain is connected, the platform provisions SSL/TLS so the published website can use HTTPS. I did not use that option, which is why the experiment should not be evaluated as though a permanent branded domain had already been configured.
From a production standpoint, several important pieces still need to be configured, supplied, or verified. Many technical SEO, crawlability, content, responsive, and performance improvements can be implemented within the existing code without purchasing separate software, although they may require additional Manus credits or professional development time. Ongoing costs are more likely to involve the domain, hosting beyond included allowances, scheduling or telehealth platforms, healthcare integrations, security services, and professional legal or compliance review.
Visually, the foundation is strong. The design is modern, organized, and generally responsive across desktop, tablet, and mobile devices. The code foundation is also reasonably structured, although much of it appears to be scaffolded by the AI rather than developed around a complete technical strategy.
The strongest gaps appear beneath the visual layer. Technical SEO and crawlability were limited in the configuration used for this experiment because the optional Manus SEO feature was not enabled and the exported code did not independently add an equivalent rendering strategy. Accessibility was partially addressed but still required validation. Performance governance, independent self-hosting, and real telehealth functionality would also need additional work before the concept could be treated as a production-ready healthcare website.
The website is a modern JavaScript application built with React 19, Vite, TypeScript, Tailwind CSS, Wouter, Express, and Radix-based interface components.
This means it is not a traditional HTML website or a site created with WordPress, Elementor, Webflow, or another visual content management system.
React finds the empty root container and inserts the website into it, including the navigation, headings, images, sections, FAQs, buttons, and footer.
This approach makes it easier to build interactive interfaces. React can update one part of the page without reloading the entire website.
Instead of the server sending a newly completed HTML page every time something changes, the browser receives the React application and manages those changes itself.
This specific Manus export was generated from a modern application scaffold. The included template.json identifies the starting point as a “Web App (static only)” template built around React and Vite, with no application backend included. React, Vite, TypeScript, and reusable interface components gave Manus a flexible foundation for producing a polished and interactive landing page quickly. This finding describes the template used for this project; it should not be treated as a claim that every Manus website uses the same architecture.
That does not mean React was the only possible choice. A one-page marketing website could also have been built with ordinary HTML, a static-site generator, WordPress, or a framework that produces complete HTML before the page reaches the browser.
In a traditional server-rendered website, the response may already contain:
<h1>Virtual nutrition support</h1>
<p>Meet with a licensed provider online.</p>
A crawler can read that content immediately.
In this React project, the first response may contain only:
<div id=”root”></div>
For the configuration used in this experiment, a crawler would need to download and execute JavaScript before it could see the H1, paragraphs, links, and other React-rendered content.
Manus can provide a separate platform-level prerendering layer when its optional SEO feature is enabled. I did not enable that feature, and the exported source did not contain another server-side rendering, static-generation, or prerendering system. The case study therefore evaluates the client-rendered version that was actually created and exported.
That means the website depends on several things working correctly:
Google can usually render React websites, but rendering JavaScript requires an additional processing step. Some crawlers and social preview tools are less capable.
This Does Not Automatically Make It Bad for SEO
The issue is not simply that the site uses React.
A React website can perform well in search when it includes:
The concern with this project is not React itself. It is that the website used a client-side React structure without enabling Manus’s optional SEO layer and without independently implementing all of the supporting systems in the exported code.
A traditional website may deliver most of its content directly in the original HTML. In this project, much of the visible page depends on JavaScript loading and running correctly. That does not automatically make the website bad for SEO, but it does make the technical setup more important.
The AI did include several strong structural elements within the code.
TypeScript strict mode is enabled, which can help reduce coding errors and improve maintainability. The page also uses semantic HTML elements such as header, nav, main, section, article, and footer, helping browsers, search engines, and assistive technologies understand the page structure.
The website contains one primary H1 heading, and the remaining heading order is generally logical. Repeated content is stored in reusable arrays and components rather than being unnecessarily duplicated throughout the code.
The project also includes visible focus styles for keyboard users, support for reduced-motion preferences, and an error boundary designed to prevent the entire application from failing when a component encounters an error.
The error boundary is a useful resilience feature, but its current fallback displays the JavaScript stack trace directly on the page. A production version should replace that developer-facing detail with a safe user message and send technical error information to an approved monitoring system instead. The viewport also includes maximum-scale=1, which should be removed or carefully reviewed because it can interfere with browser zoom for some users.
Shared CSS variables and reusable interface components create a more consistent design system. Mobile, tablet, and desktop breakpoints are also present, giving the website a generally solid responsive foundation.
These choices show that the AI produced more than a simple visual mockup. It created a structured application with several modern development practices already in place.
Although the AI created a visually polished interface and used several modern development practices, the internal structure reveals that the project is still much closer to an AI-generated prototype than a maintainable production application.
The primary homepage file, Home.tsx, is approximately 401 lines long. The main stylesheet, index.css, contains approximately 1,675 lines of CSS.
File length alone does not determine whether code is good or bad. However, in this case, the size of these files reflects how many unrelated responsibilities have been concentrated in the same locations.
The homepage component appears to control or contain:
This is commonly described as a monolithic component. Instead of dividing the page into smaller, focused components, most of the website’s content and behavior is managed inside one large file.
That structure may be acceptable for an early prototype, especially when the immediate goal is to generate a single landing page quickly. However, it becomes increasingly difficult to manage as the website grows.
This also reflects the way the website was originally prompted. The request focused on the visible design and content, but it did not define how the code should be organized for future expansion. The AI was not instructed to create a scalable component architecture, prepare the project for multiple pages, separate business logic from presentation, or establish reusable patterns for future services, providers, locations, and patient resources.
Without those instructions, the AI prioritized producing a finished-looking page rather than designing long-term software architecture. Placing most of the page inside one large component is faster and simpler when the immediate goal is to generate a single landing page. The AI can see all of the content, interactions, and layout in one location and produce visible results with fewer files and fewer connections between components.
This does not necessarily mean the AI made an unreasonable decision. Based on the information it received, the project may have appeared to require only one page. The system could not know whether the website would later expand into a complete telehealth platform unless that future direction was included in the prompt.
The project files reinforce that interpretation. The template identifies the application as static only, the design notes describe the scheduling interactions as illustrative placeholders, the booking message states that the prototype is ready to connect to a preferred workflow, and the footer identifies the finished page as a concept landing page. In other words, the prototype status was not hidden inside the code; it was part of the generated project’s own design intent.
The issue appears when the website begins to grow. A complete telehealth website may eventually require separate pages or sections for:
If each new feature continues to be added to the same homepage component, the file becomes responsible for too many unrelated tasks. Navigation changes, booking behavior, service content, FAQ interactions, provider information, and footer updates may all need to be edited in one place.
This can make the code more difficult to understand because a developer must review a large file to locate one specific section. It can also increase the risk of unintended changes. For example, editing the mobile navigation could accidentally affect another part of the page if the state, styles, or event behavior are closely connected.
A large component is also harder to test. A developer cannot easily test the booking section independently if it is tightly connected to the rest of the homepage. Reusing the same booking call to action on another page may require copying the code instead of importing a reusable component.
The project did not necessarily need a much longer prompt. It needed clearer technical requirements. A more specific prompt could have instructed the AI to:
For example, the original prompt could have included:
“Build this as a scalable React website rather than a single monolithic page. Separate the header, navigation, hero, services, process, FAQ, booking call to action, and footer into individual reusable components. Organize the project so that service pages, provider profiles, policy pages, and additional routes can be added later without rebuilding the homepage.”
That instruction would have given the AI a clearer reason to prioritize maintainability alongside the visual result.
The current structure therefore does not prove that the AI was incapable of creating a more scalable application. It shows that architecture must be part of the prompt when scalability is an important requirement. When the user asks only for a finished website, the AI may optimize for speed, appearance, and immediate functionality. When the user also defines future growth, reusable components, routing expectations, and code organization, the AI has a better foundation for generating a maintainable project.
A production telehealth website would eventually require additional pages and functionality for services, providers, scheduling, patient information, insurance, privacy, telehealth consent, accessibility, legal policies, contact information, and educational resources. Continuing to add those features to one large component would create a codebase that is difficult to update, test, reuse, and troubleshoot.
A more scalable structure would divide the homepage into separate components such as:
components/
├── Header.tsx
├── Navigation.tsx
├── MobileMenu.tsx
├── HeroSection.tsx
├── ServicesSection.tsx
├── HowItWorksSection.tsx
├── CareTeamSection.tsx
├── TestimonialsSection.tsx
├── FAQSection.tsx
├── BookingCTA.tsx
└── Footer.tsx
Each component should have a clearly defined responsibility. The navigation component should manage navigation. The booking component should manage booking interactions. The frequently asked questions component should manage FAQ content and behavior.
Separating these responsibilities would make the application easier to understand and reduce the likelihood that changing one section would unintentionally affect another.
It would also make the code more reusable. For example, the same header, footer, booking call to action, and provider card could be used across multiple pages without duplicating the original code.
The CSS presents a similar structural concern.
The main style sheet contains approximately 1,675 lines, which is substantial for a website that currently functions primarily as a single landing page.
A large global stylesheet can work during the initial design phase, but it becomes difficult to maintain as additional pages and interface elements are introduced.
Without a more organized CSS strategy, future development can lead to:
The stylesheet should eventually be separated by component, page, or feature.
A more maintainable structure could resemble:
styles/
├── global.css
├── variables.css
├── typography.css
├── navigation.css
├── hero.css
├── services.css
├── booking.css
├── faq.css
├── footer.css
└── responsive.css
Another option would be to keep relevant styles close to their components by using CSS Modules or another component-scoped styling method.
The project already uses Tailwind CSS, which raises an additional architectural question. If Tailwind is the primary styling system, the large amount of custom global CSS may indicate that two styling approaches are being mixed without a clearly defined strategy.
The same page also depends on a large custom stylesheet for detailed layout behavior:
Using Tailwind alongside custom CSS is not automatically a problem. However, the project should establish which system is responsible for layout, typography, responsive behavior, design tokens, reusable utilities, and component-level exceptions.
Without a clearly defined styling strategy, the website may accumulate both large utility-class strings inside the React files and overlapping global CSS rules outside them. This does not automatically make the website slower, but it can increase code complexity, duplicate styles, enlarge the production files, and make future performance problems more difficult to identify and correct.
Most of the TypeScript files included in the project do not appear to contribute to the website that users can currently see.
The client source contains 66 TypeScript or TSX files. When the server and shared TypeScript files are included, the complete export contains 69. A static import review found that only a much smaller group was reachable from the active application entry point. That count does not prove the remaining files are harmful, but it does show that the export contains a broader interface system than the current page uses.
In this context, “contribute” means that the files do not appear to be connected to the active website through the project’s import structure. A TypeScript or TSX file can exist inside the project without being loaded by the application. The application begins with its entry file, main.tsx, and then follows the files imported from that starting point. If a component is not imported directly or indirectly from the active application, it may remain in the project without affecting the visible website.
Their presence does not mean the files are broken. It means they appear to be available in the codebase without currently being connected to the page users interact with.
Many of the remaining files appear to be unused interface components or development scaffolding. These may have been included automatically by the AI’s preferred component library, starter template, or project-generation process.
This likely occurred because the AI did not build every file specifically for this telehealth landing page. The export contains a broader React application structure and reusable interface library. This gives the AI access to common website components without requiring it to build each one from the beginning.
A general-purpose starter structure can help the AI generate a polished interface quickly. Buttons, menus, notifications, accordions, forms, dialogs, and other interface patterns may already exist inside the project. The AI can then select the components it needs for the current design.
However, after completing the visible landing page, it does not appear to have removed every component that remained unused.
This may also be connected to the original prompt. The prompt focused on generating the website rather than creating the smallest possible codebase. The AI was not specifically instructed to audit the project afterward, remove unused files, minimize dependencies, document future components, or return only the code needed for the finished page.
Examples may include interface elements prepared for features such as:
Not every component category listed above is necessarily unused. Some elements from the broader interface library are connected to the current application.
For example, the website uses a toast notification to display the temporary booking message. The FAQ section may also rely on a reusable accordion-style component, while buttons and other interface controls are used throughout the page.
The important finding is not that every component in the library is unused. The finding is that the exported project contains a much broader collection of components than the current landing page appears to require.
Some of those components may have been retained intentionally for future development. A complete telehealth website could eventually use:
The exported project does not document whether these components were retained for planned features or simply remained from the original starter structure.
Having reusable components available is not inherently harmful. The issue is that the export contains significantly more code than the application currently uses.
There can be legitimate reasons to keep unused components. A development team may maintain a shared design system so that future pages can be created consistently. Keeping a tested dialog, form, tab, or menu component may reduce development time later.
The concern is the lack of documentation or cleanup. A future developer cannot immediately tell whether an unused-looking component is:
This creates several concerns.
First, it makes the project more difficult for a new developer to inspect. A developer opening the export may assume that these components are active somewhere in the application when they are not.
The developer may spend time searching through files for charts, sidebars, dialogs, calendars, or form systems that never appear on the live page. This can make the project look more complicated and more functionally complete than it is.
It can also make the application architecture harder to understand. A new developer must first determine which files belong to the active website and which belong only to the surrounding scaffold.
Second, unused files can make maintenance less efficient. Developers may spend time reviewing, updating, or troubleshooting code that has no effect on the live website.
For example, a dependency update may cause a warning inside an unused chart or calendar component. A developer may investigate that warning even though the affected component is not connected to the public website.
Unused files can also become outdated. If the active website changes while unused components remain untouched, those components may no longer match the current design system, React version, accessibility requirements, or coding standards.
If someone later attempts to use one of those components, they may assume it is production-ready when it has not been maintained or tested with the current application.
Third, unused components may be connected to dependencies that are also unnecessary. Even when tree shaking prevents unused JavaScript from being included in the final browser bundle, those dependencies can still increase installation time, security-review requirements, upgrade complexity, and the overall size of the development environment.
Tree shaking is an important distinction in this review.
Modern build systems such as Vite generally follow the project’s import structure when creating the production bundle. If a component is never imported by an active application, its code may be excluded from the JavaScript files delivered to visitors.
Therefore, the presence of approximately 66 TypeScript or TSX files does not automatically mean that visitors download all 66 files when opening the website.
The live performance impact cannot be determined solely by counting the source files. A complete production build and bundle analysis would be required to determine which components and packages are delivered to the browser.
However, tree shaking does not remove every concern created by unused code.
A dependency may still:
Some packages may also include build-time behavior, styles, configuration, or side effects that prevent them from being removed as cleanly as an unused standalone component.
The exact effect should therefore be confirmed rather than assumed.
The project should be audited to determine which files and packages are actually being imported.
That audit should examine more than the number of files. It should determine:
A production bundle should also be generated and analyzed. Static source inspection can show which files appear reachable through ordinary imports, but the final bundle provides stronger evidence of what is actually delivered to the browser.
Unused components, libraries, helper functions, and development artifacts should be removed unless there is a documented plan to use them.
This does not mean deleting every component that is not currently visible. A reusable component may be worth retaining if the project has a clear design-system strategy or a documented roadmap for using it.
The important requirement is intentionality. The team should know why a file remains in the project.
For example, a component could be documented as:
Without that documentation, the project remains more difficult to maintain and audit.
The original prompt could also have addressed this by including an instruction such as:
“After completing the website, audit the entire project and remove all unused files, components, imports, helper functions, and dependencies. Retain reusable components only when they are actively used or clearly documented for planned features. Verify the final import structure and production bundle before returning the export.”
This would have directed the AI to treat code cleanup as part of the finished website rather than stopping once the visible design was complete.
Useful tools for this process could include:
npx depcheck
for identifying potentially unused dependencies, and:
npx knip
for identifying unused files, exports, and dependencies.
depcheck can compare the packages listed in the project with references it finds in the source code. It may help identify dependencies that were included by the starter template but are no longer needed by the finished application.
knip performs a broader analysis and may identify:
A production bundle analyzer may also be useful because it can show which packages contribute to the JavaScript ultimately delivered to users.
These tools are not perfect and their findings should be reviewed manually, but they can help distinguish the actual application from the scaffolding generated around it.
They may incorrectly identify something as unused when it is loaded through:
Files and packages should therefore not be deleted automatically based only on a tool report.
The correct conclusion is not that the additional files are automatically harmful. The more accurate conclusion is that the AI appears to have generated the website from a broad reusable application scaffold, connected only part of that scaffold to the current landing page, and left the remaining structure without enough documentation to establish whether it was intentionally retained.
For an early prototype, that may be acceptable. For a production project, the active website, shared design system, planned future components, and unused scaffolding should be clearly separated and documented.
The Website Contains Visual Booking Interactions, Not a Complete Booking System
One of the most important differences between the prototype and a functioning telehealth website is the booking experience.
The page includes booking language and calls to action, but the exported project does not contain a complete scheduling workflow.
The source code makes that limitation explicit. Selecting a booking action displays “Scheduling is ready to connect” and explains that the prototype can be connected to a preferred booking workflow. The footer also calls the page a concept landing page. The booking experience should therefore be evaluated as an intentional prototype interaction, not as a hidden scheduling failure.
If the AI is not given a real booking destination, scheduling platform, form endpoint, or patient-registration process, it has no operational system to connect to. It can create a button that looks complete, but the destination will remain a placeholder, simulated interaction, or unfinished link.
This is an important distinction when evaluating AI-generated websites:
A button that says “Book an Appointment” is not the same as a functioning appointment system.
The AI can generate:
However, it cannot independently determine where real appointment data should be sent.
For the booking process to function, the project would need specific technical direction, such as:
Without that information, the AI is left to create the appearance of a booking experience rather than the infrastructure behind it.
This is not necessarily a failure of the AI. It reflects a limitation in the original prompt and the information made available to the system.
An AI website generator cannot connect a telehealth business to a scheduling platform it was never told existed. It also should not invent a medical scheduling destination, patient database, or healthcare data workflow.
Manus can support third-party APIs and backend integrations when the user supplies the endpoint, authentication details, workflow requirements, and appropriate credentials. None of those business-specific inputs were provided here. The missing scheduling connection reflects the scope of this project, not proof that Manus is incapable of supporting an integration.
The correct production solution would be to replace the simulated booking behavior with a verified destination, such as:
<a
href=”https://verified-scheduling-platform.example.com”
className=”booking-button”
>
Book an Appointment
</a>
If the website were using an embedded scheduling system, the integration would need to follow the vendor’s documented implementation requirements.
A custom booking system would require significantly more infrastructure, including server-side validation, database storage, authentication, scheduling logic, availability management, privacy controls, security protections, and error handling.
The technical inspection therefore classified the booking experience as an intentional placeholder rather than an operational telehealth feature. Replacing the prototype interaction with a verified scheduling destination is one of the critical steps required before a real healthcare launch.
For a general business website, an unfinished contact button may simply create a poor user experience. For a healthcare website, an incomplete or incorrectly configured booking process creates more serious concerns.
A scheduling workflow may involve sensitive personal or health-related information. Before collecting that information, the website owner must understand:
A standard front-end form should not automatically be treated as a secure healthcare intake system.
For example, a React form can collect a name, email address, phone number, medical condition, insurance information, or appointment request. However, unless the receiving system has been intentionally designed and evaluated for that data, the visual form does not establish privacy, security, or regulatory readiness.
The current project does not contain enough backend information to confirm how patient information would be processed.
Therefore, health information should not be collected through the prototype until the complete privacy, security, vendor, and compliance architecture has been evaluated.
The exported website did not include a runnable automated test suite. Vitest was listed as a development dependency, but there was no test script and no identifiable unit, component, integration, end-to-end, accessibility, or production smoke-test files. The scaffold contained a testing tool, but the project did not turn that dependency into an implemented quality-assurance process.
That does not mean the website was broken or that no one viewed it before publishing.
The project included commands for starting the development website, checking TypeScript, creating a production build, formatting the code, and running the Express server. What it did not include were commands such as:
npm run test
npm run test:e2e
npm run test:accessibility
The commands above are generic examples of the scripts a project might expose. This export declares pnpm as its package manager, so project-specific versions would use pnpm run test, pnpm run test:e2e, and pnpm run test:accessibility after those scripts and tests were actually configured.
The code could be developed and built, but there was no automated process confirming that important features continued to work after future changes.
Automated testing is usually a separate part of website development. A developer first defines what the website is expected to do, then writes tests that confirm those behaviors. For this project, that could include checking that the homepage loads, the mobile menu opens, the FAQ sections expand, images contain alternative text, and invalid URLs receive the correct response.
The current booking buttons could also be tested, but only against the behavior that was provided. Because the original prompt did not include a real scheduling URL, the website displayed a temporary booking notification. A test could confirm that the notification appeared, but it could not verify a real appointment destination until the person creating the website supplied the correct platform and URL.
For example, the current placeholder behavior could be tested to confirm that selecting “Book a visit” displays the intended message. Once a verified scheduling link is added, the test should be updated to confirm that the button directs visitors to the correct location.
Different tests serve different purposes. A unit test checks a small piece of logic or data. A component test checks one interface element, such as the mobile menu. An integration test checks whether multiple parts of the application work together. An end-to-end test opens the website in a real browser and follows the same steps a visitor would take.
A browser-level test for this project could confirm that a visitor can:
That final step is particularly important. The React application contains a visual Not Found page, but the Express server may still return a successful 200 OK response for an invalid URL. A browser test that checks the actual HTTP status could reveal that difference.
Accessibility testing would also be useful. The AI added several positive accessibility features, including semantic HTML, descriptive image text, focus styles, navigation labels, and reduced-motion support. However, the presence of those features does not confirm that the entire page meets accessibility requirements.
A developer would normally combine automated tools with manual testing. Automated tools can identify common problems such as missing accessible names, incorrect ARIA attributes, duplicate IDs, and some contrast issues. Manual testing is still needed for keyboard navigation, browser zoom, screen readers, mobile accessibility, and real user behavior.
A production smoke test would provide another layer of protection. After the website is built or deployed, it could confirm that the homepage responds, the main heading appears, the JavaScript loads, the images display, the navigation works, and no major browser errors occur.
This would be especially useful for this project because several images use Manus-specific storage paths. A test performed after moving the website to another host could quickly reveal whether those images were still loaded correctly.
The missing tests may also reflect how the original prompt was used. The request focused on creating a visible website rather than defining a complete software development and quality-assurance process.
The absence of an implemented test suite should not be treated as proof that the AI generated unusable code. It shows that the exported project did not continue into a separately documented development, testing, and release process that another team could repeat outside Manus.
For an early landing-page prototype, manual review may be reasonable. For an actively maintained telehealth website, automated testing would create a repeatable validation layer that helps prevent future updates from silently breaking navigation, accessibility, responsive layouts, booking destinations, or server behavior.
The exported ZIP represents the project files at a particular moment in time. It contains the application code needed to inspect, edit, build, or redeploy the website, but it does not necessarily contain the source-control system that would track the project’s development history.
A connected Git repository normally records changes, commits, branches, contributors, and previous versions. It can also support pull requests, code review, and automated validation. An exported ZIP may include the current source files without including the hidden Git history or any connection to an external repository.
Manus currently supports optional GitHub integration and two-way synchronization, but I did not use or configure that feature for this experiment. The absence of repository history in this ZIP therefore describes this project’s workflow; it should not be read as a claim that Manus cannot connect a project to GitHub.
A GitHub Actions workflow is normally stored inside a GitHub repository at a location such as:
.github/workflows/validate.yml
The workflow may be configured to run when code is pushed or when a pull request is created:
on:
push:
pull_request:
These events only exist after the project has been placed in a GitHub repository. If the website was created and published entirely through Manus, the user may never have created an external repository, committed the code, pushed a change, or opened a pull request.
Without that connection, GitHub has no repository event that could trigger GitHub Actions.
The workflow file could still be added to the export, but it would not run until the project was uploaded to GitHub and the required scripts, environment variables, and permissions were configured.
This does not mean that Manus published the website without performing any build or deployment checks. Manus may use its own internal systems to prepare and publish the application. However, those platform-controlled processes are separate from a portable CI workflow owned by the website developer and stored inside the exported repository.
The accurate conclusion is that the export contained the website’s current code but did not contain a visible, repository-controlled process for automatically validating future changes. A developer could create that process later by placing the project in GitHub, GitLab, or another source-control platform and configuring the appropriate CI workflow.
This occurred because the website was created and published within Manus without connecting the optional GitHub workflow or creating a separate repository-controlled CI process. Manus could build and host the website using its own systems, while the exported ZIP captured the current project files rather than repository history, branches, pull requests, or an independently managed validation pipeline.
Manus provided its own managed build, hosting, publishing, and redeployment process. Therefore, the website did not need GitHub Actions or another external CI platform in order to be published through Manus.
However, the original prompt did not request a separate source-control repository or a portable CI workflow that could be managed outside the Manus platform.
External CI systems could include:
Creating one of these workflows would require additional decisions, including:
For example, adding a GitHub Actions workflow would assume that the project would be placed in GitHub and that GitHub would become part of the ongoing development process. Those requirements were not included in the original prompt.
The absence of a GitHub Actions file therefore does not indicate that the website lacked a publishing process. Manus already supplied that process. It means the project did not include a second, external CI workflow that the website owner or another developer could manage independently outside Manus.
The original workflow example below uses generic npm-style commands to illustrate the sequence of a CI process:
npm ci
npm run typecheck
npm run lint
npm run test
npm run build
For this export, a project-matched starting sequence would instead use:
pnpm install –frozen-lockfile
pnpm run check
pnpm run build
Linting and testing would remain later steps because the export did not define those scripts or provide an implemented test suite.
Or
Install the exact dependencies
↓
Check the TypeScript
↓
Review the code with linting
↓
Run automated tests
↓
Create the production website
However, the project did not visibly include every corresponding script or system.
In particular, the export did not show complete:
A CI workflow cannot successfully run commands that the project does not support.
For example, this step would fail if there is no lint script:
– run: npm run lint
This step would also fail because no test script or implemented test suite exists, even though Vitest is listed as a development dependency:
– run: npm run test
Therefore, creating the CI file would not have been enough. The AI would first have needed to:
The missing CI workflow is therefore connected to the missing testing and linting infrastructure.
The Project Did Contain Some Validation Commands
The project was not completely without development checks.
Its package scripts included commands for activities such as:
This demonstrates that the project included a basic development and build foundation.
However, those commands were not connected to an automated workflow that ran whenever the code changed.
A developer could manually run the available commands, but the project did not enforce that process.
This is the difference between having manual commands and having a continuous integration process.
The manual process would have depended on someone remembering to run:
pnpm run check
pnpm run build
A CI process runs the required checks automatically when defined events occur.
Manus Has Its Own Publishing Process
According to Manus’s current documentation, when a user selects Publish, Manus:
Manus also provides managed hosting, monthly hosting allowances, usage-based hosting beyond those allowances, and options to purchase or connect a domain.
Manus also offers optional GitHub synchronization and code export, which means a project can be moved into a developer-controlled workflow. Neither option automatically creates a CI policy, test suite, or release gate; those controls still need to be defined for the project.
What the exported ZIP does not show is the internal workflow Manus used to perform those tasks. It does not include Manus’s deployment system, publishing history, infrastructure configuration, or internal quality checks.
Also, Manus’s publishing process is not the same as a developer-owned continuous integration workflow:
The absence of a continuous integration workflow in the exported code does not mean that the website was published without an automated deployment process. Manus has its own managed publishing system.
When the user selects Publish, Manus provisions the required cloud infrastructure, builds and optimizes the application for production, deploys it to a hosted environment, and handles future redeployments when the website is updated. It can also configure the required DNS settings when a custom domain is connected.
However, Manus’s publishing process is managed by the platform and is not included in the exported project. The ZIP contains the website’s source code, build configuration, and server files, but it does not expose Manus’s internal deployment workflow, infrastructure settings, publishing records, or validation process.
This is different from a repository-controlled continuous integration workflow. A GitHub Actions workflow, for example, would belong to the website owner’s repository and could automatically run specific TypeScript checks, linting, tests, and production builds whenever the code changed.
Manus did provide the website’s publishing and hosting process. However, that platform-managed process was not included in the exported code, so a developer could not independently inspect, modify, or reproduce it outside Manus.
Manus already provided the managed infrastructure needed to build, host, publish, and redeploy the website. Therefore, the original project did not require a separate external deployment system in order to become publicly accessible through Manus.
However, if the exported code were moved into a developer-controlled repository or deployed outside the Manus platform, an additional CI and deployment workflow would require information about the new environment.
That information could include:
Some of this information can already be identified from the exported project. The package.json file declares pnpm as the package manager, pnpm-lock.yaml records the locked dependency graph, and the project includes commands for TypeScript checking, production builds, and starting the Express server.
Other information could not be defined safely without additional direction.
For example, an external deployment workflow might require secrets such as:
HOSTING_API_TOKEN
PRODUCTION_PROJECT_ID
DEPLOYMENT_SERVICE_ACCOUNT
Those values would belong to the actual external hosting account selected by the website owner or developer.
The AI should not invent those credentials. It could create clearly labeled placeholders, but the real hosting account would still need to be connected and the credentials would need to be stored securely.
These external credentials were not required for the original Manus publication because Manus managed its own hosting and deployment infrastructure.
The exported project did not include a clearly documented linting command.
The project did contain TypeScript checking and code-formatting tools. Its existing scripts could verify type compatibility, format the source files, build the production application, and start the server.
However, type checking, formatting, and linting serve different purposes.
TypeScript checks whether values, functions, and components follow the project’s declared types. Prettier controls visual formatting such as spacing, indentation, quotes, and line breaks. A linter examines broader code-quality rules and can identify issues such as:
A project can therefore pass TypeScript validation and still contain patterns that are difficult to maintain or potentially unreliable.
The missing lint command may reflect the scope of the original prompt. The AI was asked to create and publish the website, but it was not specifically instructed to establish a coding standard, configure ESLint, select React and accessibility rules, or create a process for enforcing those rules across future contributors.
Linting also does not directly affect the visible webpage. The website can render and be published without an ESLint configuration, so an AI system focused on generating the immediate visual result may not include it unless code-quality tooling is requested as part of the deliverable.
A typical setup could include:
{
“scripts”: {
“lint”: “eslint .”,
“lint:fix”: “eslint . –fix”,
“check”: “tsc –noEmit”
}
}
The exact configuration would depend on the project’s selected standards. A developer might also add TypeScript, React Hooks, import-management, and accessibility rules.
The absence of a lint command does not prove that the application was broken or that Manus performed no internal validation. It means the exported project did not contain a visible, portable linting process that another developer could run and enforce independently.
For an early prototype, that omission may be understandable. As the website grows and more people begin working on it, a shared linting configuration would help keep the code consistent, identify preventable mistakes, and reduce maintenance problems before they reach production.
The difference is process, not origin. A non-Manus website can also be created without linting when no one defines or enforces a code-quality standard. A traditional development team may be more likely to add ESLint, testing, source control, and CI during project setup, particularly when multiple developers will maintain the code, but that is a team decision rather than an automatic feature of hand-written development. This Manus export included the application, build commands, TypeScript checking, and formatting, but not a separate linting policy. The finding is not that Manus websites uniquely lack linting. It is that prompt-based projects can reach a visually finished state before maintainability standards have been requested, configured, and documented.
No Deployment Documentation
The exported project does not include a clear README or deployment guide explaining how another developer should install, configure, build, and operate the website outside Manus. The code does provide several important clues: package.json declares pnpm, pnpm-lock.yaml records the dependency versions, Vite builds the frontend, Express serves the production application, the build script creates the output, and the server code identifies where the static files are expected. What is missing is one reliable handoff document that brings those details together and explains the supported Node.js version, required environment values, Manus-specific asset dependencies, redirect and 404 behavior, monitoring, external hosting assumptions, and rollback procedure. This is not unique to Manus; any project can be delivered without adequate documentation. The issue is that once the code leaves the managed Manus environment, another developer must piece together the expected setup from several source files. A production handoff should include a README.md documenting installation, development and build commands, environment variables, hosting assumptions, asset requirements, routing, testing, deployment, and rollback procedures so the website can be maintained and redeployed independently.
The missing README is understandable in context because Manus handled the original build, hosting, and publishing process inside its own platform. The website did not need an external deployment guide in order to go live there. The export nevertheless becomes a developer handoff the moment it is moved to another host. At that point, the package manager, Node.js compatibility, environment variables, asset handling, routing, hosting, and deployment procedure should be documented in one place. The gap is not that the code contains no deployment information; it is that the information is distributed across the project instead of being translated into a clear, portable operating guide.
The project does not include a visible .env.example file.
Environment variables are commonly used to store configuration values that may differ between development and production, such as:
PUBLIC_SITE_URL=
BOOKING_URL=
API_BASE_URL=
PORT=
ANALYTICS_ID=
ERROR_MONITORING_DSN=
The values above are examples of configuration a production website might use. They are not all confirmed requirements of this export.
The variables visibly referenced in this project are PORT, BUILT_IN_FORGE_API_URL, BUILT_IN_FORGE_API_KEY, VITE_ANALYTICS_ENDPOINT, and VITE_ANALYTICS_WEBSITE_ID. The BUILT_IN_FORGE values support the Manus storage proxy in the Vite development environment. The VITE_ANALYTICS placeholders appear in the HTML and appear designed to support Manus-managed analytics behavior.
A .env.example file should not contain real secrets. Its purpose is to document which values the application expects.
Without that file, a developer may not know which settings are required for the project to function correctly.
This is especially important because the project appears to contain Manus-specific behavior. During development, Vite uses a proxy for /manus-storage, but the included Express production server does not provide an equivalent handler. Images may therefore work inside Manus while breaking when the exported project is moved to another host.
A complete environment and deployment guide should explain how those internal asset references are replaced before self-hosting.
It was likely missing because Manus managed the original environment internally, so the AI did not need to document every configuration value for the site to run inside Manus. A .env.example becomes more important when the code is exported and another developer must recreate that environment elsewhere. The current project reveals some environment-dependent behavior—such as Manus storage proxy configuration and analytics placeholders—but it does not collect those requirements into one documented file. Also, values such as BOOKING_URL, PUBLIC_SITE_URL, or ERROR_MONITORING_DSN are examples of settings a production version might need; they were not all confirmed as existing requirements in this export. The real concern is that a developer moving the project outside Manus would need to inspect the source code to discover which variables are required and how Manus-specific image paths should be replaced. A .env.example would make that process clearer without exposing real passwords, API keys, or other secrets.
The absence of a .env.example does not necessarily affect the website while it remains within Manus, because the platform may supply its required configuration internally. The issue becomes more significant when the code is exported or self-hosted. Without a documented environment-variable template, another developer may not know which analytics, asset, API, domain, or server settings must be recreated, increasing the risk of broken functionality or inconsistent deployments. In this project, a template would help document the Manus storage and analytics requirements, although additional code and asset changes would still be needed for full portability.
The analytics placeholders do not prove that analytics failed on the Manus-hosted website. Manus provides built-in analytics at the platform level. They do show that an independently hosted copy would need its own analytics configuration or a replacement implementation rather than assuming Manus would continue injecting those values outside its environment.
The exported project does not contain a visible production-validation checklist. That does not prove that no one previewed the website or that Manus performed no platform-level checks. It means there is no portable record showing that the business owner or a future development team systematically verified the complete launch experience.
For a telehealth website, production validation should extend beyond whether the homepage looks correct. It should confirm:
Some of these checks could not be completed from the ZIP alone because the experiment did not use a custom domain, a real scheduling platform, patient forms, final legal content, or the optional Manus SEO feature. That is precisely why the checklist matters: it separates what was intentionally outside the prototype from what still must be verified before a real launch.
Without a documented validation process, a website can publish successfully while still carrying broken assets, placeholder destinations, incomplete metadata, soft 404s, inaccessible controls, or unfinished patient workflows. Publishing proves that a page is reachable. Validation proves that the experience works as intended.
The project does not include a documented performance budget. That does not mean the website is currently slow, but it does mean there are no defined limits protecting performance as the site grows.
A performance budget gives developers a clear threshold for how much JavaScript, CSS, imagery, font weight, and third-party code a page can carry before speed begins to suffer. Without those guardrails, performance often declines gradually rather than all at once. One new image, font, animation, scheduling tool, chat widget, or analytics script may appear harmless. Combined over time, those additions can increase download size, delay rendering, and make the website feel slower on mobile devices and weaker connections.
For this project, performance standards could eventually include targets for:
A production team might establish internal targets such as keeping the initial JavaScript below 200 KB compressed, the initial CSS below 100 KB, and the hero image below 250 KB. Those figures should not be treated as universal rules. The right limits depend on the final website, its functionality, its audience, and the tools required to support the business.
The same applies to Core Web Vitals. A strong production target would be a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less, and a Cumulative Layout Shift score of 0.1 or less. Those measurements should be validated on the published website across both mobile and desktop environments.
The exported code alone cannot confirm whether the current website meets or fails those standards. That would require a completed production build, bundle analysis, image review, Lighthouse testing, and real-user performance data from the live URL.
The more accurate finding is not that the website is slow. It is that the project does not yet have documented performance guardrails or a repeatable process for identifying performance regressions before they reach users. For an early landing-page prototype, that may be reasonable. For a growing telehealth website, performance should be treated as part of the development strategy—not something reviewed only after the site begins to feel slow.
The source-code review did not reveal obvious TypeScript syntax errors. That is a positive finding because it suggests the files were written in a recognizable structure and did not contain clear problems such as incomplete statements, malformed components, or visibly broken TypeScript syntax.
However, reading the code is not the same as proving that the finished application can be installed, built, launched, and operated successfully.
This distinction matters because the inspection was performed on the exported source files rather than on a fully running production deployment. The ZIP contained the project code, configuration files, and package requirements, but it did not include the installed dependency folders needed to execute the application.
That is normal for a JavaScript project. Developers generally do not include the entire node_modules directory inside a source-code export because it can contain thousands of files and take up significant space. Instead, this project includes package.json, pnpm-lock.yaml, and a packageManager declaration that identify the required packages, the locked dependency graph, and pnpm as the intended package manager.
A developer receiving the export would normally begin by running:
pnpm install –frozen-lockfile
That command retrieves the React, Vite, TypeScript, Express, routing, interface, and supporting packages required by the project.
During this inspection, those packages could not be retrieved because the external package registry was unavailable within the audit environment. As a result, the application could not be taken through the complete independent build and runtime process.
This limitation does not mean the website failed to build in Manus. Manus had already used its own managed publishing environment to build and publish the application. The limitation applies specifically to what could be independently verified from the exported files outside the Manus platform.
The code inspection could confirm that the project included scripts intended to support development and production. The most relevant commands were:
pnpm install –frozen-lockfile
pnpm run check
pnpm run build
pnpm run start
Each command validates a different part of the project.
pnpm install –frozen-lockfile installs the dependency versions recorded in pnpm-lock.yaml and respects the project’s pnpm-specific configuration.
pnpm run check runs the TypeScript validation configured in the project:
“check”: “tsc –noEmit”
This checks whether components, functions, variables, and data structures are being used in ways that match their declared TypeScript types.
pnpm run build creates the production version of the React frontend and bundles the Express server.
pnpm run start launches the completed production output.
A successful result would therefore require more than code that looks correct. The full sequence would need to confirm that:
A generic validation checklist may refer to commands such as:
npm run typecheck
npm run lint
npm run test
Those generic commands should not be presented as though they were already available in this project or as though npm were its intended package manager.
The exported code defined the script:
pnpm run check
rather than a script named:
npm run typecheck
The project also did not contain clearly configured linting or automated testing commands. Before a developer could run:
pnpm run lint
pnpm run test
pnpm run test:e2e
the project would first need an ESLint configuration, test files, and matching scripts in package.json. Vitest was already listed as a dependency, but it was not connected to a runnable test command.
A more accurate independent validation process for the project in its exported condition would therefore begin with:
pnpm install –frozen-lockfile
pnpm run check
pnpm run build
pnpm run start
Linting, automated tests, accessibility tests, and browser-level tests would then be added as separate development improvements.
Why Reading the Source Code Is Not Enough
Source code can appear organized and syntactically valid while still failing when the application is actually installed or launched.
For example, the files may reference a package correctly, but the package version recorded in the project may no longer install successfully with another dependency.
An import may look valid, but the referenced file may be missing or use capitalization that behaves differently on another operating system.
An image path may appear correct inside the code but fail outside Manus because the asset depends on Manus-specific storage.
An environment variable may be referenced correctly but remain undefined when the site is deployed elsewhere.
The production server may start but return the wrong HTTP response for invalid URLs.
These issues are not always visible through static inspection because they depend on the relationship between the code, installed packages, runtime environment, server, assets, and hosting configuration.
What a Complete Production Validation Could Reveal
A complete installation, build, launch, and browser review could identify issues such as:
This project contains a particularly important example involving its images.
The source code references assets through paths such as:
“/manus-storage/nourish-hero-care_bb2b7457.jpg”
The Vite development setup contains a proxy for /manus-storage, but the included Express production server does not appear to include an equivalent handler.
The code review can identify that risk, but only a running production deployment outside Manus can confirm exactly how the images behave in that environment.
The same applies to the server’s routing behavior.
The Express server includes a catch-all route that serves the React application for unknown URLs:
app.get(“*”, (_req, res) => {
res.sendFile(path.join(staticPath, “index.html”));
});
Static inspection suggests that an invalid URL may receive a successful 200 OK response even when the visitor sees a Not Found page.
An HTTP-level test would be needed to confirm the actual server response:
/page-that-does-not-exist
The browser output and the HTTP status would both need to be checked.
How This Differs From the Manus Publishing Process
Manus had its own managed process for building and publishing the website. The fact that the site was published indicates that Manus was able to process the project within its own environment at that time.
However, that does not automatically confirm that:
The purpose of the independent inspection was not to repeat Manus’s internal publishing process. It was to determine how portable, understandable, and production-ready the exported code was outside that managed environment.
Because the complete external build could not be executed, the audit could identify risks in the source code but could not confirm every runtime outcome.
What This Reveals About Prompt-Based Website Creation
The code review reveals an important limitation of building a website from a single prompt without first defining the technical, operational, and business requirements behind it. The limitation is not that Manus can only create visual pages. It is that even a capable full-stack platform still needs the project owner to define what the finished system must do.
The AI successfully created a convincing front-end experience. It selected a modern development stack, generated reusable interface elements, established responsive breakpoints, used semantic page sections, added common accessibility features, and produced a polished visual design. The result was more than a static mockup: it was a real React application that could be built and published through Manus.
Manus can also support backends, databases, authentication, API integrations, managed hosting, analytics, GitHub synchronization, and optional SEO tooling. This particular project did not use those capabilities to create a full telehealth operation. The included template identifies the build as a static-only web app, and the generated project deliberately framed the page as a concept with placeholder scheduling behavior.
However, the AI also had to make decisions with limited direction.
The original prompt focused on creating the website’s appearance and general experience. It did not define whether the final project should be a lightweight landing page, a scalable multi-page marketing site, or the foundation of a full telehealth application. It also did not specify requirements for component architecture, testing, linting, source control, performance limits, search-engine rendering, external deployment, or future site expansion.
Without that direction, the AI followed the clearest immediate goal: producing a complete-looking concept quickly. The project’s own design notes and footer confirm that a concept landing page—not a finished clinical platform—was the outcome being built.
That helps explain why the project used a broad React application scaffold, placed much of the homepage inside one large component, retained interface files that were not required by the current page, and stopped once the visible experience was functional. Those choices are understandable for a prototype, but they would need to be reviewed before the project became a larger, actively maintained website.
The same distinction applies to the booking experience. The AI created booking language, buttons, and confirmation messaging because those elements were part of the visual concept. However, it was not given a verified scheduling URL, patient-registration platform, healthcare vendor, form endpoint, or appointment workflow. It could not safely invent those destinations.
The person creating the website would need to provide that information in the prompt or replace the placeholder behavior afterward.
This is not evidence that the AI failed to connect a system it should have known about. It demonstrates that visual calls to action and operational business systems are separate layers of website development.
The AI could create the appearance of:
It could not independently provide or verify:
Those details require information from the organization operating the website. AI can arrange verified facts into a strong website, but it should not invent the facts that establish medical, legal, or business legitimacy.
There is also a second category of requirements that the AI could have generated, but only if they had been included in the project scope.
These include:
The absence of these elements does not necessarily mean the AI was incapable of creating them. It means they were not clearly defined as required deliverables.
Some of these controls could have been generated in the source code, some could have been connected through Manus integrations, and some—such as prerendering, canonical generation, robots.txt, and dynamic sitemaps—could have been added through the optional Manus SEO feature. Because that feature was not enabled, those platform-level SEO controls were not part of the website evaluated in this experiment.
For example, a more technical prompt could have instructed the AI to separate every major section into reusable components, remove unused dependencies, generate or enable a sitemap and robots file, configure production-safe error handling, add automated tests, document environment variables, and connect the project to Manus’s GitHub integration or another repository-controlled workflow.
The original prompt did not contain those requirements, so the AI prioritized the visible website instead.
Manus also provided its own managed publishing process. The website did not lack hosting simply because the exported project did not contain a GitHub deployment workflow. Manus could build, host, publish, and redeploy the application through its platform.
The limitation in this export was independent reproducibility and portability without additional migration work. The ZIP did not include Manus’s internal publishing process, hosting configuration, deployment history, or a separate workflow that another developer could manage outside the platform. It also referenced Manus storage paths that would need to be replaced or supported when moving the project to another host.
This distinction is important because “published” and “production-ready” are not the same thing.
Publishing confirms that the application was made available through a web address. Production readiness requires a broader review of:
A website can be published successfully while still containing placeholder actions, incomplete metadata, limited content, undocumented dependencies, portability risks, or crawlability problems.
That is where prompt-based website generation and production website development begin to separate.
Prompt-based generation is highly effective at accelerating the first stage. It can turn an idea into a polished interface, establish a visual direction, generate responsive layouts, and create a real codebase much faster than beginning with a blank project.
Production development begins when the team asks a different set of questions:
The original prompt was sufficient to create a strong front-end concept, and the project files show that a concept was the intended result. It was not detailed enough to define the entire technical, operational, healthcare, and SEO foundation required for a functioning telehealth business.
The most important lesson is not that AI produced a poor website. It is that the finished output reflected the level of business direction, technical architecture, integrations, and validation the project had actually defined.
The visual result looked complete because the visible layer was intentionally polished. The inspection revealed that the systems behind that layer still required verified business inputs, technical decisions, platform configuration, professional review, and production validation.
AI can dramatically shorten the distance between an idea and a working prototype. Manus demonstrated that clearly in this experiment. What it does not remove is the responsibility to define what “finished” means for the business, the user, the developer, the search engine, and—in healthcare—the patient.
That is the strategic value of the review: not to dismiss prompt-based creation, but to separate visual completion from operational readiness. The website proved how quickly AI can create a compelling digital foundation. The code inspection showed where clear requirements, intentional SEO configuration, verified integrations, and human accountability still turn that foundation into a durable business asset.