How Shortcuts Turned Writely Into Google Docs

Posted by Neha Palacherla /September 24, 2013 / Hot Topics

This guest post was written by Steve Newman. He is the founder of Scalyr – simple, powerful server monitoring and log analysis SaaS. He is also a co-founder of Writely, which was acquired by Google in 2006. 

Idea to Launch in 100 Days

Back in 2005, a couple of friends and I set ourselves a crazy goal. We had decided to build a web-based word processor, and despite having almost no experience with web development, we wanted to launch in 90 days. In the end, we missed by a couple of weeks. The product was Writely, which was acquired by Google and became Google Docs.

Needless to say, going from zero to Writely in 100 days involved a lot of shortcuts. We did no load testing and no formal QA. The centerpiece of our monitoring strategy was a shell script which loaded the home page once per minute. We had no captchas or spam filtering. We had no scalability plan; in fact, all documents were stored in RAM on a single server, which is about as non-scalable as you can get. How did all that turn out? Let me tell you about shortcuts in the hopes of helping more entrepreneurs.

Evaluating Shortcuts

shortcut (shȯrt-kət; noun): (1) a shorter alternative route. (2) an accelerated way of doing or achieving something.

Startups are all about moving quickly, taking risks, and running lean. In other words: taking shortcuts. But not every shortcut is a good idea. Consider the following statements:

“To save time, I didn’t test on Opera.”

“To save time, I didn’t password-protect the server.”

Depending on the circumstances, one of these might be a good tradeoff. The other, probably not.

A shortcut comes with some drawback or risk, otherwise it would be the normal way of doing things and not a “shortcut”. So how can you tell which shortcuts are worth taking?

Make sure you’ll really save time. As the saying has it: “If you don’t have time to do it right, when will you have time to do it over?” If something is important to your business in the short run, take the time to do it right. Slapdash work is a luxury reserved for people with too much time on their hands. (Corollary: avoid doing just enough of the task to tide things over for a few days. It’s better to get it done completely and put it out of your head.)

Avoid risks that might kill your startup. This sounds obvious, but it’s worth examining. Bugs are survivable. Outages are survivable, up to a point. But if you leak all of your users’ private data because you didn’t take elementary precautions, you might not survive (and you might not deserve to). In a startup, you take lots of risks, but don’t do it willy-nilly. Except when absolutely necessary, limit yourself to survivable risks.

This is why fire insurance is a good idea, but trip insurance usually isn’t. If your house burns down without insurance, you’d have a hard time rebuilding it. That’s not an acceptable risk. But a ruined vacation, while unfortunate, is survivable. Skipping trip insurance and skipping fire insurance are both “shortcuts” that save you money, but the risk is tolerable only for the trip insurance.

Be clear-headed about drawbacks. Some shortcuts involve a tradeoff of quality. If you design your logo yourself rather than hiring a graphic designer, you’ll save money, but the logo probably won’t be as good. How important is that?

If you don’t load-test your site, there might not be any consequences; or it might collapse on your launch day. How likely is that? How much traffic is your launch really going to generate, anyway? (@StartupLJackson: “Good thing we spent 6mo on scalability pre-launch. The thing went hyper-viral day one, just as planned.” – nobody ever.) Learning to judge which risks are important is a critical startup skill.

It’s important to think clearly about tradeoffs. You can discount most drawbacks that only kick in a year or two down the road, because you’ll have changed direction three times by then anyway.

Rules Of Thumb

Here are some specific guidelines that apply to most startups:

Don’t optimize. This is classic advice in software engineering, but it applies to everything. Don’t over-optimize your homepage, you’re going to tear it up next month anyway. Don’t optimize your code, you’ll have rewritten it before you have enough traffic to matter. In general, don’t build things better than necessary for their expected lifetime, which in the early stages of a startup is very short.

(The flip side of this: measure everything, from user retention to code performance. If you have a clear picture of what’s going on, you’ll know when optimization becomes worthwhile.)

Don’t be afraid to do things by hand. When you only have 10 users, you can send the “welcome to [my site]” e-mails by hand. When you only have two servers, you can do software installations by hand. Later, when you grow, it will be time to automate. (See xkcd 1205… and divide all the figures by 5, because this chart assumes five years but nothing you’re doing will last more than a year.)

Don’t scrimp on backups and replicas. You can survive a lot of glitches, but losing all your users’ data is not acceptable. Make regular backups. Run servers in two data centers. Test them regularly.

Don’t ignore security. When you’re first starting out, you probably won’t be the target of a focused attack by a sophisticated team of black hats. But you will, with a certainty, be subject to any number of automated probes looking for basic mistakes like running unpatched software, or not using a firewall. And for kicks, someone might very well go looking for XSS vulnerabilities, SQL injection attacks, and the like. (If you don’t know what this means… make sure someone on your team does.)

Lessons From Writely

So, did any of those mad-dash-to-launch shortcuts come back to haunt us? Scalability was something of a problem; when we first popped on TechCrunch, we had to close down new registrations for a couple of weeks to retool the database. The first time Marc Andreessen tried Writely, an IE bug deleted his document — we hadn’t done enough testing to find this ourselves. But for the most part, things went pretty well.

In part, this was luck, but we also chose our shortcuts carefully. We didn’t do load testing, but we took regular backups, and we maintained a failover server in a second data center. We were careful about security — exposing our users’ private documents would have been devastating. What QA we did was focused on things like the document store, where bugs could lead to data loss. (Even Marc’s document was fine in the end — he was able to retrieve it from the revision history.) In retrospect, we did a pretty good job of avoiding shortcuts we would have regretted.

The tradeoffs are different for different companies. At my current startup, Scalyr, we’re bringing Writely-style simplicity and speed to server monitoring and production analytics. Performance is critical to this application, so we do a lot of load testing. And we’re providing a critical service, so we have much more thorough monitoring. (It doesn’t hurt that we’re able to use our own product to do it.) But we’re still relying on users to let us know if we have any Opera-only bugs.

You’ll have to figure out what shortcuts make sense for you. Be mindful of the choices you’re making, appreciate the time you save, and don’t sweat the occasional fallout.