Expensify: What's in your stack?

In this new series of posts, I ask developers what’s in your stack: what development process, frameworks, tools, and other “stuff” do you use to create, get your software out the door and running? How do you go about doing development?

In the first edition of What’s In Your Stack?, I ask Expensify’s CEO David Barrett about the processes, project, and product management practices they use to get their SaaS-based expense filing application coded up and in user’s hands.

You may remember David from make all #008 from awhile back where we discussed their business and stack in depth. They’ve also launched a new feature today that, as an expensify.com user, I’m looking forward to: receipt scanning.

Delivering over the cloud

What’s interesting about Expensify in the context of stack dissecting is that they’re a SaaS company with web and mobile clients. I’ve been interested in how “cloud developers” run their development process where you have both access to real-time user data (all the “one-way mirror” user studies you’d want) and also the ability to deliver at any time (whether that’s a good idea or not). So while I also asked David about the technical under-pinnings of Expensify, I wanted to narrow this What’s In Your Stack down to “process,” which a boring word for “how do you get software out the door and make sure users like it and are productive with the software?”

First, describe company, the business that the stack is supporting

David: Expensify does “expense reports that don’t suck!” by importing expenses and receipts from credit cards and mobile phones, submitting them through email, and reimbursing online with QuickBooks and direct deposit.

How would you describe your development process?

David: Everything starts with getting the right people — excellent people can make any process work, but no process will save you from bad or even mediocre people. Pick some external event that suits the rough topic and scheduling goals, and set that as the immovable deadline of your milestone. Document the absolute minimum you need for that launch to be a huge success, emphasizing the critical usability and functionality decision points and intentionally ignoring implementation details. Split everything up between whichever of said excellent people is most interested and available. Create real-world test scripts and sample data sets, begin testing as early as you possibly can — with increasingly large beta groups — and continue testing right up to launch. Repeat 3-4 times a year. Do quarterly 360’s to force everyone to level with their peers in a constructive way. Track hours to ensure everyone is putting in a solid 50 productive hours per week, and encourage everybody to take ample vacations. Celebrate often, for items big and small.

Requirements management: How you build innovation and discovering
new features into the process?

David: Ultimately startups have no choice but to go with their instincts on what to build. It sounds good to talk with and poll users — and you certainly should. But realistically whatever data you get back will lack statistical relevance: do you have enough users? are you asking them unbiased questions in a uniform way? are the current users the ones you really want in the long run? At the end of the day, just spend a tremendous amount of time talking with real users to learn what they want to the degree they even know. And when in doubt, do whatever you would personally want. Because then if all else fails, you at least have one user who likes the product: yourself. Better that than no users.