2015 Year in Review

This year I started working at EquityEats. Leading up to accepting the job, I did 40 interviews in a week, ultimately flying out to DC to meet the EquityEats founders and being convinced that it was the job I should take.

I held 2 different positions this year. I was officially brought on as the Vice President of Engineering to see how I would work out. I took over the small, rough codebase and began building out new features and upgrading old code. Working with the team was freeing compared to my other jobs since they were very early stage. There wasn’t much certainty defined in the business and like most startups, there was no hierarchy, so when I spoke my opinion I was listened to with interest and often got to influence decisions.

A few months later, Johann, the CEO, handed me a box full of business cards with my new title — Chief Technology Officer. It’s been my title for the remainder of this year and I’ve loved every minute of it. Our company is still early and small, but that’s what I love about it. We’re on this hunt to make opening restaurants more sustainable businesses for the places we all love to frequent so much. It’s not always easy, but it’s always exciting.

CTO

I’ve enjoyed the freedom to pick my own architecture and tech stack. I was lucky that the code I inherited was already in a decent place and used pretty modern technologies — Rails & MySQL on AWS. The front end of the website was very hacky (floats galore, etc.) and making any changes to the markup or design quickly became a pain. Although it was on AWS, it was on AWS’ PaaS product, Elastic Beanstalk. I wouldn’t recommend the product, largely because of how slow deployments were and difficult doing anything custom was on it. The infrastructure was also a simple Rails app with auto-scaling enabled, so when the site got popular and people visited the homepage, we were paying for another instance to run just for viewing traffic. Then when the traffic passed, AWS would always remove the EC2 instance we had behind a different ELB, causing other services to go down.

One of the first things I did was change the architecture from a full-stack Rails application to a Rails API + JavaScript single page application. The front end is in its own repo, using MithrilJS and gulp for development serving & building. The front end is hosted on Netlify (can’t recommend that team enough), which provides us with a global CDN with fast and consistent page load times, near perfect uptime, and low cost (we pay a flat $9 a month).

The Rails API is still hosted on AWS in a custom EC2 instance that allows us to easily manipulate things like system level cronjobs and sidekiq for background jobs. It’s up to us to make sure it doesn’t go down, but we’re using some best practices to monitor the instance’s resources and even if it does go down, users can still visit our website and browse static content. This also helps us pay and scale for actual application usage, rather than just users viewing our website.

Making the transition from a Rails full stack app to a Rails API + JavaScript single page app had a lot of challenges and took quite a bit of work, but it was definitely worth it in the end. At some point I hope to write a longer blog post about the challenges that we encountered and how we solved them.

Hiring

As CTO, I also got to hire people. It’s a weird thing evaluating someone else’s skills and deciding a major part of their life — what company they’ll join. The scariest part of it for me was making sure it was a good fit. As a first time CTO, it was hard to know that I was making the right decisions, but like most everything I do, I just jumped in, gave it my best, and just hoped to learn. I ended up hiring 2 people, a developer and a designer. Unfortunately, the developer didn’t stay with us through the year, but 50% success rate when hiring employees on my first go around isn’t too bad.

Our designer, Gustavo Esquinca, has been great. He’s an extremely creative artist with a solid understanding of web design patterns and implementations. The one thing I looked for when hiring a designer was someone that could not only come up with a wireframe, but could bring it to life through code. Gustavo’s solid HTML and CSS experience made him a perfect candidate, and he’s been a great learner picking up the JavaScript & Rails code I’ve thrown at him.

Splitting out our codebase to a back end and a front end has been helpful from a resource perspective as well since Gustavo can largely ignore everything in the Rails repo and just use gulp in the front end repo to do his developing and building, which is a tool he’s more familiar with since he’s a front end developer.

Also a weird note: my startup connections are all in Boulder, which is where I originally moved when I came to Colorado, so I tried to hire in Boulder, however I ended up hiring in Denver. We’re hiring another employee, who just happens to be in Denver, so we opened an office in a co-working space in Denver. Not sure if that says anything about the scenes in Boulder / Denver, but just thought it was unusual. I have noticed a trend of friends moving from Boulder to Denver as Boulder housing gets even more crazy and Denver’s scene for startups, food, and activities is growing steadily.

What did I do?

Besides splitting out our Rails API + JavaScript front end, I also built a custom ticketing website for our restaurant in DC, opened sourced the first Ruby client for SynapsePay (a startup making ACH easier to deal with that we used for a while to handle investment payments) and released a mobile app.

Ticketing Website

From a resourcing perspective, I fought hard to not have to build our own custom ticketing system and instead use something like EventBrite, but was ultimately overruled in favor of having a system that was custom to sit down restaurants. Ticketing is a hot trend in restaurants lately and there are very few companies supporting the trend, most notably Tock. We spoke with Tock a few times to see if we could use them, but unfortunately the timing just didn’t work out.

The hard part about building a ticketing system for a sit down restaurant, rather than a concert venue or some other type of event, is seating. Unlike a concert venue were you know that the venue can hold 50,000 seats, so you can sell 50,000 tickets, a sit down restaurant has the concept of tables. If you have a table of 4 and a party of 4 wants to book that table, life is simple. But what happens if a party of 3 wants to book that table? Do you let them? What about a table of 5? Usually you can move another chair onto the end of a 4 top table at a restaurant, but that’s not always the case. We marker boarded for a few days, talked a lot to the managers at the restaurant, and built something that is still in use today. There are always improvements to be made, but by in large, the system has served its purpose and done well.

Personally, the challenges of a sit down restaurant were interesting, but the opportunity to build another thing with real people using it and paying real money excited me. To date, it’s been the largest Stripe integration I’ve done, which is really exciting.

Synapse_Client

I owe a great deal to Ara Howard teaching me everything I know about programming in Ruby and building Ruby gems.

When I was tasked with figuring out a way to accept ACH payments online for investments, I researched a lot of different companies and ended up going with our only option at the time, SynapsePay. We were selling equity investments, which meant we couldn’t use credit cards and the other ACH companies didn’t want anything to do with equity investments online since it’s such a new concept. SynapsePay stepped up and was a great partner in getting that done, largely because they were just starting off too.

At the time, they didn’t have any client libraries, just their REST API, so I built the Ruby one and decided to open source it for them. Eventually they built official client libraries so my client is hardly used, but it was still a great exercise for myself in releasing Ruby gems and writing and running tests with guard and jenkins. I also took a lot of ideas from Stripe’s Ruby Client, so thanks to that project as well.

You can see the project on GitHub.

Mobile App

One of the things we launched at EquityEats this year was a mobile app exclusively for people who invest in a restaurant through our website. After the restaurant launches, the investors use our mobile app to manage their relationship with the restaurant, including checking in (the owner gets a text message notifying them), redeeming credit at the restaurant, giving private feedback to the owner, and more. The basis of our work is giving restaurant owners hundreds of local investors, who revolutionize the business by being the best customers. However, hundreds of people to keep track of can be daunting, so that’s where the mobile app comes in. It allows restaurant owners to keep investors in the loop and keep a good relationship so the restaurant and the investor can continue to help each other for years to come.

From a technical perspective, the app is a pin-to-homescreen web application built with MithrilJS. We went with this approach for several reasons and it’s been one of the best decisions we could have made. Here’s why we did it:

1. Code re-use. There are only 2 of us in the engineering department right now, so we need to use our resources wisely. I would have been a poor leader had I made us spend duplicate time re-writing code on multiple platforms.
2. Flexibility. The most important thing for our app is that investors can use it, however that means. With the app built as a web application that can be pinned to the home screen, our users can technically use the app on literally any device — desktop, tablet, or phone. From an OS perspective, we assumed that all of our investors had either Androids or iPhones, but it turns out one of our investors had a Windows phone. If we would have made completely native apps, then that person would have been out of luck. Instead, she was able to visit the app website and “Pin to Start” (windows phone lingo apparently) to be able to access her investor account.

We’ve always had plans to add native web view wrappers to the Google Play and iTunes stores, but we haven’t gotten around to it. For now, everyone is happy with our pin-to-homescreen solution since it can be used on a larger variety of devices. It also has more feeling of exclusivity, since you can’t find the app in any of the app stores. It’s an app exclusive to investors only, so you have to be told the website where you can download the application.

Separating the Rails website into a Rails API backend and a single page app front end was done with our mobile app in mind. Since we already had the API split out and set up to be consumed by any of our clients, the infrastructure set up for our mobile app was minimal. Created a new site on Netlify, set up SSL, and we were off to the races.

In the coming year, we’ll be making more improvements to the app, especially around investor updates from the restaurant to the investor, delivered via text message (and push notification when/if we publish native app wrappers).

Some stats

commits: 13,111
added loc: 270,059
removed loc: 87,412
total loc: 182,647

Weekend Hack Fun: AtomicKit

One of the ways I like to connect with friends and fellow startup developers and designers is by working together. Taking a short break from everything else in my life, I spent a weekend with a designer friend, Jesse Litton, building a fun weekend hack. Jesse runs a large Slack community for startup people in Colorado, called TechFriends, of which I am a member.

We were talking one evening over drinks about how the majority of members in a Slack community aren’t engaged. Slack’s form factor is that of instant messaging, meaning that if you’re not around when a conversation happens, you missed it. And if you don’t regularly check the transcripts in each and every channel in a large Slack community, odds are that you are missing out on some awesome conversation within the community.

As a result, we came up with the idea of a service that allows the people that are on the community 24/7 and are really passionate about the community’s activity to star messages and have those messages be emailed to everyone in the community as a summary of the best community dialogue from the day before. Slack is a tool geared towards workplaces, not communities, so there’s very little support for Slack communities built into the tool. We figured that if people liked the email summaries, we could offer additional services for Slack communities to thrive.

We couldn’t really come up with a clever name and Jesse felt like designing space ships, so we came up with a space theme and decided to call it AtomicSlack. After a quick review and email from Slack corporate, we had to change the name to AtomicKit. We launched on ProductHunt and got some great attention and feedback. Jesse & I both work full-time, so AtomicKit has been an interesting experiment to build let run for a while. It costs a few bucks a month to let run, so we’re watching as people use it and learning what Slack communities need next, so that when (if) we ever get some spare time, we’ll add some cool new features.

Blogging

One of my yearly resolutions is to write more. It’s something I enjoy but I often don’t allot enough time in my busy schedule to make it happen on a regular basis. Making writing a regular habit is something I’m always trying to make happen. Not only is it enjoyable, but it helps me re-examine the problems I’ve solved which gives me new perspective, and sometimes, new answers. It’s also a great way for me to connect with other startup developers out there.

Email Courses

In addition to blogging, I experiments with the ideas of email courses this year. Several people launched free email courses this year, most notably Brennan Dunn’s Free Pricing Course. It’s a way for writers to offer free content while getting an email address from a potential customer and training them to seek out and open emails from them. Automated drip email courses after a user subscribes to your newsletter has always been an effective marketing tool, but the standalone email course hasn’t been tried too often that I’m aware of.

I decided to give it a shot to experience writing one myself, so I wrote a free, 10-week email course that introduces coding and front-end web development to complete beginners. Actually, I outlined it all but have only written the first 6 weeks. Writing the course took a lot more energy and time than I originally thought it would. At first, it was easy for me to write 10 individual emails that covered the content that I wanted to cover and put them in an email format.

CovertKit vs MailChimp

I’m a big fan of Nathan Barry, especially his book Authority, where he shows people how to write to teach skills. A while back, Nathan took a break from writing and decided to take one of the marketing techniques that had worked so well for him and make it into a SaaS product. He launched ConvertKit, which is an email marketing service, similar to MailChimp, but is specifically geared towards “professional bloggers”. I decided to give it a shot for my newsletter and email course since I’m a fan.

At first I was very skeptical of ConvertKit, largely because of the price. It’s 3x the price of MailChimp at $29 a month, but since I’m a fan of Nathan’s and appreciate the importance of using skills designed specifically for niches rather than a larger audience, I decided to forge ahead. The nicest features of ConvertKit that I experienced were the pre-designed forms that were easy to drop into the website (MailChimp’s are either hosted by MailChimp or super plain that require you to style them) and the automated analytics, specifically around how many people converted to subscribing to my newsletter when shown the form. The conversion stats is something that can be set up in Google Analytics pretty easily (if you know how and where to look), but it’s nice to have it automatically done.

Unfortunately, the rest of the tools around sending email to a list aren’t quite there yet. Building emails in ConvertKit doesn’t provide much help in the way of style and layout (which, as someone who has built some responsive emails, is a major benefit of an email tool like MailChimp). The other disappointing thing was that the user interface and experience around who is actually going to get an automated email (either as part of a course or an automated reply) isn’t clear. MailChimp has a nice feature in Automation that shows you how many people are about to get each email, so that you can make sure your list is configured correctly to send to the right people. With ConvertKit, I had to hope that everything was going as it should. When I added the complexity of having a main newsletter plus a separate course, it got really confusing.

Ultimately I decided that ConvertKit was a noble idea, and one that I hope succeeds some time in the future, but wasn’t ready for me just yet. I switched back to MailChimp.

Organizing Boulder Startup Week

This year I also volunteered by organizing the development track for Boulder Startup Week. Boulder has a great, thriving startup scene, which was proven, yet again, to me when I was tasked with putting together the developer sessions for the week. I thought about some high-level topics that we could make the focus of the sessions and sought speakers to speak at them. Getting speakers was pretty easy as everyone in the community is generous with their time. All of the speakers did a great job and we received lots of compliments about the quality of the developer events. I also had to organize the where and when the events would take space, for which I leaned heavily on Andrew Hyde and the rest of the BSW team, who was incredibly fun and valuable to be around. I’m excited to be around that group and help in the future.

I also got to speak at 2 of the events that I hosted during Boulder Startup Week. I enjoyed it and I got a few compliments, so I think it well. Speaking more is something I’d like to do more of in the coming year as well.

Organizing ExecBoulder

While I was putting together the development track for Boulder Startup Week, I made a new friend in Kevin Owocki. At the time Kevin was the VP of Engineering at Simple Energy and had built the engineering team from a handful to a few dozen. Since I was early on in my new role of leading a development team, I got a lot of good advice from him about engineering leadership. One night over drinks with other BSW people, I asked him if there was any group he knew of where other engineering leaders could hang out and learn from each other. He couldn’t think of any, so we decided to start our own.

We called it “Exec” (nerd humor, ha) and started invited people we knew and now the group is up to over 20 startup VPs of Engineering & CTOs. Once a month, we meet for lunch in Boulder and just talk. There’s no formal agenda, no pitching aloud, and no discussion leaving the group. Kevin & I have always wanted to just make a comfortable hour once a month of learning from other engineering leaders in our community and nothing more.

We recently just got introduced to some Denver startup CTOs, who are starting their own informal small group, so maybe our groups will cross-invite and spread the experience even more. I’m excited about that possibility and how warmly everyone has received the group.

Travel

• Washington, D.C. (7x)
• Dallas, TX (3x)
• Nashville, TN (2x)
• St. Louis, MO
• Little Rock, AR
• Fort Lauderdale, FL
• Cedar Falls, IA
• Fayetteville, AR

Next Year’s Goals

Next year will be another fun year full of new adventures, travel, and friends.

I already have a few trips on the horizon, including Cancun, Alaska, and NYC, but my goals will be simply:

1. Scale EquityEats (we’ve found our product-market fit this year, so next year will be all about scaling the product and the team)
2. Write at least once a week
3. Speak at least 6 times

How did your 2015 go?