I'm trying something new today. Last week I had the pleasure of interviewing Luke Melia.. Luke heads up the NYC Ember.js meetup, he's the Co-Founder and CTO of Yapp and he's very involved with the Ember community.

If you don't already know I live in Reno, NV next to Lake Tahoe. We have a small but growing tech community. I did this interview to get some tips and ideas on how to build a community and find out a little more about Luke and Yapp.

I had a few technical problems after we did the interview, so I don't have the recording available yet. Although I might add it up later. This will be the first part of the interview. The second part will be up in a separate post here.


Erik: Hi Luke! Thanks for joining me today. Can you tell me about yourself and Yapp?

Luke:: Sure, So the company was founded as a product start up originally in 2011. It was started by myself and my business partner Maria Seidman. Maria is our CEO. I'm kinda of the tech half of the business while she's the business half of the business. We raised a little bit of money, a seed round, initially and launched a product. In those early days it was Maria and I, a designer Kris Selden and we managed to get a private beta shipped. Eventually we had some more folks join us Ray Cohen, Stefan Penner. I launched a public beta and it was around that time where we had a lot of excitement in the company and visibility in the press. There was early excitement from our users and we were also getting short in dollars in the bank. And so we started off solving a problem that most start ups in that situation do which is to raise an A. And we went a ways down that process and decided in the end to not pursue the term sheet for the A round for a few reasons that I won't get into. It left us in a spot where we were trying to figure out what we were going to do. By this point we were pretty involved in the Ember community core. We were using SproutCore to build out the very early product and so as a result of being in that world we were aware of SproutCore 2 which became Ember very early. And this started SproutCore 2 as the foundation of our mobile experience.

When it became Ember we contributed to the community and to the code base. So when this point came about we said wow you know we've been doing a lot in the community and helping a lot of people in New York. I bet that we could turn this into a business that can probably support the company for the foreseeable future. This was mostly Maria and I spending late nights trying to figure this out and way all our options and figure out what the path was. So we then decided that was the best path. Then we had to talk to the team and say hey this is what we are thinking are you on board or what do you think? And that was the moment, of course, a change in a company that could be the end of the team right? You know you guys are nuts and we are going to look for something else. But good fortune would have it everybody in the team was really excited about it and we've made a go of it and made it work really well. We are coming on 2 years now.

That model looks like right now is that we sell the product, we are still developing it's still growing slowly but it's growing. We are learning more about the market and what the product needs to be to succeed. We are working that product from an engineering perspective on Mondays and Tuesdays and Wednesdays, Thursdays and Fridays we do Ember consulting. And we do that for a variety of companies, big and small, start ups to enterprises. Our mission is to help teams be more successful with Ember. We come in even if it's one developer or an established team that needs to ramp up quickly. We come and sit down and we do pair programming, we do classroom style training if that's what's appropriate and we help just kinda spread our love and excitement for Ember. Teach people just not the concepts but the whys behind the concepts. So one of the benefits of being involved in the community for a while is you get to see the design process that went into a feature and so you can explain why things are setup the way they are setup. My experience goes a long way to kind of use the framework as it's intended instead fighting against it.

Erik: I really like what you guys are doing at Yapp. In fact I'm also a user of your mobile app.

Luke: Cool, Awesome

Erik: I used it for a New Years party I had at my house

Luke: Yeah we launched last fall a premium offering. What we found in the early days of the product was we had this vision that it was going to be millions of users like you, consumer level kind of users not businesses. Creating things for their everyday lives. What we found over time that it does happen but it doesn't happen at the scale we originally hoped. What we also found that there was a bunch of medium to small large size business that used the app for events that have budgets in the tens or hundreds of thousands of dollars. So you know offering them this product for free probably doesn't make a lot of sense for us as a business. So we introduced a premium offering with features that appeal to those audiences that they can subscribe to a annual bases.

We are trying to find the right prices but that's the current model. That's been good, it's been very a big step for the company and we still love the use case that you use the product for and we have a ton of education usage and we really love that. We want to see that continue. Teachers use it in their classrooms or to keep the parents of the class informed. Schools are using it for their activity calendars. So that usage pattern is due to a large part to the fact that it's very inexpensive to free. If we can we really want to really figure out a way to maintain that benefit to peoples lives while also making the product into a sustainable business.

Erik: Do you see any common issues when doing Ember consulting?

Luke: First of all I'll say that on the whole the quality of code that Ember developers new to Ember are writing is increasing over time. That the testament to the fact that the documentation is improving, the framework itself is improving a lot so there is fewer bugs that people are baffled by and have to work around in incorrect ways in many cases.

So I'll give you an example of that. In the early days of Ember development we use to run into Ember.run.next sprinkled all around code bases. And people could not figure why something wasn't set when they thought it would be set. We still see that from time to time but it's much fewer cases and I think that's a testament to the framework doing the right thing a greater percentage of the time you know. Another example I would say is that in the jQuery mindset of web development there is nothing wrong with grabbing DOM reference from anywhere you want anytime you want and doing anything you want with them. There is some developers that bring that habit over with them to Ember and that obviously can lead to issues and a loss of the nice encapsulation you get by default out of the box from Ember.

When your trying to refactor things in a code base where you don't know that you know if the controller or route might be reaching into the DOM to change something or get some information. That you are refactoring it can be kind of inexplicable why something should break when all you changed was a local template for example. So that's something that we see from time to time again it's more for people that came from the jQuery background.


We'll be posting more excerpts from this interview in a future post!

Link Credit To Luke Melia and Yapp

How To Build An Ember Community With Luke Melia Part 1