In 2009 I launched a side hustle, TroopTrack.com, that helped Boy Scout troop leaders manage their organizations. It was a simple product and was built as a one-off solution specifically for Boy Scout troops.

Within a year I was getting requests from customers to add support for Cub Scout packs. And Girl Scout troops. Other “youth character development” organizations started approaching me, including American Heritage Girls, Knights of Columbus, and other groups I had never heard of.

It didn’t take me long to realize that I didn’t want to replicate what I had done for Boy Scout troops. I needed to be able to add support for a new organization without writing any code.

I needed to build a platform.

The first thing I did was freak out. It seemed like a huge thing to do, and to be honest I delayed starting because it seemed so big. 

This delay worked in my favor because it gave me time to process what it meant for me to be a platform. The most important realization that came out of this time is a crystallization that, in hindsight, seems obvious.

I needed to build a platform for local youth character development organizations. I wasn’t building it for the national or regional organizations, but for the individual units around the country. If that worked out, then perhaps I would expand into those other areas, but the first concern was clear.

Once that was clear, I started making a list of features in TroopTrack, and whether or not they varied by organization or stayed the same.

A lot of features are the same regardless of whether you are a Girl Scout or a Police Explorer: calendars, web pages, email groups, equipment management, etc don’t change from organization to organization.

Other features vary significantly from group to group. For example, awards, leadership positions, unit structure, and training are completely different in every type of organization. Boy Scouts have merit badges and ranks. AHG has “Frontiers” in various categories such as “Outdoor”, “Sports”, etc.

Things that varied from organization to organization had to be based on data driven abstraction, and they needed an admin interface. Things that didn’t change didn’t have this requirement.

With that list in hand, I had a vision. I knew where I was, and I knew where I needed to go. So I started. I built abstractions for organization types, and then attached abstractions for awards, positions, etc to that abstraction. And I built admin tools as I went.

Not all differences could be captured by data abstractions. In some cases, different unit types needed different behaviors. I didn’t want my code to be littered with “if cub scouts” and “if girl scouts” all over the place, so with the help of my friend Ryan Bell I came up with a simple framework for implementing organization specific behavior that made the purpose clear, isolated custom logic clearly, and was easy to understand.

Six months of nights, weekends, and vacation days later, I added support for Cub Scout packs without writing a line of code. A few months later I added another unit type. Today, I can add a new unit type in a few days of data entry that can be performed by an hourly worker.

So what do we learn about building platforms from this experience? In the remainder of this post I’m going to try to distill the lessons I have learned in the past decade plus about building and scaling a platform.

The first, and most important lesson deserves some emphasis.

A corollary to that is understanding what it’s not for. If you are going to build a platform you have to know what the platform will allow you to accomplish, and you need to use that as your north star. It should guide everything you design and build. I’m not a big upfront design guy, so for me this meant moving incrementally toward my goal. To do that, I had to do the second most important thing:

The first thing I think you should do is spend the time distilling this down to a few sentences at most. For TroopTrack, this was in the form of what an agile practitioner might call an “epic” user story:

“A TroopTrack admin can add a new organization type without engineering support.”

This statement is dependent on a lot of factors, including important questions like, “how do you expect to scale?” For TroopTrack, scale happens in two dimensions - entering new micro-markets by adding support for new organization types and then penetrating those micro-markets. For your platform, it may have other dimensions, but it will generally have similar implications - there are features that should be self-service (sign up, payment, member management, etc) and there are features that will need to be supported by centralized admin capabilities. 

You need to make good choices about which category these features fall into. Putting the wrong things in a centralized admin can kill you operationally. We supported data imports and member transfers centrally for years, and those two things made up 50% of our support requests. We moved those to self-service and everyone is happier.

I’m not a big upfront design guy, and I don’t want this statement to make you think you need to spend six months designing your platform. Don’t do that. You can build a platform incrementally while you develop the architecture. The important message here is that you need to start thinking in terms of next-level abstractions that weren’t necessary before. These don’t have to be super complicated - often it simply means creating data structures to represent things that were previously encoded by engineers. 

It doesn’t take a genius rock star engineer to do this. It just requires thought, commitment to the vision, and the patience to incrementally build the features you need, learning from each development cycle and making things better.

The last thing you want is to build a platform that engineers don’t want to work on. I have seen engineers actively work to avoid certain features because they are in a part of the code that is confusing, poorly designed, or leveraging libraries we dislike.

Platforms can compound this problem by adding next-level abstractions like those mentioned above. Those abstractions need to be properly named. Each one needs to do as little as possible, and it needs to be clear how to extend and test them.

Creating a canonical approach to how you build features within your platform can be a big help. I have been a part of this on more than one occasion, and having a written canon (which is much more than a style guide) has been hugely beneficial every time. The canon should be clear, guided by all engineers, and malleable enough to adapt to new problems. It should grow incrementally along with your architecture.

In a platform, the most important to canonize is the exception to the rule - the behavior that varies by customer type (or some other factor). These exceptions need to be easy to spot, easy to understand, and if possible, implemented using the same general approach every time. You might need to write some frameworkish code to make this work. For example, the most common “exception” in TroopTrack is in the user interface. I need to present different workflows in different ways for different customers, and I didn’t want logic in my code that said “if this type of customer render this, but for others render that.”

Since TroopTrack is a rails app, we added some logic to the rendering engine that I won’t explain here, but the outcome is that when I want to create an “exception” user interface, whether at the page level or some partial of a page, all I have to do is create files that follow a simple naming convention. For example, let’s say I need to have a different presentation of member names in a list for Girl Scouts than for everyone else. I would create the following files:

This approach makes the exceptions easy to build, easy to spot, and easy to understand. Your solution for exceptions will likely be different, but the point is, figure it out. Canonize it. Make it easy.

I was able to launch Cub Scouts on TroopTrack after six months of solo development in my spare time, but that doesn’t mean I’ve stopped “making TroopTrack a platform”. More than a decade later, I’m still working on this. Every feature request I look at, every new idea I have, goes through my internal platform. How do I adapt this feature so it is usable by all customer types? What exceptions will I need? How do I let customers decide if they want to use it or not?

Turning a one-off product into a platform can help you enter new markets and scale beyond initial plans for a product. It’s a daunting task, but it’s not as hard as people are inclined to think, especially if you have a north star to guide you

Want to talk more about building a platform? Add a comment or send an email to davidray@hey.com. While you’re here, join my mailing list to get content like this in your inbox.

Dave Christiansen
Writer. Maker. Programmer. Leader.