Build with Hostinger Horizons by defining one user and one outcome, creating the smallest working flow, adding data and authentication only when required, and testing every state before publishing. Use short, specific prompts and save stable versions. Do not begin with a large all-in-one prompt or real customer data.
- 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.
- 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 Horizons tutorial. Interface labels can change, so follow the current product guidance alongside the checks below.
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.
Step 3: establish the public flow first
Test the form without authentication or production data. Check:
- labels remain visible and are associated with inputs;
- required fields explain what is missing;
- email format validation is understandable;
- double submission is prevented;
- success and failure messages do not expose technical details;
- the form works at 390px, 768px and desktop widths;
- 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.
Horizons' 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:
| State | Expected result | Failure to prevent |
|---|---|---|
| Signed out | Cannot open owner records | Private data rendered before redirect |
| Wrong account | Cannot read or change owner data | Guessable URL exposes records |
| Owner | Can perform documented actions | Over-broad delete or export capability |
| Expired session | Returns safely to sign-in | Action continues with stale permission |
| Password reset | Verified recovery only | Account 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
Horizons 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 Horizons creation access or hosting ends.
Our Hostinger Horizons review explains the current plan and infrastructure boundaries. Use “View current offer” rather than relying on an old promotional price.
Step 9: publish with a release checklist
Before publishing:
- replace sample copy but keep test accounts separate;
- verify canonical URL, title, description, favicon and social image;
- add privacy, contact and terms information appropriate to the app;
- validate authentication and authorization again;
- confirm forms and transactional email from a permitted test address;
- verify domain, HTTPS and mobile behavior;
- confirm analytics and consent choices;
- document rollback and data-retention steps;
- 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 Horizons OfferFrequently asked questions
Frequently asked questions
What should my first Horizons 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 Horizons 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 Horizons?
No. It is an official-source planning workflow checked on 2026-08-01. Interface behavior and generated output were not independently tested.
Official sources reviewed
The workflow uses Hostinger's getting-started guide, prompt practices, troubleshooting guide, integrated-backend guidance, integration guide, code-export guide and pricing guidance. Last checked 2026-08-01.
