StartupNorth

Author: BryanWatson

  • Toronto is broken

    Editor’s Note: This is a cross post from Zak Homuth (LinkedIn, @zakhomuth) originally published August 7, 2012.


    Image by John Cavacas link

    I’ve got bad news. And I don’t really know a better way to say it, so I’m just going to tear the bandaid off, one motion, no fucking around. Here goes…

    Toronto is broken.

    Ugly right? We’re the 4th most active startup ecosystem in the world. We’re the largest ecosystem in Canada. And were the best non-US city for funding.

    But there are some very serious problems under the covers.

    Toronto is a young startup ecosystem, largely because it wasn’t always possible to run a startup here. This has 2 effects as far as I can tell. The first is that most of the entrepreneurs here in Toronto are very young, the average age is definitely lower than the Startup Genome Project average of 33. And the second is that almost all of us aren’t tied to Toronto. We have all been somewhere else, worked somewhere else, and got money somewhere else.

    Weak Founder Network

    Being young & unconstrained means we don’t brag about or lean on our native networks in Toronto. We brag about our investors and mentors in the valley (like we all haven’t been), we try to impress our Toronto network instead of learning from them, and we don’t trust our peers here to help us succeed. Its ok. And its pretty normal from what I’ve seen in other fledgling startup communities.

    BUT until we can trust and work with our peers here in Toronto the community will continue to flounder. We will continue to leave (not necessarily a bad thing). We will continue to NEED other networks. And getting together will continue to be about bragging instead of helping and learning.

    Small Ideas

    I’m not sure if this is because the ecosystem is so young. Or because our service providers think they run startups. Or because we’re a largely Canadian club. But our ideas on average aren’t world changing. We dream of things that already exist. We dream of parts of other company’s visions. We dream of features. We dream of being an Instagram for Instagram rather than Facebook, Go instead of Google, CRM instead of Salesforce.

    This is a theme across the startup galaxy right now. But we aren’t helping. Why not be the place big ideas come from? Why not be known for dreaming bigger? Lets be frighteningly ambitious. Lets change something. Fuck the $25MM Google acquisition. Can we please do a little bit more than building another feature for Salesforce?

    Crossing The Scale Gap

    We have almost zero entrepreneurs and early employees experienced at scaling. It might even be the real reason for the pre-scale acquisitions lately. We can’t cross the gap. Who are you going to hire to scale your marketing? What about sales & bd? Or support? Or product management? Have they ever done it at a startup before? Better still, will they – without a question – give you an unfair advantage because of how awesome and repeatable they are at it? I doubt the list is any longer than a few names for each – and I bet most of them are running their own startups or have retired.

    There is a huge void here that doesn’t exist in SF or even NYC. We have very, very few startups that have achieved scale, cycled, and produced experienced founders or employees that want to go back out and do it again. This is why so many of our startups open offices in San Francisco or Palo Alto. Will you? Does it bother you that you have to split up your team, or move? You need to move if thats how you win – but could we ever help each other to do it here at scale?

    Mentorship

    Its pretty weak in Toronto. Its a side effect of the same lack of experience. The same lack of cycling. And there just isn’t the same kind of culture of free giving that exists in the valley. We have this sort of East Coast I work to get paid mentality that doesn’t jive so well with mentorship. All that being said I can’t fix this. This is a huge problem that has cultural roots, a lack of raw material, and well all be dead (or at least our startups will be) by the time it gets fixed.

    My advice: Get a mentor in the valley, and figure out how to use skype.

    Capital

    Don’t waste your time raising in Toronto. If you can and do raise elsewhere Toronto will pay attention. If you can’t, they still wont. And the best part is you don’t need permission to be in Toronto anymore if this is the right place to run your business.

    My advice: Raise the money where you can, run your business where you need to, and get the fuck back to work.

    But…

    There still are some pretty great things about Toronto. Hell, I haven’t left yet. The talent here is A+, the money goes further, the government helps, its one of the biggest economies in North America (ie. fuck loads of customers), and you can build a first class startup culture of first class talent that has worked at startups in the valley and abroad.

    So lets fix the broken parts. I think its still worth it.

    Too much words? In picture form!

    Problems I’m trying to fix:

    • Build a stronger founder network
    • Encourage and enable bigger ideas
    • Fill-in or otherwise enable companies to cross the scale talent gap

    Things I’m NOT trying to fix:

    • More and better mentorship
    • More and better capital

    About Me

    Upverter is my 3rd startup. I dropped out of highschool, and then university, both times to run startups. I’ve worked in Ottawa, Waterloo, Stuttgart, Bangalore, and Mountain View. I have never lived in Toronto before, so it’s a first for me, but we’re here because it’s where our team wanted to be. And I’m not ok sitting back and letting this opportunity – to make Toronto kick more ass – pass me by.

    Wanna join the cause?

    Shoot me an email ([email protected])

  • Toronto: Why Are We Here?

    Editor’s note: This is a cross post from Zak Homuth (LinkedIn, @zakhomuth, Github). Follow him on Twitter @zakhomuth. This post was originally published on February 1, 2012. And like many startups, Upverter is hiring.

    CC-BY-NC Some rights reserved by wvs
    AttributionNoncommercial Some rights reserved by wvs

    Its winter right now, and that means for those of us in the north east its cold. We try to pretend its a good thing; that it keeps us focused. But the reality is we dont live and work here because of the snow, we live and work here because smart people love, more than anything else in the world [pg], to work with other smart people. And, make as many snow jokes as you want, but…

    Pay attention to Toronto

    Canada is the best country in the world to do business in [forbes], Toronto is the most multi-cultural city in the world [wikipedia] (suck-it NYC ;)), we get tax incentives for R&D [gov], and its the only city within an hour of one of the worlds foremost engineering schools [uwaterloo,coop program].

    So, I say again, you should be paying attention. And if you’ve got your shit together you should be trying to figure out how to get a footprint here. Because believe it or not, we dont all want/have to be in the valley [fred].

    All that being said, I still get this question a lot

    There is a (very reasonable) expectation that YC companies make every effort to relocate to silicon valley as part of the program. And the fact that we have most of our operations in Toronto raises some eyebrows. My answer is really simple: The talent is here and it wants to be here. Sometimes I even go as far as talking about how much further our investment takes us when we spend it here instead of in the US, but at its root its a talent thing.

    Toronto isn’t the only place in the world

    Its true. I still spend a tremendous amount of time in the valley. And we have customers all over the world. Simply put there is no perfect place for everything. But if youre building a product business, or looking for talent, you could do much, much worse! Toronto is great for talent, and its a great place to live. Oh… and Im sure its not supposed to matter but like my good friend dave [blog] would say, “look at the scenery”.

    But, its also a terrible place to raise money. Like I said, nowhere is perfect.

    About Me

    Upverter is my 3rd startup. I dropped out of highschool, and then university, both times to run startups. I’ve worked in Ottawa, Waterloo, Stuttgart, Bangalore, and Mountain View. I have never lived in Toronto before, so its a first for me, but we’re here because its where our team wanted to be. We are currently 7/7 kick-ass, and 6/7 Uwaterloo engineers who would just rather be here at home in Canada, than down in the valley. Oh, and if you’re smart, we’re hiring.

    Editor’s note: This is a cross post from Zak Homuth (LinkedIn, @zakhomuth, Github). Follow him on Twitter @zakhomuth. This post was originally published on February 1, 2012. And like many startups, Upverter is hiring.

  • 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, @zakhomuth, Github). Follow him on Twitter @zakhomuth. This post was originally published on August 1, 2011, I was just negligent in posting it.