Developing OpenCanvass, Reflection 1: A million tiny decisions

At Everyday Canvassing, we had dreamed of custom software for a really long time. As is, the software environment for door-to-door canvassing and analysis is… limited. Every part, from calculating doors to be knocked to selecting locations to building surveys and managing data, was completed in its own system. Exports to edits to imports to exports to edits and on and on.

I think a lot of teams and individuals have found themselves in a similar position, with a lot of insight into what a process should look like and not enough time or technical expertise to build tools that make it so. And then AI got very good very fast, and suddenly we had to ask ourselves, what does it really take to make something helpful? And so, OpenCanvass was born, Everyday Canvassing’s purpose-built, end-to-end canvassing platform.

This post is the first formal reflection on that development process and what it’s like to find ourselves with a need for software and the sudden, unexpected ability to produce it. One of the biggest early takeaways is that building big things means making a million tiny decisions, and building something well means learning the mechanics of each of those million tradeoffs (or at least as much as possible, for as many as possible).

When AI builds something quickly, it’s because AI is making those decisions for us, including decisions we didn’t know had to be made. For a lot of decisions that need making in software, like how to draft the CSS for a particular visual element, AI deciding them is generally a massive help. The purpose of OpenCanvass is to help people support their communities by talking to residents at their doors, which we do by making that process as streamlined and easy to manage as possible. If delegating to AI can help us get to that goal faster, wonderful.

But the problem is that trying to achieve that goal using AI means A) having AI push past our own expertise and make decisions for us before we understand the relevant tradeoffs and B) creating a knowledge debt which, unless and until AI makes those decisions well by default, we are obligated to pay.

For example, this last week I had to build an export wizard to help users manage getting data from the system into transcription cleaning (a feature we’re still building out). It’s a pleasantly simple task, for the most part. We just need a way for people who are exporting data to select the columns they’ll be exporting. Easy-peasy.

Except then, starting as a trickle and expanding into a miring slog, the million decisions come. Should it be an overlay or a side-panel? Step-by-step, or all in one screen? Inline guidance, tooltips, or explanation elsewhere? We want to include presets, and have the user build their own, but how much should we show about which fields each preset selects when there are a lot of fields to choose from? How do we make the preset selector robust to many presets, but not overwhelming, hard to navigate, or a distraction from the rest of the options the user has to choose?

Of course, you can always ask AI to build it, and see what happens. One of the most delightful/terrifying parts of this moment in technological history is that every few months, you can ask AI to complete the same task and get dramatically improved results, design included.

But as we have repeatedly learned during OpenCanvass development, a better AI baseline does not mean adequate output. For the export wizard, it initially chose an awkward side-panel, unclear typography that flattened all visual hierarchy, and long inline explanations that drew the eye and reduced visual clarity.

In that case, AI made a lot of small decisions, but the visual consequences were clear and intuitively counterproductive enough that I could recognize and adjust them. The much scarier, and perhaps even larger, category of AI-made decisions comes on the back-end, about how the tool and data systems operate. These are the ones that, for us, have required the most time and mental energy to make or verify.

As it turns out, mobile caching and offline-first data storage are a world of complicated data architecting, even for people who got into it on purpose. As with everything, building the system back-end means a million choices about each portion, some extremely consequential, but many also much harder to evaluate or define alternatives for without significant foundational training.

There’s a Paul Graham quote about how “If you want to start a software startup, you should still learn to program.” At some point, like an amateur artist learning anatomy so they can draw a portrait accurately, there’s no way to build well without learning how the code and technical underpinnings of a system work.

AI has let us make rapid progress on OpenCanvass in ways that have already changed how Everyday Canvassing canvasses, but that progress comes at the cost of perpetual learning. There are many, many decisions to make that we’ll need deeper, more technical expertise to make well. AI gets us to the point of needing that knowledge faster, but it certainly hasn’t meant we don’t need it at all, and, at least to build truly exceptional things, there’s a chance it never will.