> For the complete documentation index, see [llms.txt](https://sdk.metamarket.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sdk.metamarket.tech/overview/problem-and-value.md).

# Why MetaMarket

Most live games need the same three groups of systems: quests and progression, rewards and inventory, and currencies with energy and quotas. Studios build them for the first title and build them again for the next. This page is about why that second build is worth avoiding, and what you give up by avoiding it.

## The cost is in the connections, not the parts

Each of these systems is a small engineering project. A wallet has to never double-spend. Energy has to regenerate correctly across time zones. A quest has to survive a player closing the app halfway through a step. None of that is exotic, and a competent team can build any one of them.

The expense arrives when they have to work together. A live game acquires a purchase flow, an energy timer, an achievement tracker, and a reward pipeline, each with its own data model and its own edge cases. Because they share no common model, quest logic, economy logic, and reward logic drift apart, and that drift usually appears in production rather than in review. Every new mechanic then adds both code to ship and more state to keep consistent.

That work does not shrink as the game matures, and none of it transfers to the next title.

## What changes when a mechanic is configuration

MetaMarket runs one engine for all three groups. You describe a mechanic as configuration the engine reads at request time, rather than as a service you write and deploy. You declare which actions your game sends, what each one does, and how your resources behave, and the same engine interprets those declarations for every game on the platform.

Two things follow:

* Tuning a reward, adding a quest, or changing a regeneration rate becomes a configuration change. It reaches the running game with no client release and no redeploy.
* One engine sits beneath every mechanic, so it is hardened once rather than service by service.

## What you give up

A mechanic has to fit the parts the engine already understands: actions, resources, quests, packages, refillable quotas, and a shared delivery path. Most live-game loops do fit, including daily quests, progression, rewards, inventory, energy and quotas, shops, and player listings. A genuinely novel mechanic can still require engine work, and that work is ours rather than yours, which means it moves at our pace and not your release schedule. The [Roadmap](/releases-and-reference/roadmap.md) shows where the engine is being extended.

You also trade self-service for assistance. Registration and configuration are prepared with the MetaMarket team, which means a configuration change goes through us rather than through a console you control.

## The argument gets stronger with each title

For a single game, the case is straightforward: you skip building a backend and spend the time on the game. For a second game, you skip building it again, and you also gain something you cannot get by building separately. Your returning players already exist at the platform level, and the loyalty standing they built in the first title follows them into the second.

That is the part a per-game backend cannot give you at any price, because it requires a layer that sits above both games and belongs to neither. [What You Can Build](/overview/capabilities.md) walks through the systems that layer and the engine provide.