For the last nine months, I’ve been building a prototype of Level.

The reason is two-fold: I needed an environment in which to play with product ideas swirling around in my head, and I wanted to gain experience with some new technologies.

I’ve long been a proponent of choosing “boring” technologies, especially when starting a new project that already has inherent risk. However, that doesn’t mean you should never learn new languages and frameworks, especially if the new stack appears to fit the problem space better.

Building the prototype was a way for me to gain confidence in my technology choices. Although it is not a perfect implementation of the product, it’s a close enough approximation to get a feel for where pieces of the stack shine and where things get a little hairy.

Continue reading →

Over the past two weeks, I’ve had 21 conversations with people who are fed up with interruptive chat tools.

One sentiment, in particular, has been unanimous: everyone has expressed a willingness and desire to be involved in the process of solving this problem. In that spirit, this post is the first of many where I’ll share details about the process of building Level.

Continue reading →

Do you remember the first time you used Slack at work?

I vividly recall the impact it had on our mostly-distributed startup crew. For the first time ever I felt connected to my remote colleagues as if we were in the same building.

“Now we’re cooking with gas,” I told myself.

Anytime I had to ask my co-founder a question, he was just a quick DM or @-mention away — the digital analog to a tap on the shoulder. This proved to be much faster than firing off an email and waiting for a reply.

I realize this is not news to you now, but five years ago it was pretty ground-breaking.

Slack felt like the much-needed grease in the gears of our budding startup. It brought visibility to conversations that would have otherwise been trapped in an email silo. It lowered the barrier of formality that plagues email correspondence. It increased the velocity of communication.

Simply put, it ended the need to wait.

In the beginning, this seemed like an indelible leap ahead. Fast forward five years, and I’m convinced it has become the single greatest threat to developer productivity in the modern workplace.

Continue reading →

I recently set out to implement user registration for a project I’m working on in Elixir/Phoenix. It wasn’t long before I encountered a challenge that I have stumbled upon with every other ORM library: accepting a collection of form inputs and saving it across multiple (related) records in the database.

There’s more than one way to tackle the problem (with varying degrees of elegance), but I discovered that Ecto lends itself particularly well to solving this problem once you are familiar with tools available.

Continue reading →

Since August 2016, I’ve had the pleasure of being a regular guest co-host on Giant Robots Smashing into Other Giant Robots along with Ben Orenstein. I’ve been a long-time podcast consumer, but was initially reluctant to try my hand at recording myself. After some healthy prodding from Ben, I agreed to try a few episodes and, lo and behold, we’ve been recording ever since.

A few weeks ago, Ben dropped the news to me that he was moving on from Thoughtbot to start his own business. This left us an interesting new storyline to tell and no podcast on which to tell it!

So in true scrappy bootstrapper form, The Art of Product podcast was born. We plan to release one ~30 minute episode per week and continue with the same format from Giant Robots, discussing whatever interesting things we’ve been up to recently.

Have a listen and leave us a 5-star review in iTunes if you dig it!

One of the core features of Drip is the ability to segment your subscriber database by tags, custom fields, events performed, campaign and workflow subscriptions, and so on.

As our Postgres dataset has grown into the multi-terabyte size range, these ad-hoc segmentation queries have become increasingly expensive to run, especially for accounts with many thousands of subscribers and millions of subscriber events.

Continue reading →

Back when we started Drip in 2012, it was customary to write your own recurring billing engine.

Fundamentally, a SaaS billing engine is simply a scheduled task that runs each month for each customer and hits a payment API to charge them. Layered on top that is the concept of pricing tiers, trial periods, failed charge retry, proration, annual plans, and invoice generation.

Most developers these days choose not to build their own billing engine, as free platforms like Stripe subscriptions promise to rid your application code of complex billing logic. It seems like a no-brainer, right?

Continue reading →

Nothing quite compares to greenfield software development. The canvas is blank and you finally have the opportunity to do it “The Right Way” from the ground up. If you’ve been building web apps for a while, you’ve undoubtedly found yourself working with technologies that you’d never use again, given the luxury of a blank canvas. And if you follow the open source world, there’s probably a brand-spanking-new boutique framework you’ve been itching to take for a spin.

With all the excitement of a blank canvas comes an equal amount of anxiety. You know you are one ill-advised choice away from being stuck with the “imperfect” tech stack. You have a hunch about what you want to use, but being the dutiful engineer that you are, you spend a few hours verifying your assumptions by Googling “Ruby vs Go” and “nodejs vs haskell” only to find yourself with net loss of clarity. (Don’t do that.)

Take a deep breath, it doesn’t have to be this hard.

Continue reading →