Repurposing the Titanic

My biggest mistake with Glassboard was having blinders to the fact that the design decisions Sepia Labs made when building Glassboard would likely clash with mine. That doesn’t have anything to do with visual design. Instead, I’m referring to the platform architecture decisions they made as a funded startup, or spin-off, or whatever they were.

The folks at Sepia had a parent company in Newsgator that was funding everything on Glassboard from the server costs, their salaries, and all the perks that go with that. More importantly, they were funding these things with the typical startup mentality in mind: get as many users as humanly possible and then worry about monetization later.

Glassboard under Second Gear had a completely different mindset: try to convert our most passionate existing users to paid users, and then grow from that. I sadly failed at doing that. There are a variety of different reasons for that failure, but one of them is how much time I spent undoing some architectural decisions from their previous owner.

That’s not a knock against Sepia or NewsGator. They built a great product. They just built it with a far different set of constraints than I had as the new owner funding this out of pocket.


One of the biggest was e-mail. Glassboard was sending over 150,000 emails a day when I took over. The SendGrid bill was $2400 in November of 2013, which is kind of crazy. I was able to cut that bill in half by negotiating a better rate to account for how much email we send, but it was still four figures a month.

Sepia didn’t need to worry about justifying that cost because it was another feature in the checkbox to try and acquire users. Don’t want to use an app and get push notifications? We’ll send you an email every single time someone comments on your board posts!

E-mail to Second Gear’s Glassboard is, however, a sunken cost because none of those costs were ever passed on to my customers. My thinking at the time was that I could convert enough users to premium accounts to fund the transactional email for everyone. In reality, that proved to not be the case.

I spent far too long in that mindset. When I finally wised up and made transactional email a premium user feature, my costs dropped down to under $100 a month. It also pissed off more users than it converted, but that was to be expected. The lesson I learned is that people wanted those emails, but they didn’t want to pay for them. It was a nice-to-have thing, but not a must have. I wish I had learned that lesson $15,000 ago.

Computing Costs

The biggest project I undertook during my time with Glassboard was converting the entire backend to use computing resources more efficiently. There were three different cloud services that powered Glassboard:

I was able to get a few quick wins by enabling auto-scaling so that the instances would rise and fall based on usage patterns. It’s silly to pay for a ton of servers at 3AM on a Sunday when there’s not nearly enough users to justify the costs.

The biggest issue is that the only way to scale Glassboard in that incarnation was to throw more hardware at it. I spent an ungodly amount of time converting the entire backend platform to use C#’s async-await pattern. I am fairly confident I touched every single file in the project. One does not merely convert one portion of their code to be asynchronous. It’s a rabbit hole that you keep going down until you reach the bottom.

It was a lot of work, but once it was deployed I cut my server costs across the board in half.

Of course, by the time I got to that point, it was too late. I cut costs on a product that wasn’t commercially viable. Oops!

Lessons Learned

Building products with a bootstrapped mentality is completely different than a startup mentality. When bootstrapped, every decision you make affects the bottom line, and that is a bottom line you care about from day one. Trying to convert a platform that wasn’t designed with that in mind proved to be too great of a challenge for me as the sole proprietor of Glassboard. Rather than focusing on improving the core Glassboard product, I spent most of my time trying to cut costs where possible to curb our losses.

Would it have been more feasible if I had some help? Most likely, but I still don’t think that would have saved the platform.

If I had a do-over, I think my first decision would have been to shut down the Glassboard service as it was in November of 2013 and relaunch it without any of the legacy user accounts or data. If you wanted to continue using the service under Second Gear, subscribe now. That would have lowered costs up front and allowed me a lot more runway and likely time to delay a lot of cost-cutting projects that took up most of my 2014. Of course, there’s obvious tradeoffs in this decision too.

Hindsight is a bitch.

What Problem Are You Solving?

The worst day I had in my time with Glassboard came last month. It was becoming obvious that even with the latest round of changes to the business model and pricing schemes, things weren’t turning around as well as I had hoped. I had no beliefs that new pricing would be a magic bullet to solve all of the platform’s problems, but I did think it’d be more successful converting users than it was.

In reality what happened is that rather than paying a small monthly or annual fee to continue using Glassboard as they were, more people opted to find another free alternative to move their group or business whether it be Slack, Google+ (lol really), or any of the 85,000 other alternatives on the market.

Couple this with me having a pretty big crisis with a botched migration to a new push platform, and things weren’t going really well for me. This was the point I started to think about where to take Glassboard next. Rather than keep all those discussions internal to my brain, I emailed a variety of different people ranging from friends, colleagues, users, and other business owners. This is the email I sent them:

Have come to the realization that running Glassboard in its current state is not tenable financially, mentally, or physically.

A lot of different problems with it as a product and not sure how to solve that. Mostly it feels like a niche product without a well defined audience.

Any ideas on how to figure that stuff out or where to go with it? Trying to get a bunch of different opinions, because I’m honestly not sure what to do.

Most everyone responded back, and not much of the feedback was good in the “your platform is great! Keep going!” sense. Most people were scratching their heads just as much as I was about where to take this thing next.

The best response I got fairly direct: who is the audience for your Glassboard and what problem do you solve for them?

I didn’t have a good answer for either of those questions. Shit.

Finding An Audience

If the answer to “who is your product’s audience” is “anyone with an iPhone or Android device” you are likely screwed. One of the biggest things I have learned from the entire Glassboard experience is that ‘spray and pray’ audience targeting is something that isn’t likely to work. Glassboard’s marketing message has always been fairly generic from both its time as a Sepia Labs product and under my helm. The last marketing message was “Talk to your people”, with people being a pretty generic term meaning it could work for personal or corporate communications.

There are very few collaboration products on the market that work well for both of those markets.

I spent a good amount of time over the last few weeks looking at analytics data to try to understand who was currently paying for the service and trying to analyze each of the markets that was being served by Glassboard currently. I analyzed them by three different metrics:

My potential markets based on analytics and user interviews were families, small businesses (think Q Branch), medium-sized businesses (think OmniGroup), conferences, consumer ad hoc groups (a book club), and professional ad hoc groups (a beta test board or a cocoaheads meetup).

Analysis said I should focus my efforts towards the professional ad hoc groups and medium sized businesses because they had a large audience, were likely to pay if Glassboard could solve an actual problem for them, and there weren’t too many gatekeepers preventing me access to marketing at them.

Solving A Painful Problem

The key to selling a product to a user (whether it be a consumer, business, or enterprise) is to offer a solution to a problem they are having. If you can make that problem less painful, people are willing to pay for it. For instance, an app like OmniOutliner is successful because it’s far easier to create complex outlines in it across platforms than it is using just plain text files. TextExpander makes good money because they help power users save keystrokes by automating repeatable strings of text.

Glassboard? Well, I realized that Glassboard wasn’t really targeted at any specific group and it didn’t really solve any real sort of problem.

Here are a few different ways I tried to explain the problems Glassboard solved:

  1. It allows anyone with an iPhone or Android to communicate securely and privately.
  2. It allows users to have threaded conversations rather than IRC-style chat lines.
  3. It allows conference attendees to communicate with each other from their mobile devices.

None of these are real painful problems. You can likely name a variety of different apps that can solve #1 and #3. Threaded communications is nice, but it’s also proven to be far too niche and not really something people are willing to pay for.

I realized that Glassboard in its current form is for all intents just yet another chat platform for iOS and Android. Yeah it had an audience, but not an audience that was willing to pay for it to stay around. It didn’t solve an actual problem better than any of the free alternatives out there, so people left rather than keeping the lights on.

What Did We Learn?

What lesson can you take from my failures? Take a look at your current product and ask yourself what problem it is solving that makes it stand out from the competition. Also, ask who has that problem and if you are reaching them as well as you could.

If you are in a situation like me where you don’t have a good answer for either of those questions, you need to sit down and start answering some hard questions about where you take things next.

In my case, the risks of shifting Glassboard towards where I thought it should go next were too high for me to take on. Every business and product is different. Hopefully you learn from my mistakes and can make an excellent (and successful) product.

The Gamble

Last week I announced that Glassboard will be going out of business as of November 1, because I was unable to turn it into a profitable business. There are a lot of different things I want to cover eventually about the past year I’ve spent working on this thing. For one, it’s therapeutic to me to get it out of my head. Second, my hope is that people can learn something from my successes (yes, there were some) and failures (those too).

I knew going in that Glassboard was a moonshot. I was in essence taking over a platform that was run by six people with stable salaries from a parent company and doing it by myself, while trying to shift what turned out to be the titanic away from the iceberg.

Running any business, large or small, is mostly about managing risk. You want to invest in the things that will grow profits. Startup culture skews this in our industry, because venture capitalists are willing to assume near-term losses in favor of potential long-term riches, but for our purposes, let’s assume we are building a business like our parents made. The goal is to spend less than you are bringing in.

I am a terrible Blackjack player, but I know enough to be able to play on a few hundred bucks and have some fun. If you’re under 12, you want to take another card, because you’re really not going to hurt yourself. If you’re over 12, you’ve got to start figuring out what cards have been dealt already from the deck and determine if its worth the risk of possibly busting or not getting a high enough count to beat the dealer.

Despite being terrible at Blackjack, I play it fairly conservatively and don’t stray from those two rules too often. I try to run my businesses in the same way. Second Gear and Glassboard have always been small shops that are run with the intent of supporting me and if it grows beyond that, great.

I knew the risk of taking on Glassboard up front would be how much money it was losing each month in sunken hosting costs (not including development and design time). I projected a few different scenarios for good, great, and ‘make it rain’ levels of growth to get the business out of the red and towards profitability.

Despite cutting the monthly losses by 80% from the time I took over to today, I never fully got to that break even point and began to realize that getting there and beyond was going to require a lot more hard decisions and evaluation.

So, how do you know when you’re done and it’s time to fold? When you start thinking about shutting things down, you’re done. There may be a Hail Mary out there that could possibly save the sinking ship, but my guess is that it will only prolong the inevitable.

For me, I knew for sure last Thursday that I was done. I realized it was going to be another $60,000 or so to turn Glassboard into the product that I thought it could be eventually. There was no way I could do that emotionally, mentally, or financially. The risk was too big. I announced the next day I was cutting my losses and shutting the service down.

Glassboard was a gamble that didn’t really pay off financially (no, mom. I am not losing the house), but it was still rewarding in a lot of other ways. Hopefully those will become apparent over the next few weeks as I dump all this out of my head.

Going Against the Grain

By now you may have heard that, the upstart social network/platform/data layer, is entering maintenance mode after the company laid off their team when renewals weren’t as high as they’d hoped.

I’ve been a founding member of the ADN movement since 2012 and have renewed each of my developer accounts without much hestitation. I’m abnormal however. I prefer paying for my products rather than being advertised to, want to pay higher air fares for better service, and prefer dot syntax to brackets when writing Objective-C.

Running a niche social platform such as is harder than I think most people realize. I gained a whole new respect for ADN after taking on Glassboard, a service that shares many similarities beyond just being “social”.

Social services like Instagram, Twitter, and Facebook succeed because they are designed to reach the highest amount of people with the least amount of friction. The easiest way to remove friction for users is to make the product free and then figure out monetization down the road when you’ve (hopefully) gained a ton of users. Instagram and Facebook seem to be excelling at this. I can’t remember if Twitter is succeeding or miserably failing this week. Anyway, the point is that gaining a high amount of users by making your product free is enticing if you can afford to.

Right there, and Glassboard are at a disadvantage by being “freemium” rather than full-on free. Consumers have been trained by Facebook, Twitter and Pied Piper to not pay for the services they use. To combat this, we try to offer enough value for the free account to get people using the service, but not so much that they won’t pay.

With, accounts were limited by the amount of people you could follow on your timeline as well as storage for any files or media you wanted to put on the service. Glassboard limits the amount of boards you can create or the amount of storage you can upload.

I’d argue that neither are successful. I don’t know’s numbers, but I know Glassboard’s. Glassboard has been losing money its entire life. Last month it lost $1200. The month before it lost about $1500. The amount of premium subscriptions we convert is far too low to consider the product anywhere near a success. I knew this going into the acquisition, and have been working on changing that going forward, but pivoting a product used by tens of thousands of users daily is more like turning the Titanic than a speed boat.

I have one advantage where I have never had employees with Glassboard, my payroll is pretty affordable as a party of 1, but it still doesn’t take away the fact that losing money is not the goal of any business, especially a bootstrapped one.

Finding An Audience

Even with an amazing business model, it’s just paper without an audience however. When you’re running a paid social platform, you’re looking for niches. Sure, you dream of having Twitter or Facebook user numbers, but the reality is that when your goal is to be funded directly by your users, you’re only getting a fraction of those numbers.

My ADN stream was populated with iOS developers and Bronies. I’m sure Dalton or Bryan could list a few other groups that are popular on ADN. Glassboard has become fairly popular with gamers who organize their clans on the service in addition to small businesses and families who want a private way to communicate.

I call this finding a niche. Silicon Valley calls this product-market fit. Finding an audience of people interested in your platform is challenging. This isn’t Field of Dreams where if you build it people will magically appear. Once you find that niche of users, you’ve got to ensure they’re also the type of folks that are willing to pay to support your platform. If they aren’t, you keep looking for a niche that will sustain your product.

I have a few niches with Glassboard, but based on the numbers I shared above, they aren’t profitable niches. I’m hoping that can change as I change the product’s business model and pricing in the near future, but I won’t know for sure until I actually ship the code.


The other thing going against ADN and Glassboard is stigma. So many people in my circle have said to me “oh, the conference app?” when I mention Glassboard. They see the product as something they install when they go to WWDC, 360iDev, or CocoaConf and not a part of their daily usage. Nevermind that people are using the product for a variety of different things outside of attending conferences, it will always be the conference app.

For ADN, I believe that stigma is the “Twitter service that isn’t Twitter”. Nevermind that ADN tried to build more than a Twitter platform with their backer program, messaging platform, and authentication layer. Most people saw ADN for Alpha, the Twitter clone they shipped as part of their original funding model.

Getting over a stigma is difficult, and I’m still trying to figure out how to do that with Glassboard, but I do believe that contributed to ADN’s lack of success. That stigma likely contributed to people questioning whether it was worth paying another $35 a year to “tweet” somewhere else.

What’s Next

I’m willing to guess that most of the folks reading this post are the types that are willing to pay for the products they use. Unfortunately, you and I are a minority compared to the rest of the Internet using public. ADN’s fight may be in maintenance mode, but I’m still pushing forward with my moonshot of turning Glassboard into a profitable endeavour.

People may write off ADN as a failed experiment and maybe it technically is, but it was always a risky proposition. They always were going against the grain and seemed like a longshot to succeed. We need more people to take risks like that.

It’s still too early to tell if Glassboard is going to be a financial success or failure. There’s nights that I go to bed questioning everything I’ve done this year. This is the life you choose if you go against the grain and building a platform that isn’t just another ad-based clone funded by venture capitalists.

Back to work.


tl;dr — Photos+ has a new home at Silver Pine Software. Elements has been discontinued due to lack of sales and so I can focus on Glassboard.

When I decided to take over Glassboard, I knew I was at the time biting off more than I could chew as a sole developer. Balancing a product that has three front-end clients, an API server, and tens of thousands of users while also working almost full-time as an iOS and Android contractor isn’t easy. Add on top of that, my existing suite of products and it’s a bit insane.

One of the things I said I would do when I decided to take on this adventure was to simplify and focus my work. I’ve always had a bit of ADD, which is why my suite of apps has ranged from text editors to GitHub clients to photo galleries.

In late 2013, none of these apps were necessarily setting the world on fire financially, but they had users that I wanted to try and do right by. I have spent the past several months working on finding new homes for each of them.


We announced that The Magical Panda acquired Committed a few months ago. Since the acquisition, Saul and friends have been hard at work squashing bugs and adding new features such as 2-factor authentication support for a more secure GitHub login experience.


As of today, Silver Pine Software is the new home for Photos+, the pro’s photo browsing app I released back in December of last year. Photos+ is an app I always wanted personally. I had a pretty large roadmap for where I wanted to take Photos+ in terms of functionality, but being able to realize that feature set and work on Glassboard simultaneously is nearly impossible.

I handed Silver Pine my roadmap as a source of feedback on where I think they should take the product, but it’s totally theirs to do as they see fit. I am happy, however, that their 1.1 release includes support for browsing your Dropbox photo library: by far the biggest thing I wanted to add from day one.


I was unable to secure a buyer for Elements unfortunately, so it has been discontinued. Sales of Elements have not been more than lunch money and enough to cover paying my support minions for almost a year.

As much as I enjoyed working on it, the market for a paid Dropbox text editor has passed. It’s become too saturated and too mature to reasonably think you can make a decent living from it.

To the Elements fans still using the app, my apologies, but I’m a firm believer in not keeping an app around to rot over time. The good news is that there are dozens of great competitors out there you can choose from.

Focusing On Glassboard

This is it. I’m all in on Glassboard. I don’t have any other products to fall back on or bring in supplemental income.

Google is big on talking about taking moonshots with their self-driving cars, Glass, and terrifying life like robots. These are big ideas, but I wouldn’t say they are moonshots because the company is still almost entirely funded by their insane ad revenue. If self-driving cars or evil robots don’t pan out, they’re going to be fine.

I’m taking a moonshot. Glassboard is a giant undertaking and the biggest risk of my career. It’s a make or break decision that will likely shape the next decade of my career.

I’m working full-time right now to try and launch the first piece of my Glassboard overhaul this summer. At that point, I’ll start to have a pretty good idea whether this was a good idea, or whether I’m going to be heading to the local McDonalds looking for a job.

Wish me luck.

Refactoring in the Cloud - Notifications

One of the things I have been thinking about a lot recently is the architecture of Glassboard. Now that I have everything mapped out for where I want to take Glassboard’s direction going forward both financially and functionally, it’s the time to look at how to actually build that functionality into the existing code base.

The Current Glassboard Architecture

Glassboard’s backend is powered by Microsoft Azure. In terms of computing, there are three main components: two worker roles and one web role.

Azure defines a Web Role as a server that has a running copy of the IIS web server on it, so that users can connect to it. A worker role doesn’t run IIS, but is still a Windows Server instance that you can use to do things like background processing on it and offload some of the heavy activities from your main server role.

This is a rudimentary diagram of the Glassboard architecture as of April 2014.

Glassboard's Architecture

Everything in the current Glassboard architecture is housed in a single Visual Studio solution with about 36 C# projects in it. It’s a lot of code to manage. Luckily it’s also well tested, which makes it easier to manage.

Current Notification Role Issues

There are a few technical and ideological issues I have with the current notification architecture.

To send messages between the web role and the attachment processor and notifications roles, I use Azure’s Storage Queue mechanism to pass messages. When you post a message to one of your boards, the web role generates a new XML payload in one of our storage queues that the Notification Role listens for to handle the processing.

Sometimes this queue and the processing gets extremely backed up. Usually the CPU usage spikes to around 90% or higher for long periods of times which can lead to message postings being delayed for several minutes (in some cases I’ve seen hours) at a time. This is no good, especially when building a messaging service.

I’m not sure what the cause is for the spiking CPU other than a lot of delicate C# threading issues which I’m guessing are running amok.

The other issue I have with the notification role is how much of the code for things push notification services is in-house built. At the time Glassboard was originally built a few years ago, there weren’t too many open source solutions for handling push in C# I’d imagine.

I’m fairly conservative when it comes to third-party dependencies, but for things like push notification services there’s not much sense in maintaining your own code library to connect to the service when there are a few good solutions out there used by hundreds (thousands?) of startups and businesses around the world. They’re well implemented, battle tested, and code that is maintained by the community.

Being on C#, that limits the amount of options I have for dealing with push providers. PushSharp seems to be the main provider out there.

The New Notifications Role

Given that I’m not a fan of the C# threading model currently implemented, the amount of code used to power something that’s relatively simple, and the homegrown nature of many of the push wrappers we’re using, I made the decision to rewrite this portion of Glassboard’s architecture using Node. Hang on. Put those Buzzword Bingo cards away. I’m not a fan of rewriting for the sake of rewriting either.

Ultimately, my decision to switch to Node is all about code management. I’m confident I can accomplish the goals of my notification roles with a lot less code using Node than C# thanks to it being a bit less verbose of a language and a variety of NPM packages I can take advantage of for handling APNS, SendGrid, and GCM. The less code I have to manage and maintain, the easier my job is as the sole developer of Glassboard.

I don’t believe I will have any performance degradation in switching from C# to Node for this portion of the code either, though it’s hard to tell before actually writing the code. If anything, I’m optimistic that performance will improve.

A Fork In The Road

There’s two different ways I can approach handling push notifications being distributed through my new worker role. The first is to use these npm packages like node-gcm and its similar ilk to distribute the messages myself like I have always done. The difference being mostly in the language being used (Javascript versus C#).

The other option is to take advantage of Azure’s Notification Hubs which will handle distributing the messages to devices for me. Notification Hub has some advantages that stand out to me:

This all sounds great. Why not just do this? Cost.

Notification Hubs are another cost layer on top of the existing charges I’m paying Microsoft for my cloud instances and storage. I’m still in ‘losing money’ mode with Glassboard, so I’m trying to be fairly conservative with my spending.

Glassboard currently sends around 150,000 emails a day according to Sendgrid, but I have no idea how many push messages it sends because it has never had a way to track that sort of information. If I opt into Notifications Hub, I’m likely going to be out at least $200 extra a month, but that could also sky rocket to an even higher amount.

Now you understand why I am giving so much important to data and analytics these days.

My gut says use Notification Hubs. My wallet says roll my own.

Service Bus vs Storage Queues

One last thing I’m still debating is whether to keep using Azure’s Storage Queues for managing the messaging between the different components in my cloud stack or to use the new-to-me Service Bus functionality, which looks to offer a few more features. The Notification Hub functionality Microsoft offers is powered by the Service Bus, which has me considering the switch.

There are plenty of decent articles out there comparing Service Bus vs Storage Queues, but from a more abstracted level that leaves me still questioning which way to go. The conservative developer in me says keep using what I’ve already got because no major Service Bus feature stands out to me as a must-have right now. The liberal developer in me sees Service Bus as the more modern architecture that will likely be able to grow with me as Glassboard (hopefully) expands in years to come.

Feedback certainly welcomed.

Writing The Code

Even though the core architecture of two worker roles and a single web role won’t change with this refactoring of Glassboard’s notification architecture, hopefully this has been at least a little eye opening in terms of how Glassboard is built, and how I envision it being built going forward.

The obvious next step is to write the code, which I started earlier this week by writing the unit and integration tests for the new Node code base.

Since I spend so much time in Visual Studio these days, I thought I’d give the Node tools that Microsoft released a try. Then I remembered that while I love what Microsoft is doing with the cloud and Azure, Windows is still Windows.

Never stop being Windows, Windows.

— Justin Williams (@justin) April 16, 2014

Data Analytics That Matter

Data analytics gets unnecessary grief. When most people think of analytics, they envision Google or Facebook following your every move on the web to figure out what sort of ads to show you while you are browsing. This is pretty creepy.

Admittedly, it’s pretty easy to shift over to the creepy side of analyzing user data, but that doesn’t mean that all data analysis is bad. In fact, it is essential if you want to run a successful product.

When I took over Glassboard, there wasn’t that much data on how the service was being used. None of the apps used analytics, and the server side generated a basic report that contained some basic vanity analytics such as user signups, boards created, statuses posted, and the like.

This is interesting information to notice from high-level analytics like user signups growing or dropping off, but it doesn’t tell us who is using the service or how they are using it.

Why Analytics Matters

Who, how and why are the most important questions you want to answer when you are starting to work with data analytics in your mobile products.

Choosing an Analytics Provider

Choosing an analytics provider is important. I have two rules for it:

  1. You should be paying them money.
  2. They shouldn’t be using your data for other things like selling ads.

Since Glassboard is an inherently private service by default both of these are essential. All of our board information is encrypted on the servers so that prying eyes can’t pry. I want to understand my user base (in an anonymous fashion), but I don’t want those users to be pawns to be used for a marketing company to sell ads off of.

Right now I am using Localytics, but I’m in the process of switching to Keen, because I haven’t been getting the value out of Localytics to justify its $500 price tag. Keen’s pricing and feature set seems much more promising to me. Mixpanel is probably the other major player in the mobile analytics game. They offer some powerful functionality as well.

Each of these services is going to likely run you into the hundreds of dollars range if you have a marginally successful application. The obvious goal is to be able to use the information you garner from these analytics providers to make informed decisions to help you grow your app’s reach and in turn drive more revenue your way.

Vanity vs Useful Analytics

If you’re just focusing on the vanity analytics such as how many users you have, it’s very unlikely that you’re going to get your money’s worth out of any third-party service. What do I consider vanity analytics?

This is useful information, but it’s also pretty easily to generate yourself for much cheaper. Alternatively, it’s something you can just check periodically rather than something that needs care and attention on a constant basis.

The real power of analytics comes when you start to understand how your customers are using your app.

You get the idea. These are hard questions to ask and creating the tools to generate that sort of data is non-trivial. But, when you can start to understand how long someone is staying in your app, you can start to adjust the design of the app to either increase or decrease that engagement.

If you aren’t getting a high enough conversion rate on your premium upgrades, you can start tinkering with the wording or page layouts to see if that will either increase or decrease your conversions.

If you’re getting a bunch of non-paying free users, you can use data to start to understand why they aren’t paying. Maybe your free plan is too generous? Maybe they are just downloading the app and never using it after that first launch? Maybe they are just cheap?

Analytics Through Customer Feedback

Automated usage analytics is a useful metric to have, but far more useful is understanding your user base personally. When I first took over Glassboard, I didn’t really understand who the user base was. I knew how big the active base was, but in terms of who was using the product? It was just guesses and assumptions.

The first thing I did when Sepia Labs handed over the keys was to send out a short user survey using to all of the existing premium users to introduce myself as the new owner of the service and to get an understanding of how they were using the product.

Glassboard’s premium user base is far smaller than our free customers, but since this is a bootstrapped company, they are the more important customers during the acquisition. I wanted to understand how the people who supported the service in the past were using it so I can continue keeping them happy going forward.

Our premium user survey had a 70% response rate, which was insanely high. It shared with us a lot of useful information about how Glassboard is being used (many ways I didn’t even imagine!) as well as what alternatives people would consider, which is a pretty good way to learn about some different competitors you may not have heard of.

Another thing I implemented when I took over Glassboard was a ‘personal’ email that is sent out to users a few days after they sign up. It comes from my email address and is basically a prompt to gather direct feedback from our newest users.

Hi [John Doe],

I’m Justin Williams, the CEO and lead developer of Glassboard. I wanted to see how things are going so far.

If you have any questions, feedback or need help with anything at all, reply to this email and I will get back to you with a personal reply.

Thanks again for using Glassboard!

I receive a few responses a day from this, which has been really useful for understanding who is signing up for the service, how they are using it, and (most importantly) what they are finding confusing or hard to grok about Glassboard. By far the biggest source of frustration these new users have is the onboarding experience.

When you sign up for a new Glassboard account through the apps, it creates your account and your first board called “[Justin’s] Board”. It then drops you into an empty news feed. Hardly ideal.

The feedback I’ve received from many users is that they are confused at this point, which is really good personal data. It shows that I have an opportunity to improve the onboarding experience to hopefully receive a more positive response about functionality in the future. We’re working on it now.

Always Keep Tweaking

I’ve been sending the email above for the last few months, and the value from it has diminishing returns at this point. I’ve recently noticed a pretty major influx of new users coming onto the service, but I don’t really have a good idea where they are coming from right now.

I’m thinking my next goal for these new user signup emails will be to just plainly ask users to tell me where they heard about Glassboard and what they are using it for. I may get less of a response back, but the data that does come in will be interesting to see if the understanding I have of my audience from earlier this year still matches the new users signing up as of April 2014.

Data is only as useful as it is current. Long-term trends are meaningful in some use cases, but when you’re in the middle of trying to turn around a ship as big as Glassboard, the past isn’t nearly as important as the present. Understanding your current users is essential to being able to build and sustain a successful product in this new app economy.

The Parts of Your Platform

The simpler devices get, the more complex our jobs as developers becomes it seems.

When I first started my independent developer career way back in the dark ages of 2006, building an app usually meant building a desktop product that persisted data locally. In some cases there was an Internet backed service tied to it, but it wasn’t the norm. This was before Dropbox, people.

If you truly wanted Internet connected services, you built web apps. Using a mix of HTML, CSS and a sprinkling of Javascript you could build web pages that could replace your desktop apps with something that could run on any device and any browser.

Once mobile came on the scene, web apps weren’t as ‘sweet’ a solution as some would have liked us to believe. The pendulum swung back towards native app development, but with the added bonus of being network connected at all times.

For an app that connects to a third-party service such as Dropbox or Twitter, always-on connectivity means implementing a third-party API in your app and using that as the foundation for your data access. It’s a little more work than our desktop days, but certainly not that big of a hassle.

Fast forward to 2014 and you’re starting to see convergence of mobile and those web technologies. Mobile apps from smaller developers are starting to offer online services either as a value add (such as the wonderful Day One app) or as the foundation of the service (such as Glassboard or soon-to-be from Vesper).

Mobile apps requiring their own custom backend data isn’t new for many operations, especially those with a large staff and a bankroll of venture capital money to burn. For the mom-and-pop shops like Second Gear and Q Branch, it’s a whole new world that just became more feasible just recently.

So, what changed?

App Pricing And Expectations

When I released Photos+ last year, one of the biggest sources of feedback I received was “where is the iPad version?” Nevermind that I just spent several months perfecting the iPhone version, consumers expected that the app would be run on all their iOS devices.

Beyond just expecting your app to run on both an iPad and iPhone, users also expect that data to sync effortlessly between those devices.

Implementing that amount of functionality isn’t impossible, but at $2.99 per app or so it becomes really hard to make the economics work in your favor. If you can instead sell a service for a monthly or yearly fee, however, and then give the apps away for free it becomes a bit more feasible to make the economics work. Still difficult, but at least less of a crapshoot.

The Cloud!

Everything is in the magical Cloud now. All your files are on Dropbox. All your photos in Photo Stream. Everything else in Evernote.

Cloud computing has eliminated the need to be a sysadmin and host your own server hardware in favor of renting resources in the cloud. Amazon, Microsoft, and Google are the big three and are all jockeying to lay claim to all the CPU and storage on the web.

Glassboard runs on exclusively Microsoft Azure. All user data is encrypted and stored in Azure Table Storage. Images and videos live in Azure Blob Storage. The actual platform app itself runs on an Azure Cloud Service, which makes scaling as easy as adjusting a few sliders on the Azure web site.

Backend as a Service

Take the cloud computing paradigm, and simplify it even further and you get Backend as a Service. With a BaaS provider such as Parse, Google App Engine, or Azure Mobile Services, you don’t even have to worry about provisioning resources on the cloud. Instead you just import an API wrapper into your mobile app and configure a few cookie cutter options on the BaaS provider’s web site.

These providers make cloud-enabling your product incredibly simple. The tradeoff of using one versus the more traditional ‘cloud’ is that costs rise exponentially much quicker. It’s a tradeoff that many are willing to make, plus competition has made pricing a bit more competitive than it was even just a year ago.

The Parts of a Platform

We’ve accepted that running our own server-side resources is becoming a reality, we should analyze what that really means. And more importantly, understand what is involved.

1. The API

The brain of that powers any cloud-enabled service is its API. It doesn’t matter what language you write it in as long as its secure, stable, and reliable. Glassboard started out as a full C# product, but I’ve been rewriting parts of it in Node where it makes sense.

Most of the time your users won’t see your API firsthand, unless you offer it publicly as a value add to your customers. Whether it’s a public API or not, versioning from the start is always a good idea. You’ll inevitably get to the point where you want to add or change your API’s functionality. By versioning your API from the start, you can ensure that legacy clients aren’t immediately cut off as you improve your product.

If you’re running a marginally successful service on an API, it’s worth your financial and time investment to look into services like New Relic and Runscope. New Relic does magic things to figure out bottlenecks and other slowdowns in your API clients. Runscope is an API monitoring service that lets you test the health of your API as you run a suite of tests against it.

2. The App(s)

Whether its iOS, Android, Windows Phone, or OS X, the app is the nut of any platform. It’s what your consumers will predominantly use to interface with your service and will shape their opinion on it.

This is likely going to be where most of your time is spent, assuming you want to build something that stands out in such a crowded market. There are plenty of hybrid app solutions that can get you on all platforms quickly, but quick doesn’t necessarily mean quality.

Glassboard has native Android and iOS clients. Each one is built using the system-specific APIs and designed to look and behave like a first class citizen on their respective platform. It’s far more work (and cost) than the hybrid approach, but I believe a better app experience in turn leads to a better conversion rate to paying customers of the service.

3. The Management Backend

This is the one most people forget. Once you’ve developed your API and built the app(s) to consume it, you likely have a user base that is going to be emailing in support requests and bug reports. Those requests likely mean you need to look into the data stored on your backend.

You aren’t an animal. Running raw SQL queries from the Terminal is neither safe, nor ideal. You need yet another app for your platform. The only difference is that this one is for internal use only.

The admin portal is the piece that most developers forget about until after they’ve shipped, but it can also be one of the most important part of your product once you reach a level of success. Let’s imagine you outsource your support to a third-party company (I recommend and use AptFolk). Ash and crew are a smart group, but they don’t know the internals of your product or how to connect to your servers. Nor should they need to. By offering a web or mobile app that allows them to look up and adjust account information or whatever else is relevant, you’re making your job easier.

Beyond just support, metrics are essential to measuring success or failure. There are simple vanity metrics that are useful for showing on an app like Status Board:

For more advanced metrics, I recommend a third-party provider that specializes in things like customer segmentation, funnels, and other more advanced functionality. I use Localytics, but I’m actively shopping for an alternative. Mixpanel is also a nice service, but gets expensive real quick.

Every Piece Matters

The good news is that even though our jobs as app developers is becoming more all-consuming, the tools that enable us to do this are becoming far easier to use. I couldn’t imagine running my own servers back in 2008, and now I don’t have to. Cloud computing takes care of the heavy lifting and let’s me focus on the product itself.

Just because I don’t have to worry about imaging and provisioning servers doesn’t mean I can slack on other parts of my product’s development cycle. The API, apps, and backend platform are all equally important pieces of the puzzle that defines your product. The app may be the only public facing one, but without the API it doesn’t exist. Without the backend management portal, supporting your user base becomes a nightmare that impedes development.

Treat each piece of your product’s stack like it’s the most important, user facing portion bit. Quality isn’t just mean for the surface.

The Full Stack App Developer

Whenever I look at job boards, I notice that a lot of web development jobs are wanting someone who is a ‘full stack’ web developer. To me, that means someone who can build the front end of the application using HTML, CSS, and Javascript as well as the backend using whatever server-side framework is in there. To top it off, sprinkle in a bit of knowledge on cloud computing.

The ‘full stack’ paradigm is starting to make its way to app development going forward as well. It’s no longer enough to just know how to write code for a single platform. To be truly relevant and valuable you need to have an understanding of API design and implementation and cloud computing as well.

Ignoring the cloud or web services because they are out of your comfort zone is no longer an option. The app economy is shifting. Adapt or die.

Getting Good At Making Money

If there is one thing I don’t think I excel at as a business man, it is making money. That’s probably not a good thing to admit publicly, but it’s reality. In fact, I’d argue that I’ve gotten worse at making money in the past several years as the third-party software market has bottomed out. Making money was hard enough selling $25-$40 products. Try doing it when your most expensive app is $4.99.

The first step towards recovery is admitting you have a problem, and this is one that I am working on this year as I am steering Glassboard towards its next phase of life. I have to. This was December and January’s membership revenue and operating expenses:

Revenue vs Operating Expenses

I won’t share the exact dollar amounts, but yikes, right? If there’s any solace in those numbers, I was able to make a decent amount of progress between December and January in cutting costs and raising revenues.

Making money is harder than it seems. Most people assume you put a product out and people instantly find and support it. The reality is that for most products, they first struggle to find an audience, and secondly struggle to find an audience that’s willing to pay.

I have an inherent advantage by having a decent online following, which gives me nice starting ground of users to sell my wares to, but that’s by no means a guarantee of success. The goal of making money is to convert people outside of that base into paying customers. That is a problem I’m hoping to solve sooner rather than later.

So, how do I get good at making money? There’s a few different ways I can approach it.

Use Someone Else’s Money

This is what I’d argue is the ‘standard’ way of doing things when you are running a multi-platform service such as Glassboard. You spend a decent amount of time building a pitch deck and shopping it around to a variety of venture capitalists who will hopefully provide you with enough money to give you the resources you need to grow.

This is the least appealing to me for a variety of reasons.

For one, raising money is a full-time job and any time I spend running around begging people to write me checks is time I’m not spending on the product. Second, I don’t see it as a good fit for the type of business I want to run. Venture capital is for people who want to grow something to Instagram or Tumblr levels. Getting funding for something that VC typically (and insultingly) refers to as a “lifestyle business” is far harder. Glassboard, by design, isn’t designed for those insane levels of scale.

And finally, I’m personally averse to the whole racket of venture capital. Entrepreneurs are the new labor, especially when old guys with money are funding the sweat of someone who gets to put “founder” on their business card. I’d rather not participate in that.

VC is a nonstarter.

Cutting Costs

The easiest way to make money is to spend less of it so that your monthly profit-loss is heading in the right direction. By cutting costs, it’s easier to approach the break-even or profitable point.

This is the way I have been approaching Glassboard so far into my tenure. The existing service had quite a bit of fat on the edges that could be cut without impacting the service in a negative way. Some of the things I did were:

  1. Negotiate a new plan with Sendgrid to account for how much email Glassboard sends on a daily basis (well into six figures). This 30 minute meeting shaved over $1000 a month off my monthly expenses.
  2. Disable email on any board that has over 200 members on it. There are not many of these high traffic boards, but they accounted for a heavy portion of our email traffic. I’ve had maybe 2 complaints about this since I changed it six weeks ago.
  3. Optimize Glassboard’s Azure Cloud Services to dynamically scale the amount of instances it needs based on how much traffic is coming in. This shaved about 40% off the CPU costs on my monthly Azure bill.

There’s still plenty I can do to cut costs, but that only solves a small portion of the equation. None of the remaining items on that list are on the low-hanging fruit/quick win list.

The far more interesting opportunities are actually increasing the monthly revenue.

Increase Revenue

Duh, right?

For apps increasing revenue can be done by raising your app’s cost, adding advertisements, or inserting some sort of in-app purchases. Every app is different, so it’s hard to offer a single prescription for success to everyone. I can only speak to my use case.

For Glassboard, this is the hard nut to track because I’ve got tens of thousands of users who have been using a service for free that I have to figure out how to bring revenue in from.

One of the first things I did was lower the cost of a Glassboard Premium subscription from $50 a year to $25. There was no science behind this decision other than me personally not being willing to pay $50 a year for the service. $25 sounded much more reasonable for the existing offerings.

I also added the yearly premium subscription to the iOS app as an in-app subscription, so that it’s easier for people to support the service.

Neither of these changes set the world on fire. I sold more Premium subscriptions in two months than Glassboard sold in its previous two years of existence, but it was also at half the price.

The more interesting metric I discovered was how many people weren’t even aware Glassboard had a paid offering. Since people primarily access it through the iOS and Android apps, they had never been prompted to pay for the service. I had more than a few complaints from people about adding the premium subscription as an option in-app. These are the folks I assume will never be customers.

There’s still plenty of existing users to try and convert to paid, but $25 a year is a hard sell in 2014 when $1 apps are seen as the new Premium. The next phase is experimenting with different business models and ideas as I try to get better at making money.

I’ve got a few ideas. Now to just build them out and measure the results.

Handling Freemium Customer Support

One of the challenges of taking over a service as large as Glassboard is handling the support load that comes with it.

Since 2010, I have had Aptfolk on the payroll to handle the majority of Second Gear’s support load. I’ve long believed that my time is best spent invested in improving the products versus answering the same emails over and over again. If there’s an issue that requires my attention as the developer, Jason or Ash would escalate the ticket to me, but the vast majority could be handled as “tier 1” support. Since every Second Gear customer was a paying customer it was an expense that made sense.

With Glassboard, that dynamic has shifted as the vast majority of our users are free, non-paying customers. The ultimate goal is to convert a good chunk of these users into paying customers (while also bringing in new customers at the same time hopefully), but there’s a lot of work to do before we get to that point. As it stands today, I am paying the Aptfolks to help users who are not currently paying for the product and (being realistic) may never be paying customers. When you are a company backed by a big wad of venture capital cash this isn’t that big of an issue and can be chalked up as a cost of successful user acquisition. When you’re a small company like Second Gear that is 100% funded by our customers (and my personal bank account sometimes!) this can be a costly problem.

Free support isn’t something new. When you offer a free trial, you want to offer support and answer any questions potential customers have while they are evaluating the product. With the freemium model where there is always a level of users who will never pay for the service. Answering the question about how to handle support for these users in a way that doesn’t break the bank is something that has been on my mind lately.

As one of the ways of cutting down on the support cost and load, we recently switched to Zendesk for managing support. Yes, we switched to a paid service. Previously everything was handled by a mix of FogBugz tickets and TextExpander snippets. It worked well for several years, but dealing with a service that spreads across multiple platforms (iOS, Android, and the web) was making it difficult to track cases, analyze support trends, and burn through tickets quickly. FogBugz is great, but as a primary support tool we were hitting the pain points more than ever. Moreover, the macro support in Zendesk sold me on paying $50 a month as it allows us to quickly automate frequent questions and inquiries. If the service allows either me or the Aptfolks to iterate through our inbound support tickets quicker and saves us a few hours a month, the monthly Zendesk fee is worth it.

Free Support Is No Support?

When you’re dealing with a customer base that isn’t paying for the product, the goal is to offer as much self-service support as possible. You want customers to be able to find the answers to their questions either via a knowledge base, blog posts, or user-to-user support. As a last resort they should email you for an answer.

I’ve seen quite a few SaaS companies only offering direct support via email or phone for certain tiers of customers. For free customers, the only support options is the automated knowledge base or user-to-user support.

This is tempting, but I also can’t help but wonder how many potential customers aren’t converted to paying because they couldn’t have one of their questions answered. Obviously, I need some sort of data to measure this, but my current hypothesis is that it could be an issue.

To achieve the “No Support” option also requires a substantial amount of self-service support. This is admittedly an area that needs a lot of improvement for us, and another reason for the Zendesk switch. While we have the Glassboard Help board (Invite Code: HELP) that lets users help each other, the vast majority of support still comes through our Zendesk email address.

On the todo list is to begin working on a knowledge base that answers frequently asked questions. We’re also working with some lovely people to help with general product education that will highlight how to get the most out of Glassboard. The hope with the product education is to help alleviate the “why should I use this?” questions better.

Automating Support

There are some support tasks that aren’t as easy as pressing a button. Glassboard currently has no ability to automatically delete your account or change your email address. Why? I’m not entirely sure what the thought process was behind that when it was built by the Sepia Labs folks. What I do know is that these are the two biggest support requests we receive and that each time we have to handle one of these tasks for a customer, we lose money.

When the request comes in, we have to:

  1. Go into Glassboard and find the user’s account
  2. Update their email address (or delete the account)
  3. Go back to Zendesk and email them about the change.
  4. Possibly handle any responses that come in.

It’s not a difficult task, but it is tedious and something that we shouldn’t have to deal with manually.

Any support inquiry that comes in more than once, be it a bug users are hitting or a question, is an opportunity to automate and solve a problem with technology. In the case of changing an account’s email address or deleting the account entirely, the solution is to write code so that users can handle these tasks themselves either via the web or mobile apps.

Given that these are two areas that we are getting multiple requests for daily, it is high on my development timeline because it’s not only a better customer experience, but it’s also an opportunity for us to cut down on support costs by letting users handle these tasks themselves.

Support Driven Development

Support has long been one of the key metrics I have used when prioritizing bugs. The more a bug is reported, the more likely it is to move to the top of my development timeline because I want to make it so that we no longer have to answer emails related to the problem.

Support questions have also been a good eye opener for figuring out the most confusing areas of Glassboard as a product. Our first line of defense for these sorts of issues is to improve product education so we can refer customers to a web page or video that explains some function of the product.

In some cases, education may not be the proper solution, and is just putting a band-aid on an implementation issue. In those cases, it is worth investing the time in analyzing the user experience and seeing if there are ways to improve that. Glassboard has quite a few of these pain points that we are looking to resolve in the coming months. The biggest issue on our list is the onboarding experience of Glassboard, which I hope to share more about in a future post.

If you’re answering the same support questions over and over, take a few hours to highlight the issues that are repeatedly being hit upon. Once you have those, work on a plan to alleviate them and in turn, lower your support costs.