I get asked a lot: Why am I here? Why Startups? Here is why.

Large corporations are built to withstand a few broken cogs in the machine.  Unfortunately, by design, this requires that nearby cogs should overlap and that no cog can be responsible for too many functions (otherwise becoming a single point of failure). For an ambitious and hungry cog, this system is both a safety net and a glass ceiling.

By contrast, Startups, by necessity, have much fewer resources.  They require cogs to have minimal overlap and that individual cogs must be responsible for too many functions (otherwise it won't get done).  For an ambitious and hungry cog, this system is risky but boundless.

No resources, no funding, no large workforce - these constraints force agility, foster creativity, and forge mastery.  Often, a matter of days can mean life or death for the company*.  Startups, on a budget, have to find creative ways of obtaining users and keeping them**.  And, in a consumer web application startup, an average number of users supported per engineer over 500,000 is not unusual***.  

I love Startups. Do you?

* In The Paypal Wars, Peter Thiel's ability to make deals fall into place quickly (for funding in a down economy) was key to their early survival.

** Prerna Gupta, CEO of Khu.sh, uses JUST YouTube to get traffic towards her app. The best part? Less than a year in, they're profitable.  [source]

*** Reddit's number is at least 1,000,000,000. Yep, that's a billion users per engineer. [source]

As the technical half of my company, it is all too often incorrectly assumed that I am the CTO. 

According to Eric Ries, the CTO's primary job is to ensure the company's business goals are met by the technology strategy. This involves choosing the right platform(s) to build on top of, fully understanding all tradeoffs involved, and ultimately deciding where to focus R&D efforts based on what's best for the company. Spoondate's current full JavaScript stack has been validated by past projects created by me over the last two years as well as by a number of proven, scalable projects from NodeKnockout. The entire system has been designed from the beginning to eventually require no human intervention to operate* - minimal R&D is required if at all. The CTO job for Spoondate is essentially reduced to evangelism - a task where someone more outgoing would be more apt.

The COO's primary role is to collect, dissect, and condense data from the company for the CEO - who ultimately makes decisions from said data.  Trust is a huge factor in this relationship - a malicious COO can distort the data, undermine the CEO, and try to replace the CEO. Raissa, Spoondate's CEO, and I have established a relationship of history of trust and aligned goals. Furthermore, I have a proven track record of providing Raissa with extremely valuable, unbiased data about pretty much everything.  I'm never going threaten her position as CEO (unlike an incoming executive hire).

My background is further advantageous to this position.  As an engineer, my technical skills are invaluable in a business world - I can build my own tools to automate or accelerate almost any aspect of my job.  Personality-wise, I am happiest in roles that don't require lavish attention - when my job is executed correctly, no one should notice a thing. This complements the position well. On the flip side, mistakes inevitably happen and I can resolve them and prevent regressions without overhead or oversight.  

As COO, by design, I have a significantly better capital efficiency - I accomplish more for the same budget.  I have the ideal (and hard to find) COO-to-CEO relationship.  

- Van, COO, Spoondate.com

* Our codebase supports i18n, feature flags, split testing, continuous deployment, real-time monitoring & analytics, zero-downtime deployments, page speed best practices, (eventually automatic) progressive enhancement, web app security best practices, dynamic asset packaging, and many other production-ready (read unit-tested) features. In the future, we might only need 1 full-time engineer to add new features (or maybe 0!**).

** It is possible! Just means that a non-technical person would be able to add features without code.

***For me, often, zero feedback is a pat-on-the-back.  That means no fires to put out.  

This post was made in response to the AppSumo lean challenge. 

 At Spoondate, we've been taught and advised from day 0 to be Lean.  We started at Women 2.0 FounderLabs where speakers like Eric Ries and Steve Blank preach about concepts like Customer Development and Lean Startup methodology - we listened.  HARD.

Almost every day, we test features, ideas, or copy in front of at least one random human being (other than us).  Our iteration cycles range from 3 minutes to 3 days. We use the Think-Make-Check cycle - come up with a hypothesis, build a prototype to test, then test and use it to refine a new hypothesis.  

This process has been carried over to every stage of our development thus far - from testing the acceptance of the core concept and branding (ex: logo, catchphrases, and color scheme), to paper prototypes, to digital mockups, and finally to code prototypes.  At every stage, this fast iteration has resulted in thousands of small, incremental improvements and it shows.  

At the concept testing phase, we used Ask Your Target Market.  This allowed us to get opinions from a diverse range of demographics all across the USA.  We identified several "turn-offs", what worked and what doesn't.  Our company name choices were down to BrieHarmony and Spoondate, Spoondate turned out to be more memorable, more unique and much less likely to cause a lawsuit.  A lot of people we meet say they love our brand, this is why it's so polished.

At 500 Startups, we went through the INTENSIVE 3-day Design Bootcamp hosted by Janice Frazier from Luxr (which is AMAZING btw) in collaboration with the Stanford dschool.  From that, we were shown the magical efficiency of paper prototypes.  We built paper versions of our ideal website, people could click on links with their finger and by moving things around and thus the "site" could be interactive. We were able to test our initial prototype with real people this way.  We identified something like 30 pain points for users in the signup flow alone.  The idea of testing our concept with REAL users using JUST paper prototypes was so foreign and impossible to us before this.  Now it is natural and easy. It has saved hundreds if not thousands of development hours so far.

For digital mockups, we started with GoMockingbird.  This allowed us to create clickable mockups that we could share digitally for testing purposes. Digital mockups allowed us to map out all of the interactivity at a larger scale and then allowed us to share with people who weren't physically near us.  User testing extended to anybody on the internet.  GoMockingbird works really well until you need to export to PDF - the interactivity is lost.  For future mockups, we're moving towards Keynotopia - all of the interactivity works even if you export to PDF.  Keynotopia lets you create fully interactive mockups using JUST Powerpoint or Keynote (these mockups work on every platform that supports .ppt including Windows, Mac, all iOS devices, etc).

For code prototypes, our code has been designed from the beginning to be flexible.  Our database is schema-free without side effects - adding or removing fields on production is as easy as adding or removing a line of code.  We're not at 100% unit test coverage yet, but when we get there, Spoondate will be using Continuous Deployment - then, even a VC can push live code.  With everything in place, we can turn on a dime - even at scale!

Here at Spoondate, we don't just read or talk about Lean.  We live it.