Hostinger Horizons MVP Guide: Build and Validate AI Apps

Hostinger Horizons can turn natural-language instructions into a working web application, but generating an interface is not the same as validating a product or safely operating software.

An MVP still needs a real user problem, a bounded scope, accurate acceptance criteria, secure data handling, reliable authentication, tested integrations, accessible interfaces, analytics, deployment controls, and a plan for bugs and customer support. AI changes how quickly some code is produced; it does not remove product, engineering, legal, security, or operational responsibility.

Hostinger describes Horizons as an AI-powered platform for building and deploying web applications through prompts. Its capabilities are evolving quickly, including an integrated backend, code editing, data environments, online-store features, and code export. Its limitations are equally important: the environment does not work like conventional file-based hosting, exported code cannot be imported back for continued prompting, and integrated backend data currently lacks a direct export tool.

This guide explains how to evaluate Horizons, define an MVP, prompt in controlled increments, handle data and payments, test safely, deploy, monitor costs, and decide when to stay, export, rebuild, or move to a conventional development workflow.

Key Takeaways

• An MVP is the smallest product that can test a defined risky assumption, not every feature in a founder's idea.
• Start with users, problem, workflow, data, permissions, and acceptance criteria before prompting.
• Build one vertical user journey before adding secondary features.
• AI output is probabilistic and can modify more than requested; use small changes, visual editing, Undo, Restore, and a test register.
• Keep test and live data separate.
• Treat authentication, authorization, secrets, payments, and personal data as security work requiring verification.
• Do not use a redirect alone as proof of payment.
• Measure AI credits, hosting, third-party services, support, and rework as part of total MVP cost.
• Export source code regularly where the plan permits, but understand that integrated backend data may not be directly exportable.
• Do not launch a high-risk financial, medical, safety-critical, or regulated application without appropriate experts, controls, and independent review.

What “Vibe Coding” Means

Vibe coding generally describes creating or changing software by telling an AI system what the product should do while the system generates implementation details.

This can accelerate:

• Interface scaffolding
• Forms
• Basic data views
• Content layouts
• Authentication flows
• Repetitive components
• Integrations with documented services
• Prototype iterations
• Deployment setup

It can also hide complexity. A button may look correct while the permission check is missing. A payment success page may be reachable without paying. A form may store sensitive data without a retention policy. A generated database model may work for a demo but fail under real concurrency or reporting needs.

Use prompting as an implementation interface, not as evidence that the result is correct.

What Hostinger Horizons Currently Provides

Hostinger's Horizons overview describes a prompt interface, preview, visual content editing, code view, optional data view, mobile preview, publishing, and version restore.

The current technical specifications explain that:

• AI output is probabilistic.
• The model can make more changes than requested.
• A Horizons subscription and hosting are separate components.
• SSL, CDN, and caching are managed automatically.
• Traditional FTP, SFTP, SSH, and ordinary file management are unavailable.
• External APIs and databases can be integrated.
• Direct GitHub code import is not supported.
• Domains use supported nameserver or DNS-record methods.
• Code export is available, subject to plan and format constraints.

Confirm the live account, because older projects and newer integrated-backend projects can behave differently.

Step 1: Decide Whether Horizons Fits the Product

Horizons may suit:

• Internal tools with bounded access
• Simple customer portals
• Lead or application workflows
• Directories
• Calculators
• Content tools
• Lightweight dashboards
• Booking frontends connected to an approved service
• Early product prototypes
• Simple membership experiences
• Small online-store experiments
• Workflow validation before a custom build

Use greater caution for:

• Banking or trading
• Clinical or diagnostic decisions
• Emergency or safety-critical workflows
• Legal-decision automation
• Child-directed products
• High-value payment or entitlement systems
• Complex multitenancy
• Strict data residency
• Enterprise audit requirements
• Native mobile applications
• Browser extensions
• Offline-first products
• Systems requiring low-level infrastructure control

Hostinger currently lists native mobile apps, browser extensions, trading or banking applications, and 3D games among unsupported categories.

Product-fit questions

1. Can the primary workflow run in a web browser?

2. Are the required integrations documented and available?

3. Can the platform's data and authentication model meet the risk?

4. Can records be exported or otherwise retained as required?

5. Are file, storage, email, and usage limits sufficient?

6. Can the team test security and accessibility?

7. Is the hosting and deployment model acceptable?

8. What happens if Horizons or a third-party service is unavailable?

9. Can the app be migrated if it succeeds?

10. Is there a qualified owner for production incidents?

A “no-code” interface does not remove the need for technical review when business risk is meaningful.

Step 2: Define the MVP as an Experiment

Write one testable product statement:

For [specific user], who needs [problem solved], the MVP provides [single primary workflow], so we can test [risky assumption] using [metric and decision threshold].

Example:

For independent fitness coaches who lose track of client check-ins, the MVP lets a coach invite a client, collect a weekly form, and review missed check-ins, so we can test whether five pilot coaches use it weekly for six weeks.

This is more useful than “build an AI fitness platform.”

Scope the primary journey

A vertical slice should include the smallest end-to-end flow:

1. User reaches the product.

2. User understands the value.

3. User creates or accesses an account.

4. User completes the core action.

5. Data is stored correctly.

6. The user receives useful feedback.

7. The product owner can inspect the outcome.

8. The event is measured.

9. Errors have a recovery route.

Define non-goals

Explicitly defer:

• Secondary dashboards
• Advanced theme customization
• Complex roles
• Referral systems
• Gamification
• Multiple payment plans
• Native applications
• Broad integrations
• AI features not needed for the experiment

Every deferred feature protects time, credits, test effort, and clarity.

Step 3: Create the Product Specification

Before the first build prompt, document:

Users and roles

• Visitor
• Registered user
• Administrator
• Manager or staff
• Organization owner
• Any specialized role

For each role list allowed actions and prohibited actions.

User stories

Write concrete stories:

• As a coach, I can invite a client by email.
• As a client, I can submit one weekly check-in.
• As a coach, I can see only my assigned clients.
• As an administrator, I can disable an account.
• As a user, I can export or delete my records where required.

Acceptance criteria

A story is incomplete without observable results.

For “client submits a check-in”:

• Required fields are validated.
• Invalid values show accessible errors.
• The record belongs to the logged-in client.
• A second user's record cannot be viewed.
• Duplicate submission behavior is defined.
• Time is stored consistently.
• The coach sees the new status.
• The user receives confirmation.
• The event is recorded without sensitive content.

Data inventory

For every field record:

• Purpose
• Type
• Required or optional
• Owner
• Sensitivity
• Retention
• Allowed roles
• Export requirement
• Deletion behavior
• Validation
• Source of truth

Avoid collecting data merely because a form can.

Step 4: Write a Strong Initial Prompt

Hostinger's getting-started guidance recommends a short initial description and one change per later prompt. For a serious MVP, attach or include a compact structured brief.

A useful first prompt contains:

• Product purpose
• Target user
• Core journey
• Pages or views
• Roles
• Required data
• Design direction
• Accessibility expectations
• Responsive behavior
• Explicit exclusions

Example:

Build a responsive weekly check-in web app for independent fitness coaches and their clients. The first release needs a public landing page, email-based account access, coach dashboard, client check-in form, and an admin view. Coaches must only see assigned clients; clients must only see their own records. Use clear labels, keyboard-accessible forms, visible focus states, and mobile-first layouts. Do not add payments, chat, AI recommendations, social features, or additional roles.

Do not put production passwords, secret keys, private customer data, or confidential contracts in a prompt.

Step 5: Work in Controlled Prompt Increments

Horizons states that output is probabilistic and may overreach. Treat each prompt as a change request.

One change per prompt

Good:

• Add server-side validation to the check-in form without changing its layout.
• Make the coach dashboard filter only records assigned to the logged-in coach.
• Add an accessible error summary when form validation fails.
• Change only the primary button color to the approved brand color.

Risky:

• Redesign everything, add subscriptions, integrate email, improve security, optimize SEO, and create an admin system.

Specify what must remain unchanged

Include boundaries:

• Keep all current routes.
• Do not modify the data model.
• Do not change existing role permissions.
• Preserve the mobile navigation.
• Update only the selected form.

Use visual editing for content

Hostinger recommends the Edit Content mode for static text and images. This reduces credit use and lowers the chance that a simple copy change modifies logic.

Use Undo and Restore deliberately

Hostinger's undo and restore guidance warns that restoring deletes subsequent messages and does not return used credits.

After each stable milestone:

1. Record the working behavior.

2. Capture screenshots.

3. Export code when appropriate.

4. Run regression checks.

5. Label the milestone in the project log.

If a prompt causes an error loop, return to the last stable version instead of repeatedly layering repair prompts onto an unknown state.

Step 6: Design the Data Model Carefully

Horizons' integrated backend can create collections for users, forms, content, uploaded files, and application records. Hostinger documents separate Test and Live data environments.

For the coach example:

Users

• id
• email
• role
• status
• created_at

Coach-client assignments

• id
• coach_id
• client_id
• status
• assigned_at

Check-ins

• id
• client_id
• reporting_week
• completion_status
• answers
• submitted_at

Invitations

• id
• coach_id
• email
• token state
• expiry
• accepted_at

Define unique constraints, ownership, validation, deletion, and indexes conceptually even if Horizons manages the underlying database.

Test and live separation

Hostinger's Test and Live Data guide says preview interactions use Test data and published interactions use Live data.

Test that:

• Preview never changes production records.
• Publishing schema changes does not corrupt live data.
• Test users cannot access live accounts.
• Production emails are not sent during preview.
• Payment test mode and live mode are distinct.
• Seed data contains no real personal information.

Understand backend limits and portability

Hostinger currently documents limits for integrated storage and automated email, but these can change. Check the active account.

More importantly, Hostinger's integrated backend documentation currently states there is no direct data export tool for integrated backend records and files. It also warns that expired or canceled hosting can lead to permanent deletion.

Before collecting important data, define:

• Required export method
• Backup frequency
• Legal retention
• Manual or API retrieval feasibility
• Migration route
• Account-renewal ownership
• Project-deletion protection
• Incident recovery

If direct export is mandatory, validate an external database or another architecture before launch.

Step 7: Implement Authentication and Authorization

Authentication proves who the user is. Authorization decides what that user may access. A login screen alone is not a permission system.

Horizons' integrated backend currently documents email/password, email one-time codes, third-party sign-in, password reset, and account recovery options.

Test:

Registration

• Email normalization
• Duplicate accounts
• Password policy where applicable
• Verification
• Terms and privacy acceptance
• Rate limiting
• Error messages that do not expose account existence unnecessarily

Login and recovery

• Correct and incorrect credentials
• Disabled user
• Expired code
• Reused code
• Password reset
• Session expiration
• Logout
• Multiple tabs and devices
• New-browser notification where provided

Authorization

Create a role-action matrix:

Then test direct URLs and manipulated identifiers, not just visible buttons. Hiding an admin link does not protect the admin endpoint.

Step 8: Handle Secrets and Integrations Safely

Horizons can integrate with external APIs through prompts, but credentials must not be exposed in frontend code.

For every integration document:

• Business owner
• Provider account
• Test and live credentials
• Secret-storage method
• Least-privilege permissions
• Allowed origins or callbacks
• Rate limits
• Webhooks
• Retry behavior
• Monitoring
• Data shared
• Privacy terms
• Revocation and rotation
• Failure fallback

Hostinger's integration guide recommends staged testing and secure credentials.

Never paste a live secret into public client code. Inspect network requests and exported code to confirm secrets are not bundled into the browser.

Step 9: Build Payments as a Verified Server Workflow

The old article claimed “zero-code payment integrations” without explaining security. A visible checkout button is not a secure entitlement system.

For payments:

1. Create the product or price in the provider.

2. Create checkout on the server or approved hosted flow.

3. Receive a signed webhook.

4. Verify the signature.

5. Record an idempotent transaction.

6. Grant the correct entitlement.

7. Handle failure, cancellation, refund, dispute, and subscription expiry.

8. Reconcile provider records with the application.

Do not unlock paid content merely because the browser returns to a success URL.

An older Hostinger Stripe integration article explicitly warns that a redirect-only approach lacks backend validation and can be bypassed. Newer subscription and ecommerce integrations may provide more complete workflows, so confirm which architecture the project uses.

Test:

• Test payment success
• Decline
• Abandoned checkout
• Duplicate webhook
• Delayed webhook
• Forged callback
• Refund
• Chargeback
• Subscription cancellation
• Failed renewal
• Plan upgrade and downgrade
• Currency and tax
• Customer portal
• One user accessing another user's entitlement

Do not process high-value or regulated transactions without suitable professional implementation and review.

Step 10: Design for Accessibility

Include accessibility in requirements, not as a final prompt.

Test:

• Keyboard-only navigation
• Visible focus
• Heading hierarchy
• Form labels
• Error identification
• Error summary and focus movement
• Status announcements
• Color contrast
• Text resizing
• Reduced motion
• Alternative text
• Modal focus trapping
• Touch target size
• Mobile screen readers
• Authentication and one-time code flows

AI-generated interfaces can look polished while lacking labels, semantic structure, or predictable focus.

Use automated tools for coverage and manual assistive-technology testing for real behavior.

Step 11: Test the MVP Systematically

Create a test register with ID, role, precondition, action, expected result, actual result, evidence, severity, and status.

Functional tests

• Happy path
• Required fields
• Invalid input
• Empty state
• Duplicate action
• Refresh
• Back button
• Direct URL
• Concurrent edits
• Network interruption
• Third-party failure
• File upload
• Email delivery
• Mobile layout

Permission tests

For every role, attempt:

• View another user's record
• Edit another user's record
• Change a URL identifier
• Call an action without the visible button
• Open admin routes
• Change role values
• Reuse expired invitations
• Access after logout or disablement

Security review

• Secrets absent from frontend
• Input validated
• Output encoded
• Upload restrictions
• Rate limits
• Session protection
• Authorization enforced
• Error messages safe
• Dependencies reviewed after export
• Privacy and retention implemented
• Abuse reporting
• Logs do not expose secrets or personal data

Arrange independent review when the application handles money, sensitive personal information, business-critical operations, or a broad public audience.

Performance

Test real user journeys on mobile and slower conditions. Inspect JavaScript, images, third-party integrations, API latency, and large data views.

Hostinger says Horizons assets use CDN delivery and image optimization, but third-party scripts and generated application behavior can still be slow. Use field and lab measurement rather than a generic optimization claim.

Step 12: Configure Analytics Around the MVP Hypothesis

Track only what answers product questions.

For the coach example:

• Landing view
• Invitation created
• Invitation accepted
• Check-in started
• Check-in completed
• Coach reviewed check-in
• Weekly active coach
• Weekly active client
• Error
• Support request

Do not put sensitive form answers into analytics.

Define:

• Event name
• Trigger
• Required properties
• Consent basis
• Owner
• Validation test
• Decision it supports

MVP metrics can include activation, task completion, retained use, time to value, error rate, and interview evidence. Page views alone do not validate a product.

Step 13: Control AI Credit and Total Cost

Horizons uses a dynamic credit model. Hostinger's current pricing documentation says credit use depends on the computing resources required by each request, including non-coding interactions.

Reduce waste by:

• Defining scope first
• Asking one change at a time
• Using visual editing for copy and images
• Restoring after a broken change instead of entering an error loop
• Reusing tested prompt patterns
• Recording acceptance criteria
• Running tests before adding another feature
• Avoiding broad redesign prompts
• Monitoring the credit dashboard

Total MVP cost includes:

• Horizons subscription
• Hosting
• Domain and email
• AI top-ups
• Payment and third-party services
• Monitoring
• Legal and privacy review
• Security testing
• Design and content
• Customer support
• Rework
• Export and migration work

Compare cost per validated assumption, not cost per generated screen.

Step 14: Prepare Deployment and DNS

Hostinger requires hosting for a deployed Horizons project. Confirm subscription and hosting renewal ownership separately.

Pre-deployment checklist

• [ ] MVP scope and non-goals approved
• [ ] Functional acceptance tests pass
• [ ] Authorization matrix tested
• [ ] Test data contains no real personal data
• [ ] Secrets stored safely
• [ ] Payment verified server-side
• [ ] Privacy, terms, and contact details published
• [ ] Accessibility reviewed
• [ ] Analytics and consent tested
• [ ] Error and support route available
• [ ] Live emails and domains verified
• [ ] Source code exported
• [ ] Live-data backup strategy approved
• [ ] Rollback point recorded
• [ ] Hosting and subscription renewals assigned

Protect DNS and email

Hostinger's domain-pointing guide supports nameserver or specific DNS-record approaches.

Changing nameservers can replace the active DNS zone. Preserve and recreate required MX, SPF, DKIM, DMARC, verification, and subdomain records. Record the previous DNS state and rollback steps.

Use a subdomain for a pilot when appropriate, such as app.example.com, to avoid disrupting the primary website.

Publish and smoke-test

After deployment:

• Open the custom domain.
• Confirm HTTPS.
• Test registration and login.
• Complete the primary workflow.
• Test permissions.
• Verify emails.
• Verify payment test or authorized live flow.
• Check analytics and consent.
• Test mobile.
• Monitor console, network, and application errors.

Step 15: Understand Code Export and Lock-In

Hostinger's current code export guide says an active Horizons subscription can export a Node.js project built with React and Vite.

It also says:

• The project is downloaded as a ZIP.
• Coding knowledge and Node.js tooling are needed for manual work.
• Edited exported code cannot be imported back into Horizons for continued prompting.
• The export can be deployed outside the builder, subject to application dependencies and backend architecture.

Code portability and application portability are not identical. The exported frontend may depend on:

• Integrated backend
• Authentication
• Stored files
• Emails
• Environment variables
• Hostinger APIs
• Payment webhooks
• Domain settings
• Third-party services
• Live data that cannot be directly exported

Run an exit test before launch:

1. Export the code.

2. Install and run it in a clean environment.

3. List missing variables and services.

4. Identify backend dependencies.

5. Determine how data would migrate.

6. Estimate rebuild work.

7. Document DNS and deployment steps.

8. Confirm licenses for assets and dependencies.

If the exit test fails, classify the lock-in consciously rather than discovering it during an emergency.

Step 16: Decide After the Pilot

At the agreed review date choose:

Continue in Horizons

Appropriate when usage is validated, risks are controlled, platform limits fit, and the operating team can maintain the app.

Continue with tighter scope

Remove unused features, reduce integrations, improve the core workflow, and keep testing.

Export and continue conventionally

Appropriate when the concept is validated but needs deeper code control, testing, infrastructure, integrations, or engineering workflows.

Rebuild on another platform

Appropriate when data portability, compliance, scalability, native mobile, advanced multitenancy, or unsupported features are mandatory.

Stop

A good MVP can disprove an assumption cheaply. Archive required data, revoke integrations, cancel unused services, preserve records, and document the learning.

Common Hostinger Horizons Mistakes

Starting with a giant prompt

Broad prompts create more unverified behavior and consume more credits. Build one vertical journey.

Treating preview as production proof

Preview does not validate live DNS, email, payment, consent, load, or user behavior.

Checking authentication but not authorization

A user being logged in does not mean they should access every record.

Unlocking access from a return URL

Payment must be verified through a trusted server-side process or approved integrated workflow.

Assuming code export includes portable live data

The integrated backend currently lacks a direct export tool. Test the complete migration, not only the ZIP download.

Storing secrets in prompts or frontend code

Use approved secret and environment-variable mechanisms, then inspect the browser bundle and network.

Using real customer data in preview

Use synthetic test data. Keep Test and Live environments separate.

Measuring output instead of learning

Screens, prompts, and generated lines are not product validation. Measure user outcomes and decisions.

Ignoring ongoing ownership

Someone must own renewals, incidents, support, security, privacy requests, integrations, and data retention.

Hostinger Horizons MVP Checklist

Product

• [ ] User and problem defined
• [ ] Risky assumption stated
• [ ] Primary journey scoped
• [ ] Non-goals listed
• [ ] Success and stop thresholds agreed
• [ ] Pilot users identified

Data and security

• [ ] Data inventory complete
• [ ] Collection minimized
• [ ] Roles and permissions documented
• [ ] Authorization tested
• [ ] Secrets protected
• [ ] Test and Live data separated
• [ ] Retention and deletion defined
• [ ] Export and backup strategy approved
• [ ] Independent review completed where risk requires it

Build

• [ ] Initial prompt bounded
• [ ] One change per prompt
• [ ] Acceptance criteria tested after each change
• [ ] Visual editor used for static content
• [ ] Stable restore points recorded
• [ ] Credit use monitored
• [ ] Code exported at milestones

Launch

• [ ] Domain and DNS protected
• [ ] HTTPS active
• [ ] Emails verified
• [ ] Payments tested securely
• [ ] Accessibility reviewed
• [ ] Analytics and consent tested
• [ ] Support process live
• [ ] Rollback path documented
• [ ] Renewals assigned
• [ ] Monitoring enabled

For implementation help, review our custom web application development services and website planning consultation.

Frequently Asked Questions

What is Hostinger Horizons?

Hostinger Horizons is a prompt-based platform for generating, editing, and deploying web applications. Current features include preview, visual editing, code view, optional integrated backend, authentication, data management, publishing, and code export.

Do I need coding experience?

Hostinger says coding is not required to begin, but complex products still require clear specifications and web-development understanding. Security, payments, data, and production debugging benefit from qualified technical review.

Can Horizons build a full SaaS application?

It can build web applications with accounts, data, emails, payments, and subscriptions, subject to current limits. A production SaaS also needs authorization, billing lifecycle, data portability, observability, support, compliance, and tested operations.

Does Horizons include a database?

Newer projects can use an integrated backend for data, users, files, and emails. Some older projects use external services such as Supabase. Confirm the project architecture before planning migration or backup.

Can I export my Horizons app?

Hostinger currently supports exporting a React/Vite Node.js project with an active Horizons subscription. The exported project cannot be imported back for more prompt-based editing.

Can I export integrated backend data?

Hostinger currently states there is no direct export tool for integrated backend records and uploaded files. If portability is required, investigate and test an external data architecture before collecting production data.

Is Hostinger Horizons secure?

The platform provides managed and integrated features, but application security still depends on generated logic, permissions, integrations, secrets, data choices, and testing. Security cannot be established from the platform name alone.

Can I accept payments?

Horizons supports store, payment, and subscription approaches, but architecture matters. Use current integrated flows or verified server-side checkout and webhooks. Do not trust a browser redirect alone.

How much does an MVP cost?

Cost depends on Horizons credits, hosting, domain, integrations, payment fees, review, testing, support, and rework. Use the live pricing page and track total cost per product assumption tested.

Can Horizons create a native mobile app?

Hostinger currently says Horizons does not create native App Store or Google Play applications. It builds web applications, which may be usable on mobile browsers.

What happens if the Horizons subscription is cancelled?

Hostinger's technical documentation says the published app can continue while hosting remains active, but prompt editing and code export can depend on an active Horizons subscription. Verify the current account terms and preserve required assets before cancellation.

Final Recommendation

Use Hostinger Horizons to shorten the path from a clearly defined product hypothesis to a testable web application. Do not use it to skip requirements, security, accessibility, payment verification, or data planning.

Build one end-to-end journey, make one controlled change at a time, and test every role and failure path. Monitor credits and total operating cost. Export the code and test the exit route before the product becomes dependent on live data.

The value of an AI-built MVP is not how quickly it appears. Its value is how safely and cheaply it helps the team learn whether a real user problem is worth solving.