What We Build in Public

AngoraTek is a small geospatial consultancy, and four of our works are live on the public internet right now. Two are open-source repositories, one is a free route planner, and one is an official site for a trail-running festival at South Lake Tahoe. A consultancy that cannot show you code is asking you to trust a slide deck, so we keep ours on the table.

The framing worth arguing with: this is our R&D and our portfolio in a single act, and the two roles feed each other. The consultancy funds things it needed that nobody had built. What survives gets published, strangers stress-test it, and what we learn running it in production shows up in client work. What breaks in production shows up here as a post. Nothing on the list is a marketing layer; every item started as a tool someone on the team actually needed.

Five vendors could not agree, so the disagreement became a library

The first repository, everymap-rs, exists because asking HERE, Google, TomTom, Mapbox, and Radar the same question produces five answer formats and, where they answer at all, five opinions about what an isochrone is. We kept needing to test them against each other for client work, so we built a unified Rust client. Ten domain traits get one interface each; the providers implement them unevenly, 35 implementations in all, from HERE's ten domains down to Radar's four. The version you can pull is young, 0.2.2, first published 2026-09-15, and it says so on the crate page rather than hiding behind a mature-looking 2.0.

Vendors disagree in load-bearing ways, and the library's job is to make those disagreements cheap to test rather than to hide them. When Google cannot answer a traffic query, the error says so plainly instead of returning something that looks like data. That design choice gets its own earlier post in this series, and it is the part we would keep even if we rewrote everything else.

The bindings nobody else maintained, so somebody had to

The second repository, here-sdk-for-maui, fills a quieter gap: there was no maintained official .NET binding for the HERE SDK 4.x Explore Edition, and developers building cross-platform apps with MAUI were left wrapping it themselves, badly. Ours gives one idiomatic C# API for maps, search, routing, and traffic on Android and iOS, with a reference app in the repo that exercises all of it.

The iOS side carries the war story, told here in one short paragraph. HERE's iOS SDK is Swift-only, while .NET binds to Apple's side through Objective-C. So the project wraps the Swift SDK in a Swift NativeBridge framework, re-exposes the API with @objc, and binds that through Objective Sharpie, the pattern the MAUI Community Toolkit recommends. It works, and it stays honest by shipping an iOS framework of about 831 MB (stripped where we could) and one documented gap where a map pick returns null on iOS. We would rather publish a known limitation than a clean README that hides one.

The route planner that keeps our engineering honest in production

WayMaker started as a product and turned into the thing we point skeptics at. It is free and installable, and it takes plain English. Ask for "a shaded 10k loop near Tahoe with lake views" and it generates an optimized route with an elevation profile and a paved-versus-trail breakdown, exportable to GPX. Under that surface sits our own backend, including a server-side routable trail graph the router runs on, with sources credited inside the app.

WayMaker is also where our discipline around offline and tiles gets enforced by reality rather than by code review. The offline recipe that sounds reasonable, cache what the user touched today, fails the actual use case: a map cached at home on Thursday can be blank on Sunday, where the signal never arrived. A hiker who loads a route at home and walks it on Sunday needs the tiles from Sunday, on a device that may spend the whole day out of signal. That is why the app's tile cache is cache-first, never expires, and never evicts: a cached tile stays valid forever. Reality kept the design honest, and the same production instincts are what we bring when a client needs offline maps that survive a dead zone.

And one sentence about the fourth item: the official site for a two-day trail-running festival at South Lake Tahoe, built directly on the race's real course traces, is live at tahoeskyrace.com.

What publishing buys, and what it cannot

The four projects work as R&D because they are live. Strangers break things we would not have tested, and a trail runner filing an issue from a ridge with a dying phone battery is a testing environment no plan of ours covers. Those lessons come home. The trait design in everymap shapes how we architect client integrations. The tile-cache decisions in WayMaker have already been defended in production, against actual hikers on actual ridges, and we would defend the same ones in your project.

What publishing cannot buy is a substitute for case studies it would be dishonest to write. Client work stays private; these four projects are tools and products we own, which is why they can be public at all. They are also young, and we will not quote adoption numbers, because numbers at this age would flatter us and tell you nothing. If you want to assess us, the code is open, the products are live, and the failures are documented in the issues and the posts. That is the entire trust-building apparatus, and it is enough.

Read the repo before the pitch page. It is the most honest page we own, and it was written by the same people who will build yours.

AngoraTek is a small geospatial consultancy building geospatial platforms, data pipelines, agentic systems, and managed web and mobile products. Talk to us, or just keep reading.