When I decided to make an app to stream Grateful Dead tapes, I didn't expect it to take years. And it didn't need to, either. But that's how it worked out.

It started when my brother-in-law Josh asked me if it was something I could do. I’ve still got a screenshot of the initial text exchange:

“Potentially not hard:” famous last words

I was wrong in my initial assessment. It was hard—

—to get something resembling the app built. But now that 

, it’s worth thinking about a few of the things that I learned.

Look: I love Josh. He’s a good friend and my brother-in-law. What he’s not is a software designer or developer. This surprised me, though I’m not really sure why it did. I think I’d just wanted it to be another way: that after my day job work of trying to deliver design, which, in organizations not built around the idea of design really means educating everyone about what I’m doing, and why it might matter, I sort of hoped that working on “my project” would be easier. But it wasn’t. Or at least wasn’t easier in the ways I expected. 

Josh did play an integral role here: he’s the Dead subject matter expert. He could imagine the kinds of things he wanted to be possible, even if he wasn’t focused on, say, the specific datasets we had at hand to enable those interactions, he could ask questions about why something couldn't work, and, more than once, in the explaining, I found a solution. I’m grateful for that. But the amount of time I spent explaining the 

 something might not be possible was pretty significant.

I should also give Josh all the important credit for being the face of the project. His “audience building” efforts on Twitter—or, if you prefer, shitposting—built awareness of the project in ways I’d never have been able to.

Some things that happened between the time I decided to start this project and the present:

I got a new job, and moved from Brooklyn to New York’s Southern Tier

I mean, ok, there’s like three years in there, too. But a lot of stuff was going on. Keeping the motivation could be really tough over the long months.

I really wanted to make as much of this by myself as possible. That impulse wasn’t useful. That meant:

I didn’t seek (or accept, when it was sometimes offered) assistance with things

I insisted on making the website(s), and figuring out something approximating a marketing stack including email tools, list management, and more. Of course, by making a lot of this stuff myself, it actually made it harder to involve someone like Josh in the process for some of these things.

Very often, I’d create arbitrary requirements for myself—we can’t release it until X feature is finished, we can’t share it until there’s a new website—that took me away from wherever I’d been previously focusing. The worst part of this was that it often meant jumping from the app’s React Native codebase to some other codebase or way of thinking. Task switching is hard, but when I had the chance to write my own scope, and prevent that task switching, I let the scope balloon.

 product manager here. As it stands, the app has one database for Grateful Dead shows (with a GraphQL endpoint), a headless CMS for some of the content (e.g., the curated lists of tapes, the layout on the home screen). And the aforementioned website? Different stack there, with a different CMS. This could have been significantly easier, and I knew that at the time. But with nobody to say ‘no,’ I went ahead and said yes. 

Many times, I wondered whether the world really needed any of this. Josh often joked about “just doing it, and being legends,” and, ok, that’s probably where my mind was, too. But we’ve never really planned to monetize things—there are some obstacles to doing so, given the app’s reliance on the Grateful Dead archive—so it’s weirdly hard to say whether this was all worth it. Like: when are we done? Do we want to be done? And how would we even know?

To that point about wondering whether people would care—though I knew that shipping sooner, and getting feedback sooner, is the best way to answer that kind of a question (and the kind of thing I've always aimed for in professional contexts), the lack of firm deadlines and constraints let things drag on, and drag on for a long, long time.

As I’ve progressed in my career, the design I’m focused on professionally is often more about people, organizations, and expectations, than it is about the kind of interactions and experiences that I once focused on. It’s really nice to do this kind of work as a hobby, and as a way of staying literate about technology.

What was also satisfying was doing things that maybe didn't seem doable through sheer stubbornness. I mean, the way we've got the queries working? It's really wild. And it might be brittle, too. But I also know 

we achieved a search functionality that isn't exactly out-of-the-box

, even if you're using things like GraphQL. I know if I'd been working for clients, or working with stakeholders within a larger organization, someone would surely made some demands about what we could or couldn't do.

And, finally, receiving feedback from people using the app has been incredibly satisfying. If you're one of those folks who's shared feedback: thank you. Even when the feedback is "this doesn't seem to work," I appreciate it it. If there's any reason I've been able to think of that I've spent time doing this, it's because I wanted to provide some value to people. I'd like to think that if people are willing to take the time to offer feedback, maybe they can see that, too.

"That seems doable," and other mistakes

From the start, we've envisioned search being what Deadsound does best. The Dead's recorded legacy is uniquely well documented, but finding a way in can be tricky. Moreover, so much of the actual recorded legacy relies on tapers. As tapes became digital files, there's still been a bit of that homespun aspect about a lot of the data.

The way one might put this is "all the tapes on Archive.org are user generated content." Many are super high quality, but elements can vary from tape to tape. Song names tend to be entered based on convention, but not always. In practice, that means that where someone might have written out "Beat It On Down the Line" you really want to see "BIODTL," and you 

 want to see other instances of that song. When you're relying on user generated content, that's pretty tricky.

To address this challenge, we decided to base a lot of our experience on a database we controlled, and to help us get to that, we connected with Justin Mason, author of 

. Justin had spent years painstakingly collecting as much known data about the Dead's performances. (Seriously: check out his book.) To assemble his book, he'd created his own Dead SQL database and, when we talked, he graciously agreed to let us use that data for this project. The data served as the basis for our data, and would allow us to serve and query information like setlists, locations, and personnel. Most importantly, it would let us query that based on a data source we knew about and controlled: it meant minimizing unnecessary queries to Archive.org, but it also meant that we could do the kind of setlist-based searching we'd wanted to do.

The search works by hitting "our" database. When you search by a song, year, or person, it's looking at the database of known shows, and figuring out what shows match the criteria you've entered. Once you select a show, that's when the app hits the Archive.org-hosted Grateful Dead Archive to see what actual tapes are available. Everything from then on is user-generated.

For the nerds out there: "our" database is PostgreSQL, accessed via a GraphQL API made with Hasura. We found GraphQL made iterating and playing the search that much easier: there wasn't really any need for us to write SQL, and it was super easy to explore the kind of responses our queries would return.

Is this approach worth it? Does it make sense? Honestly, it's kind of a bet at this point. We think that giving users the ability to combine queries for things like songs in a setlist and specific years will let people find shows and tapes that maybe they haven't heard before, or answer questions just a little bit faster.

To that end, we've (finally) released a public beta. It's out on iOS via TestFlight now. 

Blog

Top 5 Shows By Year

1966

1967

1968

1969

1970

1971

1972

1973

1974

1975

1976

1977

1978

1979

1980

1981

1982

1983

1984

1985

1986

1987

1988

1989

1990

1991

1992

1993

1994

1995