Our mission, democratizing map making, is a lofty one that requires building for the next generation of point-and-click map makers. Sam and I knew most maps are shared on the web, but a lot of the time they are – to borrow a phrase from design tools – flattened. We wanted to make sure our maps consisted of composable pieces that you can not just see, but tinker with and “right-click” into. Not only that, we also wanted to make sure you could indeed create these maps on the web, without having to download or install anything. And if we did everything right, we knew sharing would be as simple as just copying and pasting a URL into an email or a tweet. The web, we knew, had all these primitives built in.

Over its existence, the web has evolved from a document sharing platform with a rigid request-response cycle to supporting full-fledged desktop class tools, ushering in new user expectations and experiences. For example, we now rightfully want things to save without having to CMD-S (phew!), we want our changes to be instantly reflected in our colleague's browsers, and we want to easily share our work via links–not double digit MB pdf files. This "multiplayer" environment is highly complex to build, but when done right, changes the way users work and what users are capable of producing, and is fundamental to building any application that meets users expectations for the decades to come. 

Achieving our simple mission required a complex solution. How could we build a brand new type of interaction, a spatial UI, while also making it “multiplayer”? Set aside the technical challenges, how would it even work for the users? For example, what did it look like when you had multiple people on a map, and one of them zoomed out to continent level and another person looking at street level data? What does it mean to make an annotation, say, on the city level view that has to be visible to others who might be looking at another part of the world at the time?

We knew we didn’t have the answers but we knew how we would get them (or try to): by iterating as fast and as many times as possible. Our respect for the challenge of the unknown has driven the technological decisions and investments we’ve made to date. We knew there was no other way to build a collaborative, complex product without making it easy to build and test the product itself. 

You’ll in fact find this idea permeate through all our blog posts already. Julius Tarng, for example, thrives on prototyping and works tirelessly to make experimenting with new ideas as seamless and fun as possible. And when we ran into one of our first speed bumps with complicated state changes being lost across page refreshes, Jason Axelson picked up the mantle and implemented Hot Reloading across our Phoenix application. This was uncharted territory for everyone involved, and we are also happy to have contributed our learnings to the community.

At the time, however, we did not fully understand the impact Hot Reloading would have across the organization. Soon we heard from Mamata Akella, our cartographer, that Fast Refresh accelerated basemap production work. Having a culture of fast iteration pays dividends in unexpected places. This is 'what it takes to make a map.'

As Chief Technology Officer, I think about iteration from the perspective of shortening the time it takes to get from idea to reality. That’s why we’ve built an infrastructure where every single code change spins up an entire version of Felt, with its own application instance and a database with sample data loaded in. There are gifs here and there in our pull requests, but none of them are a match for using the product, in production. We’ve  built a technology stack that allows us to add real-time features across the backend and the frontend with a few expressive lines of code. This enabled us to make our product “real time” in places that we didn’t know we could. And as our web app stack matures, we’re now focusing our attention to other parts of our stack where we can build tools that will allow future mapmakers to create maps with a lot more depth and fidelity. 

But don’t get me wrong. None of this technological investment is for technology’s sake. The nice thing with having a clear mission and a vision is that it allows us to judge every single choice against them. We’ve built a stack and more importantly a culture of speedy iteration because that’s the only way we will be able to build what we have in mind. There were many times we’ve eschewed cool technologies, because they did not align with our goals. We do take risks, sure, but we are also ruthless about culling what doesn’t work.

I like to butcher a famous military quote and say, “no prototype survives the first contact with users.” We’ve come so far since Sam and I started this company a few months ago. Every day we open up our product to more people who will certainly stretch its capabilities, providing us with even more complexity to iterate on. But we are prepared with our ideas, and ready to test them out as fast as possible.