Draft: A Developer's Approach To Building A Writing Collaboration Service For Writers
Yonas Beshawred
After years of battling with Google Docs, messy email threads with inline comments, and Word Documents with track changes to gather feedback on his writing, Nathan Kontny was fed up. So he did what any developer would do: he built a better tool for himself. Bit by bit, he started chipping away at all the small annoyances he experienced as a writer. He iterated quickly after getting feedback from friends and made his tool available to writers everywhere. Today, Draft has a ton of features, and is quickly becoming a favorite amongst writers and bloggers at young startups that just want a tool that works. We sat down with Nate to talk about how the idea for Draft first came about and how he went about building it. He gives a ton of advice on which gems and tools to use and tips for how to get the most value from some of the most popular dev services out there.
Highlights
Tips for Heroku & helpful Add-Ons, New Relic, Clicky the Google Analytics alternative, and more.
"I focused on, what can I deploy in just a couple days, so I can just start using it immediately for my own blogging purposes...I force myself to do this. I don't think enough people do. I think a lot of people have a vision of what this product is going to look like in two years, and they can't possibly imagine getting something out the door into someone else's hands in just a few hours."
"When we’re building software, there’s so many people that are just jumping on the next framework, or programming paradigm. You know, it’s Java, it’s Ruby, then it’s JavaScript. Then instead of Ruby on Rails you’re using Node, and now you’re using Meteor. All of these are really great tools. I’m not disparaging any of them. But you’ve got to learn how to commit to one of these things and really get good at one thing, and not just keep jumping into the next new hotness."
> "I open source stuff constantly...I keep pushing out stuff that's been very helpful for me"
- cohort\_me
- multi\_fetch\_fragments
- tracer\_bullets
Y: Let's talk about how the idea for Draft first came about, and how it was born.
N: After doing two startups through Y Combinator, Inklingmarkets.com and Cityposh, I took a break and worked on the Obama campaign for six months. Then when I was done with the campaign I was looking for the next thing. I noticed I was blogging so much. I've always loved writing, and I had stopped it, regrettably, for a while. Then the last couple years I've just been committed to it, at least getting a blog post done a week, often more. Just through that writing experience, kind of paying attention to all the pains I had as a writer, just doing multiple versions of my stuff; sending drafts to my wife to get her feedback, publishing in different places. Often I'll try to write a blog post, I'll publish to my blog but then I'll send something to Tumblr, and Twitter, and my mailing list, to let people know of it. There was just so many different things that were a pain to do. I just worked on trying to shave off a bunch of those steps of the writing and publishing process, and that became Draft. So that's what I've been working on ever since.
Y: Would you talk a little bit more about the pain points you had experienced? What were you using? Were you just using Google Docs, and then Wordpress, and email?
N: I'm just very experimental, so I've tried a lot of stuff. I've tried a lot of distraction-free editors. There's a lot of distraction-free desktop apps that are in decent shape these days. Some of them need Markdown. I like writing in Markdown, I've discovered. Markdown is a very simple way of formatting your text, and it easily converts over into HTML. It's a very simple way of bolding things, italicizing things, adding URLs, without having to know HTML, which is even more complicated because you have to remember things like closing tags.
So I was using these different distraction-free editors. I tried Google Docs, and there's too much stuff going on. I wanted something that was simple. Then I would end up just using a native text area on my blog, because it wasn't a bad writing experience, it's just when I wanted to do things like version control... if I wanted to save multiple versions of my blog post, I'd end up copying and pasting them into Evernote notes over and over again. I would create one Evernote for one document, for one blog post, and every time I thought this was a major version that I wanted to remember, I would dump it into an Evernote so I could track if there were major paragraphs I wanted. I would always have this copy. It's a terrible way to work. Graduating to something like git is way too heavy. I don't want to have to worry about committing things, pushing things, branches to remote servers. And then I would send a document. I would paste it into an email to my wife, and she would copy and paste into Word, do things like track changes, and send me the Word document back. That was also really painful. I didn't want to use Word to get her edits out of a document just for my blog post. So it's just using all of those types of tools that I decided, I'll just make something myself and see how it goes.
There's also the problem of publishing. Like I said, whenever I have a new blog post, I end up publishing to so many different places, like MailChimp, Tumblr, Twitter, and LinkedIn, just to let people know of a new post of mine. I focus a lot on Draft creating hooks into all sorts of other places that you can send a really quick note to your MailChimp mailing list from within Draft too, just to save you yet logging into another tool, and typing in a lot of fields. I'm trying to trim down all those steps you need to take to publish to all these other platforms. So publishing's a big thing.
Other things too; I want to help people become better writers. I think a lot of these tools focus on just the technology. People do appreciate a clean writing environment, people appreciate saving steps, but people want to, I think, even this more so, there's this core desire and need to become a better writer. You can give me all the tools you want but it's not going to necessarily help me get more traffic to my blog or more people paying attention. It's not going to make my blog post any more interesting.
I've been focusing a lot on just trying to help people to understand how to write better. I've done that through things like analytics. You can scan an RSS feed into Draft and it will tell you things like what are your most popular blog posts? Do people like it when you write shorter or longer? Do people like it when you use things, even, like profanity, in your blog posts? It will tell you what time of day your publishing is even your most popular. Because all of these things, I don't think people pay enough attention to. They make a big impact on creating an audience, and gathering more followers around you.
The other thing too is, I added a way to get a copy editor. I think all of us need more people looking at our writing, but we don't always have it, right? Our friends are busy, our significant others, they only have, maybe, five minutes to look at something. So I wanted a cheap way, for $5.00 bucks you can send this to the professionals to look over quickly and give you some insight into making your writing better.
Draft also gives you day and time of day analysis. So it will show you your most popular days... like for me, I've realized that Monday and Tuesday are my most popular blog publishing days. Fridays kind of suck. Wednesdays, surprisingly, kind of suck too, and that's not something that I would have realized, that apparently my readers are doing other things on Wednesdays. So now I can target things better and get more traffic. Now I know more optimal times I should publish. So yeah, it's definitely been very helpful for me to learn more about my audience in that way.
Y: And you're iterating pretty quickly, pushing out features regularly. So let's talk a bit about your build process, and even the technology you're using, starting with the initial version.
N: I'm a big believer in using tools that I know really well. I like to tell people when I talk about my tools, my father was a handyman, a contractor. He built homes and did a lot. He ran his own little construction company for a while. So one of the things growing up that you notice if you're ever around fathers like that, or handy people, it's like your tools are always so old. My dad has the same hammers and the same screwdrivers and chisels for so many years. The things are decades old. Granted, every now and then he'd buy a new saw, but he'd use the same tools constantly and was so efficient at getting stuff built because he wasn't having to learn this new paradigm of building a fence or a house.
I think we do that too often, right? When we're building software, there's so many people that are just jumping on the next framework, or programming paradigm. You know, it's Java, it's Ruby, then it's JavaScript. Then instead of Ruby on Rails you're using Node, and now you're using Meteor. All of these are really great tools. I'm not disparaging any of them. But you've got to learn how to commit to one of these things and really get good at one thing, and not just keep jumping into the next new hotness.
For me, I committed to using Ruby, and Ruby on Rails. The thing that attracted me, and there's been a lot of other things that have come along. I started using Rails before it was even officially released. I used it when it was at 0.11. That's when I first started using it. Very few people were aware of it back then. I think I gravitated towards it just because I knew it came from a cool company called 37 Signals. They were doing cool stuff in Chicago. So I saw what they were doing. I really saw how that's a great kind of goal there, to be more like them. I just committed to it. I committed a ton of time to learning Ruby and Ruby on Rails, and I've been making apps now with it for eight and a half years, something like that.
With Draft, yeah, there's so much cool technology out there. I definitely think, "hey should I build this in Meteor, and serve it with Node or something, or use a new JavaScript framework like Backbone or Angular." And I don't. I keep going back to, I'm going to keep with the core tools I know and understand, which is Ruby on Rails. I'm very good at hosting things on Heroku. I go back to all those tools.
The first version isn't all that different from what is being run today. Like you said, I iterate constantly. The core framework and the back end, a lot of it, and the stuff I've been using for so many years, it's been a huge help to get Draft up really fast, and just to keep iterating it pretty quickly.
I started learning to program on Java. Well, way back when, I learned programming with Fortran. Really quickly Java was going to be in the professional world and the corporate world when I was working at Accenture. Then I saw Ruby come around, and that was something it seemed like I wanted to commit a long time to. It didn't seem like it was a fad, and I thought I could just do a lot of stuff with it.
Y: So let's talk about your build process and some of the features you wanted in there at first. What was your approach?
N: I'm allergic to long projects. I can't stand working on things that take a long time. Most things that I try and work on, in everything since I was working on Inkling, and see if I can get it done in just a couple hours. If it's something I'm going to have to keep waking up to and staring at, I'm going to get bored. I'm going to lose the motivation and the inspiration to get it done.
If there's any project I want to do, I try to figure out obviously the minimal, shortest thing possible. With Draft it was the same way. I pretty much had a writing environment ready in a day. I focused on, what can I deploy in just a couple days, so I can just start using it immediately for my own blogging purposes. I wasn't pulling all these crazy all-nighters to get this stuff done. I just focused on really tiny problems, like, how can I create really simple, distraction-free expanding text area that auto-syncs. That was challenge number one. That would be solved in a day.
Then the next day it was, well, how can I save major versions of my work? I want to mark major drafts of a certain document. That was ready in another day. There it was. Now I have a writing tool that I can use in my blog and I can get rid of Evernote. It was ready in just a couple days. I force myself to do this. I don't think enough people do. I think a lot of people, if they want to do a new software project, they envision this crazy thing that needs to be done, right? They have a vision of what this product is going to look like in two years, and they can't possibly imagine getting something out the door into someone else's hands in just a few hours.
Y: Yeah, that makes sense. So for the initial writing environment, what were you using aside from Rails?
N: It was mostly just vanilla Rails and custom JavaScript I've written that does all the syncing of data. It's just a very JavaScript and Ruby heavy application. Doing the auto-staging, listening for keyboard shortcuts to save things ... it's really not all that fancy. I used MySQL in my development environment to Postgres in production.
I do use a lot of third party stuff in other projects. One of the neat ones that I use is something called Ink Filepicker. That's been a very helpful tool for help me. I use it all over the place. It's a utility that people can use to import documents into Draft, to export stuff from Draft to other places like Dropbox and Evernote. It's also the tool people can use to have an easy image hosting service with Draft. You can quickly import the image from Dropbox to your computer and Draft will post it for you, and it all, again, goes to Ink.
Y: Very cool. Quick question: why did you want to use MySQL in your local environment and then Postgres in prod? I do the same thing but probably for a very different reason.
N: It's probably not great. I mean, I've kind of grown up, again, on MySQL. I've been using MySQL for so many years. Inkling was based on MySQL. I feel like MySQL's just such an easy tool to use in the developing environment. One of the big ones, too, is even the things that are built on top of MySQL. There's a lot of good MySQL admin tools. I use something these days called Sequel Pro, and I believe it's open source. It's awesome, I'm just handy with it.
It isn't ideal, right? I've got this stupid code in Draft right now that, and if I had to do this often, I would switch to using just Postgres all the time, but there's a place in Draft right now that has queries that are different for Postgres and MySQL. I use this one query to see what it's going to look like in development, but then obviously I need a different query for prod. It's just because it's doing some fancy date arithmetic using custom date functions in the database. It's kind of stupid, right? I would never recommend anybody do that. But it's a one-off situation. I do use Postgres in development too. Obviously if I'm seeing a performance problem, or any kind of problems with queries, I'll usually go to Postgres and make sure it's not a problem with the database itself. I mean, it's not really a great reason why I chose MySQL, but it's just that I'm handier with Postgres in development.
Y: Cool so were there any other things in there that were really useful for you in just getting something out?
N: No. I mean, like I said, I had something deployed even before Ink. The basic kernel deployed was just a simple writing environment. It was a basic CRUD app. The only cool part of that original two-day version was, it would auto-save and I could mark the major versions. That was it.
The second big thing I think I built the next week was merging in changes from my wife. Every time I hit a problem that I don't want to deal with some other tool, it becomes another item on my to-do list to get rid of. I was sick of dealing with my wife's merge documents so the next thing I focused on was merging in her changes. That's how I want to make products. I think a lot of people focus on, what do other people need? That's a fine way of looking at things, and I'm definitely attuned to how my customers are using Draft in ways that I'm not, and I'm trying to make them happy. I will make things that don't come from my use case. But I really want to make products because they solve my problems.
It's for all sorts of reasons. One, it makes my life easier, but two, it makes me make a better product. I built things for other products, other projects, and if I don't use those features, they're the first ones that go broken, and they're the first ones that look ugly, or people don't even use them and I don't pay attention to them just because I'm not touching them myself. It occurred to me to use my own products. Just as a writer I come up against this pain point where I'm sick of using some other tool. It becomes another thing on the to-do list to tackle in Draft.
Y: So fast forwarding to today and where the product is today, is your build process similar in terms of the things you prioritize?
N: It's a weird balance. I don't have a really strong formula about it. Security is the most important thing, right? If everything falls by the wayside, for me to make sure things are secure. That is the number one thing that is on my mind at all times. Also, speed is important to me. I treat speed as a feature and I'm constantly trying to make sure I can make things faster. Then after that I'm basically juggling between both; what do customers need and what do I need.
When I'm getting things done, I'm not switching between a lot of different projects. It's usually just three things at the top of my list. If I get something done, or if I have to wait for a follow-up, then I move on to do the next one of those three things. I think that's also been very helpful. I'm very laser-focused on the things that I need to get done. Organizing my list just helps a lot.
Y: Awesome. So taking a step back from a technical perspective, is it just you right now, or do you have other people that are also contributing code and working with you?
N: Just me.
Y: Okay. So you don't have to coordinate much. In terms of your actual build process, you're just pushing up to Heroku. Do you have any automated testing, or continuous integration that you have in there, or are you just pushing straight to prod?
N: No, I'm a big believer in creating automated tests. Every deploy I launch goes through a test which I've created. Actually, a friend of mine, a guy by the name of Zach Gilbert, he and his buddy have a little company. I wish I could plug it better. They're just beta testing this right now, and I'm using them, and they're doing some good stuff. They basically are running some extra tests on top of my stuff. I'll get an email from them if something in the app is really broken that I haven't caught. In prod. They're running through the script in prod just to make sure everything's okay. It's more of a UI testing. It's some stuff they built. I think they're using Selenium a little bit. No, they'll actually go through my application slow with some test users in production to make sure everything's okay in production from a user's perspective.
Also, there's a tool that's an add-on to Heroku called Tinfoil Security. They'll do some automated penetration type things. They'll do some automated checks, if you've got cross-site scripting bugs and stuff like that. But that's also running in the background.
I use AirBrake for exception monitoring. And New Relic. New Relic is also pretty useful for monitoring exceptions, and trends in exceptions. Kind of a combination of both. New Relic has been really useful to me. I've been using New Relic since they launched years ago. We used that like crazy on the Obama campaign for performance troubleshooting. I use that constantly with Draft. The big pic there is, New Relic can get pretty expensive. So what I'll do with it, I'll turn it to the premium when there's a specific type of issue that I know that's occurring and I want to start going deeper into. But Heroku makes it really easy to switch between the premium and the non-premium New Relic. I don't have to leave it on for a long time and pay the prices. I can just turn it on, pay the extra fees, and then when I get the things fixed up, I bring it back down to their free basic plan, which still is very valuable.
Y: Oh, cool. So kind of like manually scaling.
N: Yeah. I mean, it's just me toggling. It's so much easier to toggle the switch than to turn the thing on and off. That's what I do. Other things that are helpful too ... there's a great article online that talks about getting the most out of your free Heroku. It's a very applicable paper for a lot of people, using things like New Relic uptime monitoring, to make sure your Heroku dyno is always loaded. When you're starting out, there's no traffic. Heroku will unload your dynos, right, which in a dyno is just a server basically in your load balancer. So Heroku will turn it off, and so the next visit from a user, will have to spin up a whole new instance for that first experience. If you're a new startup, you've got these first users that will have this terrible, terrible, slow, first experience with your product. You can use New Relic to ping your app to keep it alive.
Also, I use Amazon's CDN, CloudFront. I think a lot of people should be using that. It saves half the traffic to Heroku on Draft. If I wasn't using that, all the requests, all those javascript assets, file assets, would just hit Heroku. Instead now it hits the great Amazon content delivery method, which is huge, and cheap. I'm a huge believer in it. It doesn't take that long to set up. It took me five minutes, ten minutes. It saves quite a bit of traffic in Heroku just using Amazon's CDN.
There's a tool called Blitz. It's a Heroku add-on, that does a lot of stuff with ... you can hit your app with tons of traffic and see how well it performs. That's really helpful. I use that right away. When I was launching Draft and knew I was going to be on TechCrunch, when TechCrunch announced Draft. I wanted to be prepared. I used Blitz like crazy when I was launching to make sure that Draft was going to handle all the traffic.
Other cool tools, are like Clicky analytics. Google Analytics is fine, but Clicky is just something that I think is more niftier, and, I don't know, it's a little bit more user-friendly. Google Analytics always confuses me. I feel like it's always changing. I like using Clicky. Just real time tracking what people are doing on my site. In real time I see links coming. I can tell from the articles that have written about me, or something shows up in the recent new links, sending referrals to my site. I use it to keep track of web traffic, where it's coming from, what people are doing on the site.
I also open source stuff constantly. I created my own cohort analysis for Rails apps, it's called cohort_me. There's great tools out there, like MixPanel, and KISSmetrics. Both of those tools, I think, people should be looking at and using. There's just a lot of greatanalyticaltools. I also believe you should be gathering a lot of this data yourself, too. If you ever want to switch analytics tools, you're going to kick yourself if you haven't been gathering this data on your own.
Also, I felt with Cohort analysis, there's so much data already in our database, I didn't want to have to use someone else's tool or database to start screwing with this stuff. So I created a whole cohort chart that you can link at your own database to see how people are using your application over time. That was handy in the beginning. As I was developing the features, just to see if people are sticking with the application and the feature I was using.
Y: Very cool. Let's talk about some of the open source stuff that you've used and/or have built. You mentioned the Cohort tool. Anything else?
N: Sure. If you want, my GitHub repo has all these projects. I keep pushing out stuff that's been very helpful for me. Like cohort_me was very helpful. Something that I learned, a technique that I learned more on the Obama campaign, with stretching things in parallel to memcache. It's a technique that people don't really realize. Like most people cacheing with Rails use something like MemCache, right? There's a cache server with a lot of memory that's really fast. But there's a feature in Memcache that kind of goes unnoticed. You can fetch things from MemCache in parallel. So if you're fetching a bunch of fragments all at the same time, you don't have to fetch them sequentially, right? If your MemCache is bad, most likely your MemCache server is a different server than your application server, right? You're going to be making network call after network call. If you have a big table, most people are fragment cacheing each row of that table. You have a row of 30 things, which isn't all that unusual, like 30 customers or something like that in a table, you're going to fetch your memcache 30 times. That's 30 network calls that you don't need. So there's something in my repo called multi_fetch_fragments, that basically will help you fetch all of those fragments in one network call. Instead of going to Memcache 30 times, you can go to multi_fetch_fragments one time and fetch all those individual fragments for those 30 customers.
So if you're doing any fragment cacheing, and you have a lot of rows in a table, or you're just displaying a lot of fragments on one page, this thing is going to save you a ton of time in network traffic.
Y: That's awesome.
N: Yeah. I feel like it's almost something that should be baked into Rails right away. It's like rendering partial image collection, and we're doing fragment caching, but if you put those two things together, it's not very efficient. That's my most popular repository that people are using.
There are some other things. Tracer bullets, which is just an easy way to ... you basically just stick the word "tracer_bullets" in your code, and if you look at your development log file, you'll see how much time has elapsed to get to that point. New Relic's awesome but it's this extra step to see where your apps flow. That's been a helpful tool for me to do performance improvement with Draft. So if you look between them and you see, "Oh, man, a lot of time has passed since the last time..." now you've narrowed it down to where your slow part of your application is, right. There's so many areas where your app could be slow; is it the controllers, the giant views. You have no idea where in the view is the bottleneck. By putting just a few of these in, it helps narrow it down a lot faster.
I do a lot of A/B testing. I made a little A/B testing tool that's really helpful. So, yeah, all the open source stuff is in Draft. I use that stuff like crazy.
Draft needs to make money, so I need to charge customers. We're using gems like Stripe. So those are the obvious ones. I've got things in there, like, I connect to MailChimp. Because I've got all these gems in there to connect to all these extra services, like MailChimp, and Tumblr, and LinkedIn. Griddler is kind of an interesting one, from Thoughtbot. They've created something called griddler, that makes repeating emails hooks. So, they basically make receiving email posts super easy. I use that in combination with Mailgun. Mailgun can create a receive hook, so that whenever it receives email it can post somewhere, right. Right now, Draft has team folders, where you can share a whole folder with a team of people. There's even a group discussion that's inside. So I wanted to make it so that you can apply those emails, just email clients, and what team is going to get the replies. So a combination of Mailgun is receiving these emails; they call back, you need to do something with that email. They'll call my application. Griddler makes it really easy to deal with getting callbacks. Griddler basically creates this framework you can use to deal with any incoming email hooks. That's a useful tool that I just started using and just realized a week ago that's what they created.
There's also a tool that's called Gritter, it's like Growl Alerts for JavaScript. And you can put them in different corners, make it sticky, queue em up, change the designs really easily. I use that. I use quite a bit of Gritter in Draft. There's a Gritter gem that makes it really easy to use too. So if someone exports a document in Draft, it might take a while, right? If they've got a lot of images and stuff like that, it will process all those images. If they want to say, export it to Microsoft Word or something. I'll pop up a little Gritter message, like a Growl message, just to let them know, "Hey, it's processing, I'll send you an email when it's ready." I use it for most of the customer-facing messaging.
