Find people you want to work with. If the thing is successful, you're in it for the long-haul. Better enjoy their company, otherwise it will be a long series of awkward silences.

Haha, I remember sitting in a meeting with the CEO of SurveyMonkey, where we worked while starting CodePen. He's showing us graphs of SurveyMonkey making millions and I'm sharing a graph of TWO PRO SIGNUPS in a single day with Alex.

Geez betty, this our first date. I think we should get to know one another first... :)

How about new user counts? You can't sell all your drama in your first book. You have to leave something for the second.

We don't have any planned features at the moment. But officially supported JavaScript is very high on our list. We'd love to hear what you have in mind.

If they are being implemented in browser, that's great for usage on CodePen, because it means we (and you) don't have to do any special processing to make them work.

As it stands, as far as I know, people are largely using Webpack for compiling that import syntax and we do support Babel/Webpack processing: blog.codepen.io/projects/using-babel-codepen-proj…

There are some amazing examples being created on CodePen as projects. Look at the examples here http://codepen.io/projects/. You'll find lots of inspiration.

I would take these steps:

1. Come up with an idea you want to see as a website. Anything that you'll be happy working on.
2. Write out the steps it'll take you to build the site with as much detail as possible.
3. Work on every step until you're satisfied it's complete.
4. Enjoy your success!

We're all on macs. Except Alex. He's on an ubuntu machine. So his bluetooth does not work.

If anything it would happen in the Project Editor. From what little I know, it requires .elm files, which doesn't really make sense in the Pen Editor. What would be awesome to see is a GitHub repo of a project that you'd like to be able to work with on CodePen.

We sure hope so. We're just getting started with CodePen Projects. What you see today is the foundation of Projects. We may not create an official CodePen CLI but if we created an API making an open source CLI would be very simple.

Probably.

Although "improvements" is subjective to any particular user. I'm definitely a fan of changes that are objectively better in some form. Better business. Users measurably completing goals. Easier code maintenance. Better performance. I'm happy to endure Twitter whining for objective wins.

I'll give my input only on what insights we've gleaned while running CodePen. Two things.

1. Find the minimum amount of process that works to coordinate your team and formalize it. We were pretty ad hoc when we added people to the team and it felt inefficient. We've come up with processes we follow when doing our work and it's helped how we communicate. Everyone understands how we decide what to do and when we do it. Add the fewest number of steps you can. Team happiness is still the most important thing.
2. There are great ideas and there are great ideas the team can accomplish. We hold back on adding features until we feel we can give them the love they deserve. For example we've wanted an API for a long time, so have our users but we've never had the time to support it. Five years in we can finally start discussing adding an API to CodePen.

Doesn't that seem like already the case? I can't imagine hiring someone, especially to work on the web, where you don't look around pretty widely and closely about who they are on the web. If I can see how you write words, how you write code, how you communicate with people, the stuff you produce... that's powerful. If that's out there and available for me to see, that's leg up on someone else where I can see nothing.

We haven't really considered that. Have you seen all the other layouts we offer for a Pen? Check out this screenshot .

This is a good example of a feature we could easily get sidetracked with. I'm not necessarily opposed to it, but as far as I know, this is the only time it's ever been asked for. As a tiny team we gotta pick what we work on carefully.

I think if we did something like this, it would be tied into a mini-sprint where we're focused on changing some editor UI stuff, and adding this isn't a weird detour. So: maybe!

Done. 💰

We launched CodePen in June 2012, and PRO plans in December 2012, so about 6 months.

Today, our revenue channels are mostly PRO plans, but sprinkled with our job board, advertising and sponsorship, and merch sales.

We've just started discussing an API. We've held back on supporting an API for a long time because we wanted to continue building out CodePen itself.

Now that we've built a lot of our favorite features supporting an API is very high on the list. I'd love to have it for some open source ideas I have. Really hoping we can start work on it soon.

There's probably more than I can even remember. The cheekiest ones are definitely math-related and built into the console.

Build something small with a backend language. When you succeed with that move onto a bigger challenge. Repeat until you're a full back end developer. If you code a frontend project you have the skills for many backend languages. I recommend Ruby. It's a sweet language.

Perhaps you've seen that CodePen Projects is out: http://codepen.io/pro/projects/

The release of that coincided with a major backend project, the rewrite our payment and signup system. Both of these were huge, long, demanding projects. For our own sake, we're going to be mixing it up with smaller, quicker-to-release stuff that we've been banking up and are sure people can use.

We're also trying to stay focused on "high impact" work. It's so easy to get sidetracked on a little project that ultimately has little impact on the business or our user base. We're right on the cusp of profitability and we want to get firmly into that territory by working on things that have the best chance of getting us there.

On a related note, we have a podcast were we talk about a lot of this behind-the-scenes stuff called CodePen Radio: https://blog.codepen.io/radio/