Building a Great App With a Small Team

At Big Cartel, we're always working hard on our iOS app, constantly working to make it easier to use and more powerful than ever. But you may not realize that the iOS team is very small: only two developers, collaborating with a member of our design team as needed. Like many of the artists we love, it's important to us to make a lot with a little.

Working Remotely

Big Cartel has a remote team, which can be an added challenge as we start on projects. Working in the same physical room as your team makes it easier to pick the best times to interrupt other people. Knowing when they're in the middle of another conversation or deep in concentration only requires peripheral vision. Working remotely, tools like chat apps let you see when your team members are online, but not necessarily whether they're free - or, perhaps more importantly, whether they might need you.

The most effective adaptation is to turn all the nonverbal queues into literal communication. Effectively, think out loud in Slack.

The Typical Process

Design work starts in Sketch, but involves Xcode as soon as the initial ideas start to congeal. Collaboration and iteration happens through a daily cycle that starts in Slack and Screenhero, followed by hands-on with the resulting prototypes.

TestFlight is a fantastic tool for our public beta testing program, but it's even better for keeping the feedback loop really tight when working remotely. TestFlight removes the single biggest disadvantage of working on a remote team.

We keep our process and tools deliberately minimal. There are so many tools and thought technologies for building elaborate, sophisticated systems, and we use almost none of them.

Being a really small team makes some things really easy. Take the win and don't overthink it.

Deciding on new features

It's easy to say, "Do one thing, and do it well." In practice, it means saying no on a daily basis, and that responsibility falls to Matt (Big Cartel's co-founder and CEO).

Sometimes we start by talking about what we want to be able to do or how we want things to feel, then work backwards to map a trail between there and here. But it's not always as dreamy or intellectual - we hear what people need by working directly on support requests from shop owners, and that informs our work. Wherever they come from, the ideas that seem to have legs become super rough prototypes that we present during a standing Friday demo session.

There are two things that can be difficult to balance. The first is that it's pretty hard to evaluate new ideas without some amount of experimentation, so the prototypes we make are super rough and the presentation is extremely informal. Building something like Big Cartel, where we're now able to measure progress in decades, taking time to play now pays off big later. So we're not really balancing work and play so much as balancing today with a year or two from now.

The second balancing act is pulling people away from what they're doing today as briefly and predictably as possible in order to get them thinking about what we're doing tomorrow.

Engineering, meet design

When the designers and developers get started, sometimes ideas seem obvious and we get it right on the first try. More often, we leave a cruise ship-sized wake of discarded prototypes. As a perfectionist, that's definitely a luxury that we can only afford because we focus on a limited number of features at any given time. Plus, that focus ensures that our small team isn't spread too thin.

As a developer, you have to enjoy being alone (at least in your own mind), working methodically through a given problem. And I do enjoy that. But, selfishly, I like it when design and implementation overlap as much as possible. "Back and forth" disappears into "doing it together." This is why doing one thing at a time is so important. The time that design and development spends sitting together at the same easel feels like magic when everybody is focused on the same thing.