Step 1: Find it

You need to find or invent a great domain name that’s available for sale.

What makes a name great? Pick something that other people find memorable, easy to pronounce, and easy to type (including on a mobile phone). It doesn’t have to be a real word, but I do find real words easier to remember and spell.

I also recommend making the domain name the same name as your business or the main product/service you’re promoting. That way, your customers only have to remember one thing, and you don’t split marketing dollars across two different names.

For me, coming up with a good name is easy; it’s finding a name available for sale that’s hard. In general, most of the names I want are already taken. Hopefully you have better luck than me. But luck need not be your only companion; here are some useful tools for finding domain names:

• Lean Domain Search
• Domainr
• Wordoid
• NameBoy

I found all of these via Hacker News, where people love talking about nerdy topics like this. I like LeanDomainSearch best.

Step 2: Register

Once you’ve found the domain name you want, you lay claim to it. To do this you pay a small fee to a “Domain Registrar”.

Tread carefully; there are hundreds if not thousands of domain registrars, and many of them are shady, if not downright annoying to deal with. Be suspicious of registrars that offer you an amazing deal for the first year; they often hike the price in subsequent years, try aggressively to upsell you to extra products you don’t need, and make it very difficult for you to transfer your domain name to another registrar later on. Sadly, that’s the norm in the domain registration business.

The two domain registration companies I recommend are Namecheap.com, which I’ve used extensively since 2006, and DNSimple, whom I’ve done business with since 2011. (By the way, these are not affiliate links. If you want an affiliate link, find it at the bottom of this post.)

With Namecheap you get:

• cheap domain registration prices
• less upselling than most other registrars I’ve tried
• easy transfer out, should you want to switch providers
• a usable interface, although managing DNS records is a bit of a pain

With DNSimple you get:

• modest domain registration prices, usually $2 or $3 more per year than Namecheap
• excellent tools for managing DNS records
• a delightfully easy-to-use interface (the best I’ve found)
• no upselling
• easy transfer out, should you want to switch providers

Basically you pay a bit more with DNSimple to get the best user experience and some additional tools that are very handy if you’re managing many domains. If all you need is cheap and simple, try Namecheap.

I have also used, and do not recommend, GoDaddy (infuriating upsell tactics) and Namespro.ca (not competitive on price).

I have heard good things about Badger and Hover, but haven’t used them. I’m curious to know more.

Here is a LifeHacker post on the Five Best Domain Name Registrars.

Step 3: Renew

Congratulations, you’ve registered your domain name. But you don’t own it; a domain registration is much like a lease, in that you’re renting the right to use that name for a year. So in one year you’ll have to renew the registration by paying another small fee to your registrar.

Your registrar will almost certainly email you a renewal reminder, as they want to keep your business. But you should set your own calendar reminder for about 10 months from now.

If you miss out on renewing your domain, your lease will expire, and the domain name becomes available for other people to purchase. Getting your domain name back after the expiry deadline is sometimes possible, and always hellish. So don’t forget.

Another important reason for a reminder is that switching to a different registrar, which you might want to do, takes time. You need to start on the transfer process a few months before expiry. Registrars won’t let you transfer your domain name elsewhere if you’re within the last week or two of the registration year.

FAQ

How much should I pay for domain registration? $20? $30? You shouldn’t pay more than $15 a year for a .COM domain name. You may be able to find promotional deals as low as $8 per year (search for “discount code” + the name of the registrar). Most of the time I pay between $11 and $14 a year. [Update 2013-04-24: see Ed Kaim's useful comments about purchasing $0.99 domains on GoDaddy]

Should I try to get the “.COM” domain? Personally I prefer .COM, especially in North America, as it’s what most people associate with businesses and with websites in general. But you may want a country-specific domain (.CA, .CO.UK, etc.) if your business serves a particular geography. And for a not-for-profit you’ll want to get the .ORG. In many cases I’ve registered all three.

“GoDaddy’s prices look amazing, should I buy through them?” (Insert favorite cut-rate registrar here.) I don’t recommend registering through GoDaddy, as I have found their upsell tactics infuriating. Many of the cheap registrars offer poor service, in my experience. [Update 2013-04-24: I stand by my advice here, especially for newbies, but see also Ed Kaim's useful comments about GoDaddy]

How many years should I register my domain name for?  To start with, 1 year. You can always register for more years later, and most registrars give you a price break for doing so. But to begin with, especially when you aren’t sure you’ll like the registrar, and you aren’t certain you will invest marketing into the domain name you’re purchasing, start small.

Can I buy a domain name before I’ve set up my sole proprietorship/partnership/corporation? Yes, and you absolutely should. Buy the domain name on your own dime and transfer ownership to your business later, when you’re ready.

What is “domain privacy”, and do I need it?  Domain registration information is all publicly searchable via a “WhoIs” report. Domain privacy masks the name, phone number and address you use to register a domain. So if you’re using your personal phone number and address, privacy might be appealing to you. On the other hand if you’re buying with a business phone number and address then use that as the registration info. Many registrars offer privacy free for a year but then charge thereafter. Personally I haven’t found the privacy features worth the hassle.

Should I buy “web hosting” services at the same time as I buy the domain name? No. Many domain registrars will try to sell you on this, and it just isn’t necessary.  To start with, simply register your domain. Figure out hosting later, once you’re sure you really want to use that domain name, and after you have your site design figured out.

How should I build my website and where should I host it?  This is a deep topic, so I’ll cover it in another blog post. But the short story for most small business owners I’ve talked with is this: use WordPress.com. If all you need to do is put up a 1- or 2-page website with a bit of info about your business, WordPress is a cheap, quick starting point that looks great and requires zero management time from you after you’ve put it up. Start there.

You promised me I could click an affiliate link, didn’t you? Indeed, I did. Here is my Namecheap affiliate link. Enjoy.

People are very, very good at smelling authenticity. Without this ingredient you will fail to create a self-sustaining community, be it online or in the real world.

I think we did well on the authenticity front with 5 Blocks Out. Our community members added real tips and real photos of real places they really cared about. Many business owners added their own content too, which was great, save for the few times someone was not up front about their identity.

We encouraged folks to use their real names on the site, and almost everyone did. We also gave everyone a publicly visible profile page, which helped a lot in terms of accountability. (There was no ability to comment anonymously.) I think we could have gone even further down this track by using mobile phone numbers or physical addresses as more weighty means of confirming identity.

We suffered a spate of spambot user account registrations for a while, and fought that back to a standstill. Painful. Days wasted.

The real test would have been our ability to maintain a high degree of authenticity at the scale of millions of members. That’s a really hard problem, and I don’t envy search engines and sites like Yelp and CraigsList in having to fight that fight every day. I wish a white knight would come along and provide a better authentication solution so that little sites wouldn’t struggle to reinvent the wheel on user identity and authentication (poorly) every single time. I’d pay for that!

One of the things that made 5 Blocks Out truly challenging was the problem domain: local. And more specifically, neighborhood-level advice. It’s a tough space to succeed in.

If you’re thinking about doing a local product or service, here’s a list of hard problems you will face.

1. Local content means building N different content bases — one for each locale — and (more difficult) possibly N different communities instead of one big community. In our case we chose neighbourhoods as our community hub, and while I’m convinced that was spot-on from an end user standpoint, it definitely made it harder to build online community. There are over 180 neighborhoods in Toronto, so arguably we had over 180 distinct online communities to build. Two people can’t do that on their own.

2. The local space is crowded. It wasn’t so heated when we began, but Yelp launched right around the time our site did, and soon after came Google Places / Local, Facebook Places, FourSquare, and a long list of others. This was not a blue ocean! Every week someone would email us a link to one or more new web services in the local space that smelled a little like 5 Blocks Out. All these services were subtly different, but getting that endless stream of “Hey did you hear about X?” email is distracting, and sometimes disheartening.

3. “Local” means many different things to different people. Places. Events. Photos. Checkins. Reviews. News. Stories. Lists of local things. Our users asked for all of these things. We designed and shipped support for four: places, photos, tips (similar to reviews but positive and helpful in spirit), and missions (lists). We built but did not ship support for events and stories. We found it hard to stop at the edge of any one of these. We found it hard to focus on only one subset of our users and say “no” to the rest. We should have focused more narrowly.

4. Local business owners are, generally speaking, not techies, and not wealthy. They tend to own small businesses, and they work very hard to stay afloat. They do not care about your website-technology-thingy. They care about things that will improve their ROI very quickly and cheaply. So if you want to create a revenue model for your local service based on revenue from local business owners, first go and talk to some of them. You’ll probably conclude, as we did, that the Yellow Pages business has been around so long in large part because local sales is so damned hard. Sales partnerships may be a better way to go, for a startup.

We had a clue about all of these challenges when we started. We got smarter as time went on. If I had a do-over I’d still enter the same space (because I love it), but I would have tried much harder to focus narrowly.

Bottom line: pick a space you have passion for and can get real traction in.

P.S. To get smarter on local, read Greg Sterling on Screenwerk.

This article is about the importance of investing in design before writing code.

If the design of your product is flawed from an end user perspective then all the shiny implementation technology in the world won’t help you succeed. So get the design right first.

Step away from the keyboard. I’m talking to you, programmer-type person.

It makes more sense to go as far as you can in proving your product concept (and hopefully disproving some parts of it) cheaply, with pen-and-paper sketches, mockups, slide shows, surveys, face-to-face discussions, and the like. Only when you hit diminishing returns on this AND you’re fairly certain you’ve found a market for your product design should you get heavily into designing software architecture and writing code.

I am not just parroting shit I read in the latest book on how to build products. I’ve learned this the hard way, having done the opposite for too long.

Why design first? Because exploring in code costs way more than exploring on paper. In a given unit of time you can explore easily 10x more ideas via pen-and-paper sketches than code. What’s more, your willingness to try new things will be higer. Your latest napkin sketch idea doesn’t pan out? Throw it away, sketch another, no big deal. Your latest code idea doesn’t pan out? Well… it took longer to create… perhaps we should refactor it instead of casting it aside?

I am not saying that exploring a product idea with code is bad. Just that it is more efficient to do once you’ve explored in other, cheaper ways first.

It’s harder to walk away from code. The sunk cost is higher. And so code tends to have far more inertia than a paper sketch. People will usually fight  much harder to keep a line of code than to keep a pen-stroke on a piece of paper.

We created literally thousands of paper sketches of design concepts for 5 Blocks Out, and I’m thankful we did. But we also committed the error of writing code in parallel with that design exploration, right from the outset. I justified it as “infrastructure we will surely need”. I was wrong; it turned out we didn’t need a lot of the code I wrote at that early stage. Most of my time at that stage would have been better spent helping on the design and validating our thinking with customers. Yes, really, most.

Using Ruby on Rails as our main technology made it even cheaper (and more tempting, and fun) to explore in code. I would have been much less of a cowboy if I was still coding in C!

Thinking back, several teams I worked on at Microsoft did the exact same thing. The circumstances were totally different, of course. In any case, we were unable to resist the urge to write code prior to figuring out a solid direction for the next product version. And this urge is much harder to resist in a big team…

the clock is ticking, money is burning, we have all these typists here, shouldn’t they be typing?

(The Microsoft in me says, “Don’t be ridiculous, we had awesome devs on our team ready to move mountains. Did you honestly want them to sit on their hands and do nothing until we had a design in hand, or worse, move to another team?” It’s hard to answer yes to that, especially as a manager. But the answer really ought to be yes. Work on design instead. Figure out what the product should be. Then get into architecture, which is a more detailed and expensive type of design. I wish we had done that instead of writing so much code that, in the end, we wanted to throw away. And sometimes did, but often couldn’t bring ourselves to.)

Unlike a paper sketch, code in a product has an ongoing cost. You need to test it, deploy it, support it, and integrate it with all the new code you write from then on. So if it’s code you should not have written in the first place, well congratulations, you’ve just created a perpetual inheritance tax.

I also realize now that the mere existence of working code short-circuited our design process. We could and should have explored further on paper but stopped because we had working code already. Code anchors design thinking.

So design first. And if you don’t have a great deal of design skill then try to partner up with people who do. And then listen to them!

#1: Work on something you love.

I really believe that the amount of energy and time required by a startup project is so high that, if you are working on something you don’t care all that much about, you’re setting yourself up for failure. So be draconian with your time. Be greedy on jealous of how you spend it and how you allow others to spend it.

A different way to say this is, “work on something that allows you to live in the moment”. Life is too short for anything else to be worthwhile. At least, not for very long.

This is true for regular work too, just moreso for startups because they tend to be far more demanding.

Yes, it’s possible to justify working on a project as a good investment for the future, even though you may not love it right now. And that may be OK for 3 months, or 6, or perhaps even 12. But 12 months of working very hard on something you don’t love is way too long. That’s thousands of hours of your life spent in a way you might regret. Instead, find something you love to do, and you’ll be able to enjoy each moment you spend on it.

This lesson is eminently clear to anyone who is a parent. When you have a child your free time gets crunched down to zero, or near that, for quite some time. You wish you had more of it, but recognizing — admitting, perhaps for the first time — that it’s finite, and scarce, you begin to re-evaluate how you spend your time. And you begin measuring everything else in relative terms: “Is this work worth 8 or 10 hours a day away from my daughter? 60 or more hours a week?” It had better be, because you will not get those hours back. And the older she gets, the more she will remember the choices you made.

I’m proud to say we got this one right from the start on 5 Blocks Out. We loved working on it. Sure there were some moments that we didn’t enjoy, and many things about the project were difficult. But all in all it was a labor of love, and there is little I regret about how I spent that time.

Since January I’ve spent far more time than I expected to on CampusPerks, far less time than I wanted to on a yet-to-be-announced startup project, and almost no time on 5 Blocks Out. Oh, and we just welcomed baby number two into our family on July 26. Busy times, to say the least.

It’s 5 Blocks Out I want to write about today. Last week we shut it down; here’s our farewell note. I want to explain why and talk about some things we learned by working on it.

First, the why:

not enough traction.

It would be easy to just leave it at that, but a little cowardly. We all know “not enough traction” is a euphemism for “your customers didn’t care enough”. And that deserves an explanation.

Many people loved the idea behind 5 Blocks Out — helping neighbours share helpful tips on all things interesting and local – and told us that. But the specific incarnation we built didn’t inspire enough people to keep coming back and contributing on a regular basis. We found we could not get the community to sustain itself without continual investment of our own in stoking the flames: inviting people to join, adding photos, adding helpful tips, tinkering with the design, and so on.

It would have been easy to walk away much earlier if everyone had said, “Hey, this thing you built is really not very good, and I will never use it”. But so many people told us the opposite. And so it took us a long time to concede that, try as we might, we couldn’t convert all that positive sentiment into enough regular return visits, or sufficient growth in content contributions. We had created a nice campfire that simply lacked the fuel to become a roaring blaze.

A few weeks ago we finally pulled back and decided to stop.

Damn.

I. hate. quitting.

We tried so very hard.

Thank you, Katrin, for being such a great partner in this and our other ventures. I learn so much from you!

And thank you to everyone who participated in 5 Blocks Out. We are very grateful to have worked on it with you.

I’ll write more, soon, on lessons learned.

“Small batches” have been on my mind a lot lately. Eric Ries discusses the concept in his Lean Startup book. The basic idea is to do repetitive work in small end-to-end batches, creating one finished product at a time, rather than in large batches where you create many products at once in a phased manner. He credits the concept to Toyota, and applies it in turn to startups. Here’s a real-world example from his book of a race on stuffing envelopes between a father and his two daughters:

The daughters, age six and nine, knew how they should go about completing the project: “Daddy, first you should fold all of the newsletters. Then you should attach the seal. Then you should put on the stamps.” Their father wanted to do it the counterintuitive way: complete each envelope one at a time. They told him “that wouldn’t be efficient!” So he and his daughters each took half the envelopes and competed to see who would finish first. … The father won the race, and not just because he is an adult.

Ries cites many benefits to doing work in small batches, including less waste, less inventory, earlier discovery of defects, and a tighter feedback loop. I’ve found all these to hold true in doing software development. I happen to be focused on web services, but I see no reason these benefits wouldn’t also hold true for many other kinds of software and creative production work.

When not writing code I’m often planning what work we should do next, and I’m finding the small batch philosophy yields benefits on planning too. Here’s an example: we made a change on CampusPerks a week ago to our planning granularity. We used to estimate our work in half-day units, equating 1 Pivotal Tracker “point” to 4 estimated developer hours. Now we equate 1 point to 1 estimated developer hour. Sounds simple, right? You might think it would have little to no effect, but in fact after only a week I can already see a few significant benefits:

• We’re estimating our work with greater precision, and there’s a 1:1 mapping between estimated points of work and available developer hours. So questions like, “Can you get feature X done by Wednesday?” have become easier to answer (i.e. less time-consuming, with smaller error bars).
• We can now give credit for smaller pieces of work… the sort of stuff we might have assigned zero points to in the past because it took an hour or less to do, or lumped together with 4 or 5 similarly-sized items into a 1-point story. I find this especially true of design work, the fit-and-finish and attention to detail that is essential for making a product beautiful, but that often doesn’t get the full respect it’s due. Being able to give credit for all work regardless of its size feels more equitable to me and, I suspect, makes everyone on the team happier.
• It’s easier to decide how to fill small chunks of available work time. If I have an hour before lunch I can take 10 seconds to pick the next 1-point item off the backlog, knowing that I’m likely to complete it before my energy fizzles. In the past I might have wasted 5 or even 10 minutes hunting for a small-enough work item.
• My motivation to begin a new work item is higher, because none of the tasks look as daunting now (everything is scoped in hours, not half-days or days), I’m more certain of how long each task will take, I get to check off tasks more frequently, and I almost always get the satisfaction of carrying the baton across the finish line on tasks that I start.
• All this leads to more time when I can reach a state of flow.

The fact that chunking work in this way motivates me more and helps me reach flow was a delightful surprise, so much so that I’ve applied the same 1-point-equals-1-hour change to the other software projects I work on. It isn’t just accounting or semantics; there’s a real psychological difference. The bottom line is I find myself more willing and able to work if I invest the time up front in batching the work into smaller units. The work is easier to begin, faster to complete, and more satisfying to perform.

Pivotal Tracker. This is the single tool I use for managing software projects at the designer/developer work item level. It’s great… very easy to use, full history tracking, lives in the cloud (backed up), optimized for software projects, predicts dates for me, and lets me organize work into a few logical buckets. Some people don’t like the automatic date prediction, and if you need to work that way (“Precisely Scheduled Project Candy-Cane Land”) then it is not the tool for you. I think Pivotal would also work for many other kinds of creative project work — not just sofware — and I’ve suggested this to the good people at Pivotal Labs a few times, but they seem locked on the software space. All the better for us nerds.

Trello.  Trello is my single “big picture” list-making tool these days. At work I’ve just started using it for tracking high-level work project deliverables, e.g. key milestones and handoffs with clients. At home, I use it with Katrin to plan our expenses, prioritize home improvements, track movies, music and books we’d like to buy, and more. It’s simple, visually beautiful, and works on our computers, phones, and iPads. I’ve only been using it a few months now, but I think this one will stick because it addresses so many of the failures that stopped me from using other list-making tools.

Text files. When I’m keeping scratch notes on a project, or drafting a blog post, or trying to organize something that doesn’t fit into a list, it goes into a text file. I write in either straight .txt format or MarkDown to get a teensy bit of formatting. Every file is named yyyy-mm-dd-the-topic-title.md, e.g. “2012-01-27-writing-about-startups.md”, and this gives me a clean way to organize files and rediscover stuff I wrote months or years ago. Within software projects, a few text files in the doc directory suffice for readme’s and specs, and they get stored in our git repository for backup. For personal stuff, gitdocs automatically backs up my docs directory to the cloud. If I need a fancier looking document I generally switch to Google Docs, as I hate trying to reconcile and merge copies of office docs. But I always miss the speed and simplicity of editing a local text file, and I find myself back in text files before long, ast least for the initial drafting step.

Here are some tools I’ve tried that didn’t work well:

• Rich text “office” docs stored on a file server, e.g. Word, Excel, StarOffice, etc. plus file servers, Sharepoint, DropBox, etc. The richness of these document formats is fantastic for loosely structured content, but I find I always get caught up in formatting content and rearranging it on the page instead of getting down to the real work of writing. (Now that I write code for a living, I grit my teeth when someone sends me an amazingly formatted rich text document. “How long did that take to do?”, I wonder, and “how much better could the actual content have been if you hadn’t spend so much time formatting?” Sorry, all you devs I spammed with beautiful specs at Microsoft.) I’ve also never found a filing system that worked for teams… they all turn into junkyards, and then into graveyards. So I try only to go here when I have to work with big, bulky documents, e.g. video, PhotoShop PSDs, and such.
• Calendars, e.g. Google Calendar, iCal, Outlook/Exchange. Some people are huge fans of putting everything on a calendar, arguing that it forces time-based tradeoffs, thereby avoiding overcommitment. I find this too constraining. It forces me to think of everything in half-hour or 1 hour chunks of time, which isn’t a natural fit to the kind of work I do right now.[1] It limits my flexibility in deciding what to work on at any given moment. I don’t want silly reminder popups interrupting me every 30 minutes. My calendar drifts towards being 100% blocked out, and then I start chopping time into 15 minute segments… madness. And I find myself spending way too much time trying to optimize which day and time each thing needs to happen on. Time trap.
• Defect trackers, e.g. JIRA, FogBugz. If you have a defect-tracking list that’s separate from your feature-tracking list, it’s easy to ignore, because it’s one more thing to pay attention to. Plus you have to continually make arbitrary decisions about whether something is a defect, a feature, or in between (“by design”, “spec bug”, etc.). This is a waste of everyone’s time… who cares what you call it, the question is “are you going to do it, and if so, when?” What’s more, the same people who build features are usually responsible for fixing bugs. So I try now to avoid the disconnect by using Pivotal, which combines “bugs”, “features” and “chores” into a single work list.
• Project schedulers, e.g. Microsoft Project, or Excel for critical paths. Gantt charts and the like are pretty, and the promise of accurate schedule prediction is enticing. But they’re a lot of work to build and maintain, and they rely on people being good at estimating work, managing risk, predicting uncertain future events, and sticking to commitments. In my experience, most people (myself included) are not very good at any of those things. So project schedulers lead you down the path of building a beatiful house of cards, only to have to reconstruct it every week or two when schedule predictions are inevitably proven wrong. They are good only for point-in-time “aspirational” planning, IMO. Some projects do need this (building a new airplane, say), but I’ve found that many do not.
• Task lists and To-Do’s, e.g. in gmail, Microsoft Outlook, Things, Basecamp, etc. These tools encourage you to break goals down into fine-grained tasks, which you then prioritize and check off when they’re done. I find I tend to put way too many things on task lists, at which point I promptly get overwhelmed with analysis paralysis. Not for me.[2]

As a rule, when I find myself spending more time organizing the work rather than immersed in doing the work, I have a broken process. At that point I stop, hit the reset button, and start over. The tools I’m using these days are great assistants: they help me arrange my plan, and then they step quietly out of the way.

Thanks Ilia for the nudge to write this.

[1] Outlook/Exchange calendaring was an essential tool for me in my last few years at Microsoft, because most of my workday consisted of meetings. But even so, I used the calendar way too much. Better to leave some ad hoc unscheduled time in the day. Give serendipity a chance.

[2] I’m not sure why I find Trello so much more pleasurable than any of the task list and to-do list alternatives. After all, Trello is at its heart a list-making tool. Perhaps something subtle in its design helps me “chunk” list items at a more appropriate granularity. I’ll have to think more on that.

“How will I pay the bills?”, you might ask. “What if it all goes wrong?”  ”How will this look on my resume?” “What will my friends think?” “Will my family understand what I’m doing?”

Well, to the last of those, I will answer “probably not”. Unless you come from a family of entrepreneurs, your fam will probably have no clue what you’re doing. This will make for lots of awkward holiday dinner conversations. Oh well.

Will you have to take a pay cut? Probably. In exchange for your Stable Corporate Salary you will get to work on an idea you are passionate about, in a work style you own, with a chance at more long-run financial upside. If that tradeoff of short-term money for immediate happiness, immediate control, and long-term financial potential sounds bad to you, stop now.

As for the optics, I guarantee you will become a more interesting person, both on paper (your resume) and in the eyes of your friends. You will be learning new things, meeting new people, stretching yourself. Simply by taking this risk you will be markedly different from everyone in Corporate World. If you go back, you will be noticed. And that’s a good thing.

Lastly, what if it all does go sideways in Startup World? Consider this: when you exit a stable job in which you’ve done well, it’s highly likely you can turn right back around and knock on the door you just stepped out of. All those people you just said goodbye to like you. They miss you. They might even envy you. And they will be happy to see you again.

Pretty good worst case, no?

Don’t be afraid of the start.

For a brief while, somewhere around beer number three, I had a flashback to 2005 when I moved to Toronto. Things were very quiet in the tech startup scene. Ruby on Rails was just starting to take off. DemoCamp had yet to begin. Lots of smart people were building things with software here, but most of them worked out of IT departments in office towers on Bay Street. The only “tech startup” people could commonly name was RIM, and it was already 10 years old and publicly traded by then.

Things have changed. A lot. There were over 100 attendees at Unspace HQ last night, with at least 20 employers pitching their companies, all vying to hire Ruby developers. I saw a lot of familiar faces, but also many new people I’d never met before. And pretty much every employer in the room was representing a startup. Joey de Villa was there from Shopify. Paul and Geoff from CommunityLend. Katherine Hague and Phil from ShopLocket. William and Bart from Engagio, freshly funded by Fred Wilson of Union Square Ventures. Paul from GaggleUp. Krista and Aidan from Winston. Mike with his University Health Network project. Startups everywhere.

That says a lot about Ruby on Rails; it’s clearly got great traction in the web startup space here. It also says a lot about Toronto and the community that has grown here around Ruby, Rails, and web startups. The barriers to creating startups are coming down. Starting a company is now much more socially acceptable here, desirable even. Designers and developers who want to be true craftspeople increasingly “drop out” of mainstream IT work to join startups. Technologies like Ruby, Rails, git and Heroku continue to reduce the cost of building and deploying great web software. And, at least from my little corner of the web, the local demand for web developers and designers seems to be at an all time high. All subjective, I have no hard numbers to offer, but I believe it’s real.

The startup scene in Toronto is really taking off.

I love that fact.

Much of this has come about organically, due to these enabling factors kicking in at the same time. But it really struck me last night that the community piece is different. This community didn’t just spontaneously assemble itself and become awesome overnight. Instead, a small handful of very diligent community builders, most notably Pete Forde, Meghann Millard and their amazing crew of coworkers at Unspace, worked hard and gave freely of their time and energy to help seed and build this. Free advice. Encouraging pats on the back. Rails Pub Nites. Technologic. Ruby Fringe. FutureRuby. Ruby Job Fairs. Friendship, even. They have done a ton to foster and ignite the web startup community here in Toronto. And they continue to do so.

So I will say it here, and hope others repeat it: Thank you, Unspace. You are doing great things for Toronto. We are proud of you.

#ThanksUnspace

Update 2012-02-13: Fred Wilson personally funded Egagio. The funding is not from Union Square Ventures. Thanks William for the correction.