Please enter your e-mail address: 

Daily e-mail summary is delivered around 4PM EST by FeedBurner.

Why Twilio Wasn’t Affected by Today’s AWS Issues by Evan Cooke

The biggest news story in the Internet startup world last week was the unexpected downtime of Amazon Web Services (AWS) that brought down dozens (if not hundreds) of websites and web applications including Reddit, Quora, and Foursquare. This wasn't the first time AWS experienced an outage though it has been more than 3 years since the last one. No cloud hosting is immune to massive outages and with most Internet software startups opting to use them instead of building in-house infrastructure it is important to show some of the architectural strategies that account for such unfortunate events.

Twilio, a New York startup that connects web applications with phone lines, shares some of their design principles in their freshly-created engineering blog that helped them to remain available during the outage. The main reason is the highly selective use of AWS only when the service offered matches their strict requirements:

  • Unit-of-failure is a single host
  • Short timeouts and quick retries
  • Idempotent service interfaces
  • Small stateless services
  • Relax consistency requirements

The blog post is heavy on engineering terms and concepts so see comments for clarifications if needed.

9 Startup Scaling Secrets from Eventbrite by Wade Roush

Wade Roush, Xconomy's Chief Correspondent, presents a great feature interview with the founders of Eventbrite Kevin and Julia Hartz (husband and wife and 2/3 of the founding team) about their personal experience and the company's history. While the biographical trivia, like Kevin Hartz having two degrees in history, is certainly entertaining, the real value is in the lessons they learned from their successes (surprisingly, no failures are mentioned anywhere in the story). Wade summed everything up in nine points:

  1. Don't take big checks until you absolutely must
  2. Pick the right team
  3. Pick the right trend to follow
  4. Keep it simple
  5. Build on existing tools
  6. Empower your customers
  7. Trust the value of your product
  8. Learn from your customers
  9. Respect the data

In the form of a list, they all sound very bland and generic. The complete article has many awesome examples, like what happened after Eventbrite changed its pricing and how customers discovered a new distribution channel.

The lessons learned are at the end of the story if you want to skip over the biographies and the history.

From Minimally Viable To Maximally Buyable Product by Dharmesh Shah

There is no consensus on what constitutes the first version of a product worthy of a broad exposure to potential customers. Some prefer to test just the concept by producing marketing materials to measure public's interest like Ash Maurya did for his book. Others test a basic solution to the market problem with a "minimal viable product" (MVP), which is well explained in quotes from Paul Graham, Steve Blank, and Eric Ries. Others ship only the fully executeted product because they either are perfectionists or cannot change much once production begins, like it is the case with physical mass-produced goods.

Dharmesh Shah, founder & CTO of HubSpot, offers a middle ground that he calls a "maximally buyable product". Although he says it is the next stage of product development after the MVP, we believe that most of the qualities he outlines affect any product's success in the market.

Bad Copy Kills – Read It Out Loud by Cindy Alvarez

To industry insiders, user experience (UX) and interface (UI) aren't just pretty graphics, nifty visuals, hot colors, and eye movement. The quality of the text presented (the copy) can have great impact on people's behavior as well. Professional copywriters produce amazing engaging personable copy. Unfortunately, not every young company has one on their team or can afford to retain one making the task a typical hit-or-miss gamble.

Cindy Alvarez, the head of product management and customer development a KISSmetrics, suggests an easy way to spot bad copy: read it out loud. She says she does it for every piece of communication she sends to customers and for nearly every interface element in their applications. Cindy's tip might not sound revolutionary or new. Some might have heard about the technique in high school but the amounts of bad copy we encounter suggest few are really using it.

Cindy explains four common copy mistakes that can be weeded out with this quality assurance method: lack of flow, embarrassing buzzwords, lack of context, and being boring. Unfortunately, style issues like jargon might not be uncovered this way.

What is your secret sauce for writing a great copy?