Looking for Hostinger Horizons? Hostinger's current documentation calls the product Hostinger AI Builder. This guide keeps its established Horizons URL and follows the documented agentic-mode workflow.

Quick answer

Start with a small client-enquiry app: a public form, a private owner view and a status field. Open Hostinger AI Builder, describe that single workflow, and refine it with focused prompts before connecting real data or publishing. The example and prompts below are illustrative; UseAIVisora has not independently built or tested this app in the product.

Decision summary
Best for
A freelancer creating a reversible prototype, calculator, directory, simple portal or lead workflow with clearly defined acceptance tests.
Not suitable for
A rushed production launch involving sensitive records, complex permissions, regulated data or unreviewed payments.
Bottom line
Treat AI generation as an implementation assistant: plan first, change one area at a time, test every role and keep an exit plan.

From brief to release decision

The client-enquiry example has four checkpoints. Each checkpoint needs an observable result before you add the next layer. These are proposed tests, not results from a completed build.

Prompt-to-domain acceptance-test runbookA proposed workflow using fictional records; not a tested product demonstration
01Write the brief02Build the small path03Try failure cases04Make the release call

Write the brief

Step 1 of 4

Define the user, core task, required pages, stored data and failure messages before the first prompt.

One public formOne ownerExcluded features
Hypothetical enquiry tracker

A visitor submits an enquiry. Only the owner can read it or change its status. Payments and uploads are outside the first version.

Stop and review: The app cannot be described as observable user actions and expected results.

Build the small path

Step 2 of 4

Request the form and owner view with sample data. Review the structure, then make one focused correction at a time.

Fictional recordsVisible labelsFocused changes
Hypothetical enquiry tracker

Use a fictional enquiry named Sample Project. A success message in the preview is not yet proof that a submission was stored.

Stop and review: The generated app adds real integrations or collects customer information before its behavior is checked.

Try failure cases

Step 3 of 4

Try invalid input, empty data, duplicate actions, unauthorized access, refreshes and mobile widths before connecting a domain.

No duplicatesOwner-only accessRecoverable failure
Hypothetical enquiry tracker

Submit twice, interrupt a save and try the owner URL while signed out. Record what actually happens against each expected result.

Stop and review: Private data is exposed or the core task loses user input without recovery.

Make the release call

Step 4 of 4

Resolve blocking defects, record the recovery plan and obtain the owner's release approval. After publishing, repeat the checks on the real URL.

Release approvalHTTPS and formsRollback owner
Hypothetical enquiry tracker

A preview test can pass while the deployed form fails. Keep the release record open until the public URL completes the same permitted test.

Stop and review: The deployed app differs from the reviewed version or the team cannot recover its important data.

Key takeaways
  • Write acceptance criteria before the first prompt so the result can be tested rather than judged only by appearance.
  • Build in stages: public shell, core action, data, authentication, notifications, failure states and deployment.
  • Hostinger's dynamic credits reward focused requests and make repeated broad rewrites expensive and difficult to audit.
  • The integrated backend is convenient, but important data needs a retention and portability decision before production use.

What you will create

This guide uses a simple client-enquiry tracker as the model project: a public form, a protected owner view and a status field. The same sequence works for a directory, booking request, calculator with saved results or lightweight portal.

It is a planning guide based on official documentation, not a hands-on AI Builder tutorial. Interface labels can change, so follow the current product guidance alongside the checks below.

Open the app builder

In hPanel, open Websites, choose Add website, then AI Builder and the agentic option. Enter an initial description to start the project. Hostinger's guide describes a temporary-domain setup; an existing project can be reopened through Edit website.

These entry points follow Hostinger's AI Builder agentic-mode overview, checked on 9 September 2026. Account options and interface labels can change. Prepare the brief below before submitting the first prompt.

Step 1: define one user and one job

Write a one-page brief before opening the builder:

  • primary user: for example, a prospective client;
  • core job: submit an enquiry with name, email and project type;
  • owner job: view the submission and change its status;
  • excluded scope: payments, file uploads, multi-team permissions and bulk imports;
  • success test: a new enquiry appears once and is visible only to the owner;
  • deletion rule: the owner can remove test records.

This prevents an attractive interface from disguising an undefined product. It also gives you a stopping point for the first version.

Step 2: use a constrained opening prompt

Hostinger recommends describing the purpose, desired features and audience. A useful opening prompt is specific about behavior and exclusions:

Create a responsive client-enquiry web app for a solo consultant. Visitors can submit name, email, project type and a short message. Add a private owner area that lists submissions and allows status changes between New, Contacted and Closed. Start with sample data. Do not add payments, social login or file uploads. Use accessible labels and clear error messages.

Review the generated information architecture before asking for visual polish. Confirm that the public form and private area are separate and that no feature outside the brief has appeared.

Follow-up prompts for common first-app mistakes

These sample prompts keep each request narrow. They are not tested outputs; inspect the generated changes and run the corresponding check before continuing.

Focused follow-up prompts for a client-enquiry app
ProblemPrompt to tryCheck afterwards
Too many featuresKeep only the enquiry form and private owner list. Do not add payments, chat or uploads.The flow still matches the brief.
Cramped mobile layoutAdjust the enquiry form for a 390px screen. Keep labels visible and prevent horizontal scrolling.Fields, messages and buttons remain usable at narrow widths.
Duplicate submissionsPrevent repeated submits while saving and show a clear result without losing the entered details on failure.Double-click and failed-save tests do not create duplicates or lose input.
Exposed owner recordsRestrict enquiry records and status changes to the authorized owner, not just a hidden navigation link.Signed-out and wrong-account requests cannot read or change records.
A broad rewrite breaks a working stepFix only the named failing step. Preserve the working form, routes and owner permissions.Repeat the original acceptance checks and inspect the scope of changes.

Step 3: establish the public flow first

Test the form without authentication or production data. Check:

  1. labels remain visible and are associated with inputs;
  2. required fields explain what is missing;
  3. email format validation is understandable;
  4. double submission is prevented;
  5. success and failure messages do not expose technical details;
  6. the form works at 390px, 768px and desktop widths;
  7. keyboard focus order follows the page.

Request one correction at a time. Hostinger documents AI output as probabilistic, so a prompt to “improve everything” can change unrelated working areas.

Step 4: add data deliberately

When the visible form works, request a minimal data model. For an enquiry tracker, that might be an enquiry identifier, contact fields, consent timestamp, status, creation time and deletion time. Avoid collecting fields merely because they might be useful later.

AI Builder's integrated backend can store form data and files. Current official documentation says integrated-backend data cannot be directly exported, so decide whether that limitation is acceptable before collecting important records. If portability is essential, compare Supabase and Firebase or another backend before committing to production.

Step 5: add authentication and authorization

Authentication proves who signed in; authorization decides what that person may access. A login screen alone does not protect records.

Create at least these tests:

Minimum authorization test matrix
StateExpected resultFailure to prevent
Signed outCannot open owner recordsPrivate data rendered before redirect
Wrong accountCannot read or change owner dataGuessable URL exposes records
OwnerCan perform documented actionsOver-broad delete or export capability
Expired sessionReturns safely to sign-inAction continues with stale permission
Password resetVerified recovery onlyAccount enumeration or insecure reset

Use sample accounts and fake information. Do not invite real users until each negative test passes.

Step 6: add integrations without exposing secrets

Hostinger documents prompt-based integrations with services such as payment providers and external databases. Credentials, API keys and account identifiers may be required. Never paste a secret into visible page content, commit it to exported code or include it in a screenshot.

Add one integration at a time. Verify its official setup guide, webhook signature, allowed redirect URLs, test mode and failure handling. Payments require refund, tax, subscription and dispute decisions beyond a successful checkout screen.

Step 7: test failure states and accessibility

Test more than the happy path:

  • empty and malformed input;
  • duplicate action;
  • slow and lost connection;
  • unauthorized route;
  • expired session;
  • unavailable third-party service;
  • long names and messages;
  • screen-reader labels and visible focus;
  • reduced-motion preference;
  • deletion and recovery behavior.

If a generated change breaks a working state, Hostinger documents reverting to an earlier message/version. Record the stable version before a structural change so rollback is deliberate.

Step 8: check credits, hosting and renewal terms

AI Builder currently uses dynamic credits, so a complex request can cost more than a simple edit. Review the credit-usage screen and estimate the ongoing change budget. Record the hosting term, renewal amount and what happens when AI Builder creation access or hosting ends.

Check the current offer rather than relying on an old promotional price.

Step 9: publish with a release checklist

Before publishing:

  1. replace sample copy but keep test accounts separate;
  2. verify canonical URL, title, description, favicon and social image;
  3. add privacy, contact and terms information appropriate to the app;
  4. validate authentication and authorization again;
  5. confirm forms and transactional email from a permitted test address;
  6. verify domain, HTTPS and mobile behavior;
  7. confirm analytics and consent choices;
  8. document rollback and data-retention steps;
  9. publish, then repeat the production smoke test.

Do not assume built-in SEO or managed SSL guarantees rankings, accessibility, security or conversions.

Step 10: create an exit and maintenance plan

Export the code while the project is healthy if your plan supports it, and test the archive. Hostinger says exports use React and Vite and cannot be re-imported for continued prompting after manual edits. Inventory backend data and integrations separately because code alone is not a complete backup.

Schedule reviews for user access, stored data, dependency behavior, domain renewal, hosting renewal and official product changes.

View Current Hostinger AI Builder Offer

Frequently asked questions

What should my first AI Builder prompt include?

State the audience, one core outcome, required fields, user roles, design direction and explicit exclusions. Keep the first version narrow enough to test.

Can AI Builder build authentication and a database?

Hostinger documents an integrated backend with authentication, data and files. You still need role-by-role authorization, recovery, deletion and privacy testing.

Should I use real customer data while building?

No. Use fictional records until access controls, deletion, retention, legal basis and recovery behavior are approved and tested.

How do I reduce wasted AI credits?

Plan first, request one scoped change at a time, use direct content editing where available and preserve stable versions before structural changes.

Was this workflow tested in AI Builder?

No. It is an official-source planning workflow rechecked on 2026-08-25. Interface behavior and generated output were not independently tested.

Research notes

The workflow uses Hostinger's getting-started guide, prompt practices, troubleshooting guide, integrated-backend guidance, integration guide, code-export guide and pricing guidance. Last rechecked 2026-08-25.

Revision scope, 9 September 2026: Product naming and builder entry points were rechecked against Hostinger's current agentic-mode overview. New prompts are illustrative and were not independently executed. The wider backend, export and pricing source review above remains dated 25 August 2026.

Layout and explanation update, 12 September 2026: Reworked the runbook into four interactive checkpoints with fictional enquiry examples. The detailed instructions, original publication date and source-review dates are retained; no new hands-on product test is claimed.