Routie
Denva's own product: a shop and a 3D configurator for framed prints of uploaded routes, built from scratch instead of on a ready-made platform. The customer uploads a tracked route, composes a print, and the same configuration yields both the print-ready PDF and the file the 3D printer runs.
A shop with nothing in stock. Every print is made after the order, from a route the customer uploads, and it has to be manufacturable to the millimetre.
Routie is not a catalogue. The customer uploads a tracked route from their app or device, composes a print from it, and we manufacture that print: the route is 3D printed as a matte PLA relief, glued onto glass, with the printed map behind the glass inside a frame. So a configuration made in a browser has to produce a manufacturing file, not a picture. That is a different job from a shop, and no ready-made platform does it or can be pushed into doing it with plugins.
The second layer is risk. With made-to-order goods there is no change-of-mind return, so a wrong file means a discarded print and an angry customer. That is why we did not only build a configurator, we built the brakes too: the print file has to be reproducible, the proof has to prove it describes the same print, and production must not start when those two drift apart. Add maps that must not depend on somebody else's API key, because here the map is part of a physical product and tile licence terms can change.
4 rozhodnutia, ktoré zmenili všetko.
-
01
Our own platform, not a ready-made shop
Next.js with the App Router, TypeScript in strict mode, PostgreSQL and Drizzle: 91 tables and 33 migrations. It is built from scratch precisely because the configurator is the heart of the project, and a configurator like this cannot be bolted onto a ready-made platform. The platform core is also separated from the Routie layer, and that boundary is proven by a test rather than by agreement: a synthetic shop selling standard products completes checkout in CI without loading a single Routie package.
-
02
A configurator that ends in a manufacturing file
The configurator is the core of the whole project and we built it from scratch. The customer uploads GPX, TCX or KML; the format is sniffed from the file's root element, never from its name or MIME type. They pick from 25 templates, three formats, two frames and 17 map styles, or take one of 40 Formula 1 circuits and 37 iconic routes. A single render pass produces the 300 dpi print PDF, the customer's proof and a binary STL in millimetres, so the proof and the print file cannot describe two different prints.
-
03
Self-hosted map tiles instead of somebody else's API
We serve the maps ourselves: over 600 GB of our own PMTiles archives built from OpenFreeMap vector data and Mapterhorn elevation data. Not one map request carries a third-party API key, so the map that is part of a physical print depends on nobody else's licence terms and on nobody else's uptime.
-
04
Brakes that stop a bad print
Before production the proof is compared against the print file, with a tolerance of 2 % of pixels and 0.3 mm of geometric deviation. On a mismatch the printing state cannot be reached until an operator clears it with a stated reason. The render itself runs in an isolated origin that knows neither the database nor the object store, and the process refuses to accept a single job at start-up if its probe reaches the network.
Jedna
spoločná reč.
Čo sa po spustení
zmenilo ,
Boring tools.
Predvídateľný výsledok.
You bring the idea. We handle the rest.
Tell us what you need. We will reply within one business day with an honest take on whether we are the right fit, the scope and timeline we see, and a custom quote.