5 Steps to an Awesome Executive Summary

Editor’s note: This is a cross post from Massive Damage Inc. written by Ken Seto,  founder of @Massive_Damage & @EndloopMobile.  He is building @PleaseStayCalm, a location based game.. Follow him on Twitter @kenseto where he tweets about Apple, music, games, food, wine & movies. This post was originally published in February 21, 2012 on MassDmg.com.

Massive Damage Inc Header

We’ve finally decided to post our Executive Summary to share with other founders as we’ve always had compliments and great feedback from it.

Some folks wonder how best to use executive summaries.. basically you’ll give it to people who will be doing intros for you. That way, they can forward something that piques the interest of the potential investor without giving away the whole pitch. You don’t want your deck to do your pitch for you, you want to do the pitch.

Here are the following guidelines I followed to create ours:

  1. Keep it to one page if possible, it’s a summary, not a pitch.
  2. If you have no eye for design, hire one or get a designer friend to help out.
  3. If you have metrics, put the good stuff front and center. Feel free to use vanity metrics for big impact but make sure you also have engagement metrics.
  4. Leave enough room for your Team section. Use pictures and previous startups/accomplishments.
  5. Include awesome visuals. Sure you can’t use zombies for every startup but give it some personality. Use bold infographics or charts.

Here’s our Executive Summary:

Editor’s note: This is a cross post from Massive Damage Inc. written by Ken Seto,  founder of @Massive_Damage & @EndloopMobile.  He is building @PleaseStayCalm, a location based game.. Follow him on Twitter @kenseto where he tweets about Apple, music, games, food, wine & movies. This post was originally published in February 21, 2012 on MassDmg.com.

When Does a Startup Stop Being a Startup?

Editor’s note: This is a cross post from Mark Evans Tech written by Mark Evans of ME Consulting. Follow him on Twitter @markevans or MarkEvansTech.com. This post was originally published in January 11, 2012 on MarkEvansTech.com.

Anakin Transformation -  CC-BY-NC Some rights reserved by Tiggywinkle
AttributionNoncommercial Some rights reserved by Tiggywinkle

This may be a question of semantics but here’s a question for you: When does a startup stop being a startup? At what point does a startup become a small company or a plain and simple company?

It’s an interesting question because it’s easy – and probably lazy – to describe less established high-tech companies as startups. As well, the word “startup” is lot sexier and appealing than “small business”.

So how should a startup be defined? Does it have to do with the evolution and life-cycle of its product? Is it the number of employees? Is it linked to revenue? Does it have to do with how long a company has been around? Can a startup have 10s of thousands of customers even if none of them actually pay for a service?

For example, is Freshbooks a startup despite the fact it has been around for several years, it has 80 employees and sales of about $10-million give or take a few million dollars? It’s sometimes called a startup but it’s more accurate to call it a small company.

For the sake of argument, here are some possible criteria for startups:

  1. Less than 20 employees. Once you get more  than this number of employees, a company starts to have “departments”
  2. A product still in development (pre-launch) or in market as a beta for less than six months.
  3. No sales or sales of less than $1-million, which means it’s a mini-business as opposed to a small business.
  4. It’s less than a year old, although there are companies that do go from zero to sixty in less than 364 days.
  5. No customers or only a handful of customers, who may or may not be significant clients dollars-wise.
  6. It has raised more than $5-million in venture capital. With this kind of cash, a company can support having a large team.

For more thoughts, check out this Q&A on Quora, as well as a recent blog post on Business Insider.

Editor’s note: This is a cross post from Mark Evans Tech written by Mark Evans of ME Consulting. Follow him on Twitter @markevans or MarkEvansTech.com. This post was originally published in January 11, 2012 on MarkEvansTech.com.

Under the Hood: The Technical Setup of Upverter

Editor’s note: This is a cross post from the Upverter blog written by Zak Homuth (LinkedIn, @zakhomuth, Github). Follow him on Twitter @zakhomuth. This post was originally published on August 1, 2011, I was just negligent in posting it.

Who doesn’t love tech porn? And what’s better than an inside look at the architecture and tools that power a startup? That’s right, nothing. So we thought, why not put up our own little behind the scenes, and try and share a little bit about how we do what we do?

At Upverter, we’ve built the first ever web-based, the first ever collaborative, and the first ever community and reuse focused EDA tools. This meant re-thinking a lot of assumptions that went into building the existing tools. For example, clients and servers weren’t an afterthought, but instead a core part of our architecture. Collaboration was baked in from the start which also meant a whole new stack – borrowed heavily from guys like Google Wave, and Etherpad.

http://en.wikipedia.org/wiki/Apache_Wave
http://code.google.com/p/etherpad/
http://techblog.gomockingbird.com/archive/5/2010

 

Apache-wave

On the front-end, our pride and joy is what we call the sketch tool. Its more or less where we have spent the bulk of our development time over the last year – a large compiled javascript application that uses long polling to communicate with the API and Design Servers. When we started out to move these tools to the web, we knew that we would be building a big Javascript app. But we didn’t quite know what the app itself would look like and our choice of tech for the app itself has changed quite a bit over time… more on this later!

On the back-end, we run a slew of servers. When it comes to our servers, there was a bit of a grand plan when we started, but in reality they all came about very organically. As we needed to solve new problems and fill voids, we built new servers into the architecture. As it stands right now, we have the following:

  • Front-end web servers, which serve most of our pages and community content;
  • API & Design servers, which do most of the heavy lifting and allow for collaboration;
  • DB servers, which hold the datums; and
  • Background workers, which handle our background processing and batch jobs.

 

 

So let’s talk tech…

  • We use a lot of Linux (ub) (arch), both on our development workstations and all over our servers.
  • We use Python on the server side; but when we started out we did take a serious look at using Node.js () and Javascript. But at the time both Node and javascript just wern’t ready yet… But things have come a tremendously long way, and we might have made a different choice if we were beginning today.
  • We use nginx (http://nginx.org/) for our reverse proxy, load balancing and SSL termination.
  • We use Flask (http://flask.pocoo.org/) (which is a like Sinatra) for our Community and Front-end web servers. We started with Django, but it was just too full blown and we found ourselves rewriting it enough that it made sense to step a rung lower.
  • We use Tornado () for our API and design servers. We chose Tornado because it is amazingly good at serving these type of requests at break neck speed.
  • We built our background workers on Node.js so that we can run copies of the javascript client in the cloud saving us a ton of code duplication.
  • We do our internal communication through ZMQ (www.zeromq.org) on top of Google Protocol Buffers
  • Our external communication is also done through our custom RPC javascript again mapped onto Protocol Buffers. http://code.google.com/apis/protocolbuffers/docs/overview.html/
  • We used MySQL () for both relational and KV data through a set of abstracted custom datastore procedures until very recently, when we switched our KV data over to Kyoto Tycoon ().
  • Our primary client the sketch tool is built in Javascript with the Google Closure Library () and Compiler ().
  • The client communicates with the servers via long polling through custom built RPC functions and server-side protocol buffers.
  • We draw the user interface with HTML5 and canvas (), through a custom drawing library which handles collisions and does damage based redrawing.
  • And we use soy templates for all of our DOM UI dialogs, prompts, pop-ups, etc.
  • We host on EC2 and handle our deployment through puppet master ().
  • Monitoring is done through a collection of OpsView/nagios, PingDom and Collectd.

Our development environment is very much a point of pride for us. We have a spent a lot of time making it possible for us to do some of the things we are trying to do from both the client and server sides and putting together a dev environment that allows our team to work efficiently within our architecture. We value testing, and we are fascists about clean and maintainable code.

  • We use git (obviously).
  • We have a headless Javascript unit test infrastructure built on top of QUnit () and Node.js
  • We have python unit tests built on top of nose ().
  • We run closure linting () and compiling set to the “CODE FACIEST” mode
  • We run a full suite of checks within buildbot () on every push to master
  • We also do code reviews on every push using Rietveld ().
  • We are 4-3-1 VIM vs. Text Edit vs. Text Mate.
  • We are 4-2-2 Linux vs. OSX vs. Windows 7.
  • We are 5-2-1 Android vs. iPhone vs. dumb phone.

If any of this sounds like we are on the right path, you should drop us a line. We are in Toronto, we’re solving very real-world, wicked problems, and we’re always hiring smart developers.

Reference

Editor’s note: This is a cross post from the Upverter blog written by Zak Homuth (LinkedIn, @zakhomuthGithub). Follow him on Twitter @zakhomuth. This post was originally published on August 1, 2011, I was just negligent in posting it.