In 2012, my friend Ben Sperry and I launched our startup Codiqa, in Madison, Wisconsin. Since the year is almost over, I thought it would be fun to create a timeline of events that carried us through the year, as well as touch on what we are excited about in 2013.

In one year we went from just an idea to a three-person profitable software startup. Here’s how we did it:

Late 2011 – The Birth of an Idea

When we built Codiqa, we didn’t really have any plans to turn it into a business.

We built it because we were doing jQuery Mobile development through the standard mockup -> prototype -> end-product process, and we thought mockups were redundant when the end-product technology was known (in this case, jQuery Mobile). Why not have a simple interface builder for jQuery Mobile that could quickly build these kinds of apps?

There were a few visual builders for jQuery Mobile, but we largely put them out of our mind since we just wanted to build something that was ours. We started playing around with the idea late in 2011, but we hadn’t shown it to anyone yet.

Ben and I also had full time jobs at a local mobile game startup, Perblue, so we were juggling our 9-5s and our side project.

Jan 1st – The Landing Page and Initial Users

Before we had a working product, we threw together a fun landing page that had an interactive demo and a viral share option upon entering your email for our beta mailing list. We launched this landing page in January of this year:

Through this landing page, we grew to about 1500 interested beta users, primarily through Twitter shares.

February 1st – Private Beta

When we felt like we had a product that worked well enough, we started inviting some of our initial users into the beta. The biggest feedback we received was that this was awesome…but way too buggy.

Ben and I had just read about the Lean Startup method, and we were trying to apply it to Codiqa by releasing early and often, testing our ideas with customers, and tweaking them when we had learned what worked and what didn’t.

Over the next few weeks we took what we learned and the bugs we found and tweaked and improved it, releasing many small updates in a short amount of time.

February 20th – Public Beta

By the end of February, we felt confident we had something that worked well enough that we could open the product up to the public. We sent an email out to our beta list inviting everyone to the new site, and we replaced our landing page with a real site.

A few weeks before our beta, we started showing the jQuery Mobile team what we had built. We thought it was be an awesome way to give back by making an embedded version of our tool that would make it easy for anyone coming to the jQuery Mobile site to build an app and try it out right away. They agreed, and we tried to figure out a way to make it happen.

At the end of February, we launched an embedded version of Codiqa directly on jquerymobile.com, and started to slowly grow our user base.

A few weeks later we blogged about growing our user base to 10k users in a month, which coincided nicely with a rejection from YC a few months earlier. The post was #1 on HN for a whole day and drew us a great deal of traffic and interest from around the world.

Monetization

At the beginning of March we started to talk about ways to monetize the product. We were just a two-man team that was starting to see that this could become a real company, and we wanted to be able to devote our full-time attention to it.

We threw up some “beta” pricing and slowly but surely the paid signups started coming in.

It wasn’t much, but we had proven that people would pay for this product, and that we were on to something.

May 1st – MVP

In mid-April, we decided to build out features that would better differentiate between individual users and teams of users, so we could offer different pricing plans based on their needs.

We released a new updated MVP at the beginning of May that offered user invites, media uploads, and themes. We also adjusted our pricing and had a decent revenue boost.

Unfortunately, we still weren’t making enough to pay ourselves to work full time.

June and July  - Full Time

By the end of May, Codiqa was making enough for one of us to go full time and pay our living expenses. I decided to leave my current job and go full time in June.

Over the next few months we just focused on improving the product, experimenting with marketing, and figuring out where we wanted to go from here.

The Fall – Marketing

In the fall, we  started ramping up some of our marketing efforts, and we ran some experiments including sales and pricing tweaks. We had our biggest revenue increase in August because of this, and continued to grow over the next few months. We were finally able to make enough for Ben to go full time as well, and he left his 9-5 to join us full time.

Additionally, we formulated some really interesting licensing partnerships with large companies this fall. It’s a bit early to reflect on this, but are excited to see how this impacts our business in 2013.

December to the Present – The Change

In December, things have really changed for us. Chalk it up to more experience, or just understanding our product more, or even just finally listening to advice we had been given over the year,  but December has been a breakout month for us.

We even hired our first ever employee a few weeks ago. While he’s just acclimating still, we are really excited to have more resources to devote to Codiqa to make it way better than it currently is.

We’ve also had some great news come on the business development side, and we are looking forward to several amazing opportunities coming in 2013.

Risk?

The theme for me of 2012 was risk. I did several things this year that initially felt risky, including quitting my 9-5 and throwing out my stock options to do some consulting on the side (a decision that was incredibly difficult for me to do), and then finally quitting that to go full time on my company.

In hindsight, the biggest risk was actually to not jump in on Codiqa. I would have thrown out several amazing opportunities that I would never have had the chance to experience at a normal job. I met so many great people from around the world, and learned so much.

The opportunity costs of leaving a job are quantifiable and potentially meaningful, but the costs of not chasing your dreams are even bigger.

With that, I wish you all a very productive and successful 2013. Things are just beginning for us, and have some awesome stuff in the pipeline. Stay tuned!

How was your 2012? Did you create anything new or improve something old? What are you looking forward to in 2013?

Max

Hi, I'm Max, Co-founder of Codiqa, the easiest way to build jQuery Mobile prototypes. I'd love to talk with you: follow me!

More Posts

Over the last few days, I’ve been overcome with the realization that in a lot of ways I am living my big dream. The dream that kept me up countless nights over the last several years and drove a lot of the decisions I made since graduating college.

That dream is simple: each and every day I get to work building awesome software with my best friend, Ben. I’m my own boss, able to pay myself a fair wage, and even employ a small team of great people who just love making stuff. I get to put my blood, sweat, and tears into something that I completely own and have the responsibility to care for.

The problem is, I find it very hard to sit back and actually enjoy it. It seems like there is never enough revenue, or never a good enough conversion rate. We always need more users, or more followers on Twitter. Our retention is never long enough.

The rat race never seems to end, and we are never satisfied.

Unfortunately, that means we never realize how good something is until it’s gone. I fear we might one day sell our company or make a poor fundraising decision that divides the team, and miss out on something that was truly, at its core, wonderful and special.

Ben and I have always had a core set of companies we look up to, including 37signals, Github, and Balsamiq Studios. While we have always been generally inspired by them, we never really understood why we look up to them so much. What was it about these companies that we just felt drawn to?

Then it hit me: these companies just plain love working with each other, and it shows.

When I think about where our company Drifty is headed, along with our product Codiqa, I get more excited about the opportunity to keep doing what I’m doing with the people I do it with for as long as possible, instead of selling the company and moving on (possibly a little bit richer).

There always seems to be a set of decisions we could make as we grow the company that appear initially as growth opportunities that could actually hurt us in the long run. A lot of our hesitation to chase fundraising or bring on additional major stackholders is due to this fear (however irrational or naive), along with the regret shown by those that have done it and had it backfire.

You can’t buy the magic you feel making awesome shit with your best friends. Not everyone gets to go to work and create their dreams with people they truly love.

If we don’t stop to smell the flowers, we might be missing the reason we love doing what we do. And if we don’t enjoy the journey, why do we even suffer through the trials?

Life is short. So much tragedy recently proves that. I have a hard time believing I will ever be so much happier than I am now that I neglect my life or dream job for money.

After all, it’s the people you love that make your life special. Enjoy them and take pleasure in being fully present in the moment.

Max

Hi, I'm Max, Co-founder of Codiqa, the easiest way to build jQuery Mobile prototypes. I'd love to talk with you: follow me!

More Posts

A few months ago I wrote about how we use Backbone.js to build Codiqa, specifically our Data Model and API layer. A week ago we released a bunch of new updates to Codiqa, along with a faster and more natural feeling Dashboard that utilized some new Backbone.js features I hadn’t used before. Here is a screenshot of the new dashboard:

One of the big changes to the Dashboard was moving it to a pure single page app, complete with non-refreshing navigation, deep page linking, real URLs with History API support, and lazy loading. We also moved to CoffeeScript for the development of the dashboard.

We were inspired by the feel of the new Basecamp redesign, and wanted to incorporate technical elements of it into our dashboard. To do this, we used the great Backbone.Router class, along with some custom changes I’ll explain later in this post.

What is Backbone.Router?

Backbone.Router is essentially a conductor for all URLs that are navigated to inside of your Backbone “application.”

With Backbone.Router you can monitor for a URL or a URL fragment match in the address bar and instead of allowing the browser to make a new request and refresh the page, you process it locally and perform an action.

Behind the scenes, Backbone.router monitors for URL changes in several possible ways: listening for the 'popstate' event on the current window object using the History API, listening for the 'hashchange' event on the current window object, or periodically polling for URL changes.

Why Backbone.Router?

When I first heard about Backbone.Router, I didn’t really see the point. I was used to using things like jQuery UI Tabs which just toggle the visibility of  divs when you hit a hash fragment.

Then I thought, wouldn’t it be awesome to link directly to dynamic and deeply nested content, as if that content was requested individually? Or even to just have nice clean URLs that you wouldn’t be ashamed to show your boss or client?

Backbone.Router lets you do this, and it’s remarkably simple to use.

Defining Routes

On our dashboard, we have a simple routing system based around the different “Panels” a user can navigate to. An example panel would be the Projects panel. Some panels can also have a sub panel. An example of a sub panel would be the Billing sub-panel inside of the Account panel.

To support this, we need to define routes with Backbone:

class DashboardRouter extends Backbone.Router
  routes:
    '': 'showPanel'
    'dash/:panel': 'showPanel'
    'dash/:panel/:subpanel': 'showPanel'

This is the extent of our router. Essentially we are telling Backbone to trigger the showPanel event when the URL path contains 'dash/panelName' or 'dash/planelName/subPanelName' or is just empty. The placeholders such as :panel and :subpanel get passed into the showPanel function as a string containing the entered value.

Inside the View

In our view, we create the router and then listen for the route:showPanel event to trigger

class DashboardView extends Backbone.View
  initialize: ->
    @router = new DashboardRouter
    @router.on 'route:showPanel', @showPanel

In the DashboardView class, we specify the showPanel method. It’s really simple, though this is where you’ll have custom UI logic to hide/show different panels based on the panel name:

  showPanel: (panel, subPanel) =>
    # Default the panel to 'projects' if it's empty
    panel = panel or 'projects'
 
    # Show the panel, toggle buttons, etc.
    # ...

Initializing Backbone.history

By default, Backbone does not use the History API when using Backbone.Router, so you get ugly URLs that have hashes in them. To enable the History API, we have to start Backbone.history with pushState: true

enablePushState = true
 
pushState = !!(enablePushState && window.history && window.history.pushState)
 
if pushState
  Backbone.history.start
    pushState: true
    root: '/'
else
  Backbone.history.start
    pushState: false
    root: '/'

Before we do that though, we need to make sure the History API is supported by the browser. We check if window.history and window.history.pushState are available, then we start Backbone.history

If the History API is not supported, Backbone will fall back to using standard Hash based routing.

Clicks and external Navigation

One of the “gotchas” you’ll notice with Backbone.Router is that it doesn’t process link clicks or external navigation for you. You might be surprised when you’ve created a link you thought Backbone.Router would handle only to have it refresh the page and bypass all your hard work!

To fix that, we’ve added some code found on Stack Overflow to listen for any clicks that match our route root, and we pass that to our router:

  $(document).on "click", "a[href^='/']", (event) ->
    href = $(event.currentTarget).attr('href')
 
    # Check if the link matches our route
    passThrough = href.indexOf('/dash') != 0
 
    # Allow shift+click for new tabs, etc.
    if !passThrough && !event.altKey && !event.ctrlKey && !event.metaKey && !event.shiftKey
      event.preventDefault()
 
      # Remove leading slashes and hash bangs (backward compatablility)
      url = href.replace(/^\//,'').replace('\#\!\/','')
 
      # Instruct Backbone to trigger routing events
      window.Dashboard.router.navigate url, { trigger: true }
 
      return false

Server Side

A requirement for creating a single page app with deep linking capabilities is to configure your backend to process URLs that your client normally would handle. This lets you create a link to a specific part of your app and it will be properly served by your application server.

In our example, we’ve simply added a URL route in our Django application to serve our dashboard:

(r'^dash/?', dash_index_view)

Search Engines

One big thing that is missing from this dashboard is search engine visibility. Because all of the content is loaded by the client, a search engine will not see what the end user sees.

For our Dashboard that’s okay, since users must be authenticated to see it and the data is very private.  For your site, though, it might be really important. In that case, this article might be a good starting point for you.

Final Thoughts

Learning Backbone.Router has been an absolute pleasure. I’m still proud of how fast, responsive, and natural our Dashboard feels now. To top it off, the code is clean and easy to understand.

I also like that Backbone.Router fits nicely into an event driven application, though I did not utilize events as much as I should have in the new Dashboard.

I’d love your feedback on our approach to Backbone.Router. Are we using it correctly? Anything we might be missing? Built anything cool with it? We’d love for you to leave a comment!

Max

Hi, I'm Max, Co-founder of Codiqa, the easiest way to build jQuery Mobile prototypes. I'd love to talk with you: follow me!

More Posts