Building a game backend initially sounds like a list of technical features: authentication, cloud saves, leaderboards, remote config and crash reporting. Those features matter. A useful backend as a service only emerges when API, dashboard, SDKs, documentation, pricing and operations fit together.
That is what we are learning with horizOn. The platform is designed for smaller studios, indie developers and teams that need backend features without building their own server platform.
horizOn is more than a game project for us. It is a substantial SaaS product that demonstrates general lessons about software development and live operations.
1. The API is only part of the user experience
A clean endpoint is not enough when a developer does not know which key is needed, how to create a project or where an error becomes visible.
horizOn therefore connects several surfaces:
- a dashboard for projects, API keys and live-ops features,
- a backend with separate admin, app and public APIs,
- SDKs for Unity, Godot and Unreal,
- a REST integration for other languages and engines,
- quickstarts, examples and video tutorials,
- monitoring, support and changelogs.
The horizOn quickstart does not begin with the complete API reference. It follows the smallest successful workflow: create an account, create a project, download the configuration, install an SDK and connect.
2. An SDK is product code, not a side task
An HTTP endpoint may look unambiguous to the platform team. A game developer experiences the same function through their engine.
Unity, Godot and Unreal have different package models, lifecycles and conventions. A good SDK does not hide every technical fact, but it translates the API into the language of the tool.
That creates additional product work:
- installation must be reproducible,
- configuration should not be scattered across secrets,
- error messages need to make sense in the editor,
- examples must match the current SDK,
- backend changes must not unexpectedly break shipped games.
The SDKs are therefore developed together with example projects, quickstarts and explicit compatibility boundaries.
3. Live-ops features need a shared model
Cloud saves, leaderboards and remote config are not isolated switches. They use the same projects, users, API keys and permissions.
If every feature invents its own model, the platform becomes unpredictable. horizOn separates access:
- dashboard users manage projects and settings through the admin API,
- games and apps use project API keys with the app API,
- public workflows remain intentionally limited.
This separation adds work, but it prevents a key embedded in an application from gaining administrative control.
4. Pricing is an architecture decision
horizOn uses fixed, transparent packages instead of charging for every API call. That is a product position, but it also shapes the architecture.
Fixed pricing only works when capacity, limits and operating cost are modeled clearly. The platform needs to know which resources belong to a plan without confronting developers with a long list of small charges.
We want a successful launch to remain good news rather than automatically producing an unpredictable bill. We also state openly that fixed capacity is not the same as unlimited dynamic scaling.
That honesty is part of the product. A pricing promise without a technical boundary would only be advertising.
5. Multiple regions multiply responsibility
Low latency in different parts of the world sounds like an infrastructure feature. In practice, it affects almost every operational process:
- deployments need controlled rollout,
- databases need backups and restore tests,
- monitoring must show regional differences,
- certificates, DNS and network rules need consistent management,
- errors need enough context to identify an affected region.
The public horizOn status page shows service state. Behind it is ongoing work on clusters, databases, backups, alerting and release processes.
A SaaS product is not ready because it works locally. It becomes dependable through repeatable operations.
6. Your own products are the hardest integration test
ProjectMakers uses horizOn internally, including authentication and cloud storage for BodySeasons. This exposes the same questions external teams face. How quickly can an integration be completed? Which error message helps? What happens when a connection is interrupted?
Internal use reveals problems that an isolated demo does not. It still does not replace feedback from other developers. Quickstarts, support questions and real integrations belong in the same improvement process.
7. An open exit reduces lock-in
A backend is a long-term dependency. Developers need to know what happens when requirements grow or a provider no longer fits.
The managed platform is complemented by the horizOn Simple Server on GitHub. The intentionally small PHP implementation supports core SDK workflows and can be self-hosted.
It does not replace every feature of the managed product. It provides a transparent starting point and a way to control central workflows.
Lessons we transfer to other SaaS products
The main lessons are not tied to one game engine:
- The first successful workflow matters more than the complete feature list.
- Integrations and SDKs are part of the user experience.
- Pricing promises need technical boundaries.
- Monitoring, backups and support are product features.
- A credible exit path increases trust.
horizOn.pm describes the platform, features, pricing, quickstart and limitations publicly. Our portfolio provides additional context on the role ProjectMakers plays in product, SDK and operations work.
If you are planning a platform, API or SaaS product, we can define the first useful workflow and operational boundaries together. Tell us about the product.
