I was first introduced to development world by a friend doing a project for an art class he was taking. He had created a short little animation in Flash that totally blew me away. After that point I was hooked.
Fast forward 10 years. I’ve been working with the same team on various different products, the newest of which is Nanobox. Since we’re a relatively small team, I’ve had the opportunity to transition between many different roles. This has been a great opportunity for me to gain experience in all layers of the development stack.
Recently though, my focus has actually pulled me away from development into marketing, sales, and business strategy. I’ve really enjoyed my foray into the business and marketing side of things, since it’s something I’ve never really done before. It’s another great opportunity to round out my skillset and dive into an area that’s previously been a mystery to me.
The thing I enjoy most, however, is when I get to apply my development background into this new area of focus.
Due to the nature of our product, writing content for Nanobox is an interesting experience, to say the least. Nanobox is an orchestration layer that sits between an app and an underlying host (AWS, Azure, Google, etc). Basically it’s a DevOps automation tool that takes all the complexity out of configuring, deploying, and managing production infrastructure.
To write content for a product like this, it’s important to know a lot about many different languages, frameworks, hosts, processes… you get the idea. Although I’ve had many years as a developer, it’s still taxing trying to maintain an expert level of knowledge across so many different areas.
Our most recent marketing initiative was to create a series on “deploying X language/framework to Y host”. The prospect of creating the content and then copy/paste-ing it in all its different variations was daunting.
After discussing the details of the content, it occurred to me that the majority of it would be very similar, with only small pieces changing on a per framework/host basis. If we modularized the content, we would be able to pick and choose the pieces that were the same and sew them together with whatever unique content we needed. That’s when I had the idea for Stitch.
Actually… Stitch wasn’t the original name. Since the idea revolved around automating content marketing, specifically blog content, the first name we came up with was “blomit” (blog-vomit). And then we found this image, and it seemed like a perfect fit…
Ultimately I decided that if I wanted people to take it serious, I should come up with another name. That’s how Stitch was born.
The Real Stitch
The name obviously comes from the idea that you’re stitching together pieces of content to form a coherent whole.
Writing it was actually a lot of fun. I hadn’t had a chance to do any serious development for a few months, so it was great to get back into Go (which I’ve fallen in love with) and create it. Development is really where my true passion lies. While it was actually quite easy to write, and didn’t take much time, it was very enjoyable while it lasted.
Stitch isn’t going to work for everyone, since a lot of content won’t have the luxury of modularity. But when it works, it works really well. As I was writing it, I thought, “this will be pretty cool”. After I wrote tests for it I thought, “this turned out pretty cool”. The other developer marketer on the team who’s used it told it me it was really cool, but it wasn’t until I actually used it for the first time that I sat back, smiled, and said out loud, “Wow… this is really cool.”
I’m sure Stitch has tons of different use cases, some of which I haven’t even thought up yet.
Here’s How We Use It
We have a root level “content-modules” folder with all of our content that doesn’t really change (mainly Nanobox configuration stuff).
For each content “campaign” we do, we create a folder with an intro, outro, images, and its own set of content-modules. Here, for example, you can see our “how-to-deploy” campaign.
If you’re not a developer, don’t get scared off because Stitch is a command like tool (CLI). It’s very easy to use. You just specify, in order, the files you want Stitched together like this:
This will permute through each of the folders stitching the content together, generating dozens, hundreds, or even thousands of articles in an instant.
In The End
While writing Stitch was fun, and using is even more fun. The coolest part for me, was getting to write something that I felt improved an industry that I’m not traditionally a part of. Using skills that I’ve built up over the years as part of one focus and bringing them together into another, felt really cool.
Stitch doesn’t fully automate content marketing, there is still some work assuring content is unique enough to avoid duplicate content, and then uploading all the content, but it has reduced the workload of copy/pasting substantially.
I hope someone out there finds Stitch as useful as we have so far. It was fun to write, and is really fun to use! I’d love to hear from anyone who has a chance to use it. Let me know what you think! How did it work for you?