Skip to content
All writing
Parchment devlogPart 5 of 5

Where Parchment is today

In this series

  1. 1Why I'm building my own maps appI've spent most of my spare time since 2023 building Parchment, a maps app for people who walk, bike and take transit. Here's why I started it and what I want it to become.
  2. 2How Parchment started on free public APIsThe first version of Parchment was a Vue app wired up to free, open source map services. That worked well for a while, until rate limits, mismatched data formats and outages started getting in the way.
  3. 3Making map providers swappableParchment's code used to reference every map service by name, which made changing anything painful. I borrowed the way Home Assistant handles devices, and now switching providers doesn't mean rewriting features.
  4. 4How Barrelman spun out of ParchmentThe APIs I depended on couldn't do a lot of what I wanted, so I started building my own backend for search, routing and map tiles. It ended up becoming a separate product with its own business model.
  5. 5Where Parchment is todayYou are hereParchment is in closed alpha with a small group of testers. Here's what's working so far, and what I want to finish before opening up a beta.

Parchment is in closed alpha right now. There’s a waitlist, a small group of people use it every day, and it still has plenty of rough edges.

It runs on web, iOS, Android and desktop from one codebase, and the whole thing can be self-hosted.

What works#

  • Search and places. 44 browse categories, including ones other maps skip like drinking water, benches, bike parking and defibrillators. Place pages translate OpenStreetMap tags into plain language, in your own language where mappers have recorded one, and show opening hours in the place’s own time zone.
  • Directions. Driving, cycling, walking and transit, with departure boards, isochrones and a carbon estimate for each route.
  • The map. A globe at low zoom, day and night styles, indoor floor plans, and street-level imagery from Mapillary. There are also layers for weather, air quality from OpenAQ and active wildfires from NASA FIRMS.
  • Your own data. Saved places and collections, offline regions, optional location history that stays on your server, and OpenStreetMap editing, so if a place page is wrong you can fix it at the source instead of submitting a report and hoping someone reads it.
A transit leg lists the next several departures and keeps the ones you've already missed on screen.

What I’m working on#

What’s left is mostly polish. I want to be able to hand it to someone without a list of caveats.

The interface. A lot of the app works but isn’t good yet. This is the slowest part by far, because it mostly comes down to using the app a lot and fixing things by eye.

Native mobile apps. Parchment already runs on iOS and Android, but from the same codebase as everything else, and you can tell. I’m planning native clients that follow each platform’s design guidelines instead of reusing the same interface on both. People open a maps app one-handed in a subway station, so it should look and feel like it belongs on their phone.

Transit. This is where most of the real bugs are, and they matter more than most, since a wrong departure time can make someone miss their train and wait twenty minutes for the next one.

Getting facts right. Opening hours, closures, and all the small differences between what’s in OSM and what’s actually true on the ground. I’d rather show nothing than tell someone a place is open when it isn’t.

Running planet-scale servers reliably. Building Barrelman and keeping it running turned out to be very different jobs. Imports need to finish, indexes need to stay up to date, and queries need to stay fast with the whole planet behind them. It needs to be efficient enough that the free tier is sustainable, and stable enough that people can rely on it for directions when they’re already running late.

The commercial side. Billing and the paywall for Barrelman’s free-for-individuals model. That’s the last big piece I need to build.

Getting to beta#

The waitlist lets me bring people in slowly enough that I can actually fix what they find. Alpha testers know they’re testing something unfinished, but beta users will reasonably expect it to work.

So the next step is a limited beta, with a small group of testers and possibly only a few regions to start.

I’ve been talking with municipal governments and other engineers about what that rollout could look like. In some places it might be a partnership, and in others it could become a business that pays for itself. Either way, I don’t want any of it to come at the expense of the product.

If you want to try it, you can join the waitlist.