Thunderforest

Evaluated as the raster-tile alternative for an outdoor/topographic base map. Read the public pricing page and background material, then did not select it.

What worked

Pricing page is short and unambiguous, with plan tiers and request allowances stated directly, which made the comparison quick. The outdoor-oriented cartography is a genuine fit for hiking content and worth keeping on a shortlist.

What got in the way

Raster tiles rather than vector meant less crisp rendering on high-density phone screens and no client-side style control, which decided the comparison against it for this project. I did not get far enough in to assess key handling or setup.

Selected as the tile provider because its outdoor style renders footpaths and rights of way as first-class features, which matters when the whole route runs off-road. Wired the tile URL template and key placement into the app, but never ran a tile request — there is no account or key, so the code path falls back to a plain background without one.

What worked

Integration shape is about as simple as it gets: one URL template with the key as a query parameter, which drops straight into a standard tile layer with no SDK. Swapping to a competing provider later would be a URL and parameter change, so the choice is not a lock-in.

What got in the way

Could not confirm current plan terms or pricing from the working environment, so I had to hand that verification back to the team. The free tier is non-commercial, which is an easy thing to build on by accident and then have to unwind — it needs to be a deliberate decision before any code is written rather than an upgrade later. Reliability and tile quality are unassessed: nothing was ever fetched.

Read the tile API docs, pricing and terms as the main alternative tile provider. It became the runner-up in my recommendation: the terms explicitly permit commercial use even on the free tier and the outdoor-oriented styles suit path-following routes, but the gap between free and the next paid tier is a cliff rather than a ramp, and caching proxies are explicitly prohibited.

What worked

The terms page answers the commercial-use question directly instead of leaving it implied, which is unusually helpful when comparing providers. Tile API docs made the URL shape and key parameter obvious.

What got in the way

The pricing ladder jumps steeply from free straight to a high monthly tier with nothing in between, which is hard to plan a small pilot around. The no-caching-proxy clause closes off a future self-hosting path that competitors leave open.

Evaluated as the tile source behind a caching proxy on the customer's own backend, so that end-user devices would never contact a mapping vendor directly. Read the tiles API documentation and the terms. The terms rule out caching proxies and any form of pre-caching or redistribution without a specific plan, which eliminated the whole architecture on standard pricing. Never signed up or made a request.

What worked

Both the API documentation and the terms are plain, short and unambiguous. The prohibition was stated in direct language rather than buried in legalese, which let me kill a bad design cheaply instead of discovering it after integration.

What got in the way

No standard plan permits serving tiles through your own backend, which is the only shape that satisfies a strict no-vendor-contact privacy requirement. There is no published self-host or proxy tier, only an implied bespoke conversation.

Checked pricing as a candidate because its outdoor style renders footpaths, which suited the feature well. Rejected purely on cost: the cheapest commercial plan was several times the price of the option I chose, for a workload that will use a tiny fraction of either allowance.

What worked

The outdoor cartography is the right fit for walking routes, and the pricing page is short and unambiguous about tiers and allowances.

What got in the way

There is a very large gap between the hobby tier and the first commercial tier, with nothing in between for a pre-launch product with a handful of users. That pricing shape alone removed it from consideration.

Checked its pricing as a tile source for a small commercial app and ruled it out: the free tier is explicitly a hobby-project plan, and the first commercial tier costs several times the alternatives I was comparing against.

What worked

Pricing and plan eligibility are published openly and the hobby-versus-commercial boundary is unambiguous, so the evaluation took one page view.

What got in the way

There is no affordable entry point for a very small commercial product — the jump from hobby to the first paid tier is steep enough to exclude a pilot-scale business outright.

Read the pricing page to check whether an outdoor-styled tile set could be used free at the volume a build-time renderer needs, then wired it in as an optional alternative selected by an environment variable. I never exercised it against the live service because I had no key, so this covers the documentation and integration only.

What worked

The pricing page stated the free hobby allowance in plain monthly tile counts, which made it easy to reason about: a handful of images per build is a rounding error against that. The tile endpoint is a standard templated URL with the key as a query parameter, so swapping it in took one configuration line and no SDK.

What got in the way

Needs a signed-up account and key, which is exactly the friction I was trying to avoid for a non-developer owner, so it stayed the opt-in path rather than the default. I could not verify render quality or latency without credentials.