Re. #1: Good question :) The day-to-day is pretty relaxed. Skylar and I meet every Monday morning to catch up on the latest stuff: what we’re working on, what client work is in the pipeline, and what needs done to get to where we want to be—whether that’s launching a new feature or something a bit more long-term. Outside of the Monday morning catch up, we don’t really have any other meetings unless we’re meeting with a client. Most of the back-and-forth between the team is through Slack, and we have a channel for each product and client to keep things organized. Most of the stuff we know we need to do is a GitHub issue in the corresponding project’s repo and we try to use GitHub’s Milestone feature to group the issues by priority. This setup isn't perfect but it works okay for a small team like ours.

One thing that we do with Dropmark that pushes us to keep things moving forward is a monthly email that we send out. This was partially inspired by something Nathan Kontny wrote about doing when he took over Highrise from 37Signals:

On day one, I established a train schedule – we'd make major announcements on a regular basis. If something isn't ready, it misses the train. But an announcement is going out; something better be on it.

We started doing a similar thing at the beginning of the year, and at the end of every month we send out an email — most months we’ve had a new feature or improvement that we’ve been able to announce.

Re: #2 It’s definitely tricky to balance self-initiated projects with client projects, especially in the beginning of your company/project. Consulting brings in money (and can pay really well!), and self-initiated projects usually just cost money (and getting paying customers is hard!). From the start we mostly just worked on our own products in downtime between clients, which resulted in a very sporadic schedule. It really helps to be passionate about the self-initiated project, and that drives you to find the time in whatever small ways you can.

We’ve also experimented with different ways of building our own products. With Symbolset, for example, Mike and I slowly poked around with ideas for nearly a year before we actually launched something.

Gazette on the other hand, was built in one crazy week. Myself, Sawyer, and Larry spent a weekend hacking together some code and polished it throughout the week. When we launched it wasn’t even fully functional yet (except for the sign up form), but we knew we had 7 days to complete and ship the first issue. We made the deadline, slightly stressful but super fun. Even though Gazette is no longer around, it was a great learning experience (pro tip: if you build a product, charge more than $1.99/mo if you want it to be sustainable).

Re: #3 I wish we could say we have a secret formula for this, but really just involves experimentation and determination. Not everything we’ve tried has been a success, but typically everything we do is built with a purpose in mind and one that scratches an itch. We feel like if it's something we’d use, others may feel the same way. Even if it's not, just having the thing exist for yourself (or one client) may be “real” enough to start. We actually had 2 working versions of Siteleaf for years prior to the v1 public launch. Nowhere near as polished as it is now, but all along the way we had clients using it. So it served a purpose (we didn’t have to use Wordpress!) and was the “real deal” to at least some people.

Re. #4: We really focused on building a CMS that developers would love to build for and that everyone would love to use.

So some things developers will love is:

• Full compatibility with Jekyll — it’s open source, you can run it offline, and it’s the same thing GitHub Pages uses to power over half a million sites.
• GitHub Sync, which keeps your source files locally, in GitHub, and in Siteleaf all in sync. When you make an edit in Siteleaf or push a local change to GitHub, everything syncs which gives you a time machine for your content.
• A full API that developers can use to manage their content. Hell, you could create your own CMS using just our API. (The Siteleaf Admin uses the same API endpoints). I’m using the API personally to export my Kindle and iBooks highlights online.

From the client or content manager side: I’m a bit biased but I think we’ve built and designed a pretty kickass admin interface for you to manage your site in.

Re. #5 for me:

I’m obsessed with usesthis.com — it’s super interesting to me to see what other software developers are using in their practice, but also what scientists, chefs, and musicans are using. The site even has an API.

I also have to mention Kevin Kelly’s new book, “The Inevitable”. You gotta read it.

Hey David, thanks for showing up early to the party!

We have a bunch of stuff on our Siteleaf roadmap, partially dictated by Jekyll’s roadmap which is kinda nice. Awesome features trickle down to us like Gem-based Themes, we’re really excited about this one!

Besides what’s in the Jekyll pipeline, our plan is to continue building out and improving the UI to make it even more client friendly with more Jekyll coverage (editable defaults, data files, etc), third-party gem support, and possibly some add-on features which extend beyond Jekyll's functionality. Stay tuned!

Would love to hear if you have any specific feature requests too :)

Glad you liked it! We made the video ourselves, using an app I love called ScreenFlow.

Sawyer found the song in the Vimeo Music Store, which was great because I probably would have picked something weird (see: v1 video).

For the video content, I just recorded my screen going through the motions of using the app and pieced it all together using ScreenFlow’s built in editor (it’s a lot like old school iMovie, in the best way).

We do our tutorial videos in the same way: https://vimeo.com/siteleaf

That’s a tough one. I’ve always dabbled between both worlds, mostly out of necessity. I’m an impatient person, so waiting on someone to help me develop or design something hasn’t ever been attractive. When you’re on a small team like we are, you don’t always have the benefit of a dedicated team of developers or designers to work alongside, so you’re forced to adapt and learn new skills in order to get things done. With that said, it’s always helpful to be surrounded by people you can bounce a question off of or get their opinion when you hit a wall.

Regarding staying fresh and adept: I think deliberate practice through side projects and experiments help a lot with this. For me, most of my day-to-day work is on large monolithic code bases where what you can do is dictated by decisions made a year or so ago, like your build system, framework, or style guide. This isn’t always the easiest environment to try cutting edge stuff, because that stuff wasn’t around when the big decisions were made a year ago. I usually have a ton of ideas for side projects and use those as an opportunity to take a first crack at trying a new library (like React), app (like Sketch), or service (like AWS Lambda). Eventually I can apply those lessons when we work on a new version of a project, refactor, or start something from scratch.

Would I recommend it? Definitely, if that’s something you’re interested in. To use some buzzwords: It’s great career capital and widens the adjacent (1) possible (2).

Hey Justin, thanks for the kind words! Glad we were able to allow you to ditch Wordpress, and join the static web party. It’s fun over here :)

Also glad you’re still using Pizza Compass. Still blows our mind how much press that got at launch. Kind of a bummer when publications like Los Angeles Times are excited to write about your joke app instead of your legit products :P

Fun fact: For at least a brief moment, we were able to beat Angry Birds in the App Store paid app charts. That was a huge achievement we’re still proud of to this day.

Another fun fact: When the Apple Watch first came out, I was determined to get Pizza Compass up and running (could you imagine!?). Actually got pretty far before realizing that the watch doesn’t have a compass. Oops!