Looking back, one of my biggest lessons learned from building Gatsby is to avoid pre-mature automation.

What do I mean by this? Take our payments system, for example. Integrating Stripe was quite a doozy: a custom subscription job, saving payment methods, handling failed payments, handling account balances, etc. There was 

logic that went into all of this. All in all, it took about two months to complete our integration and get to the point where it works. (And at this point, total development time for Gatsby was only at ~3 months, so the payment system was 40% of total time spent. Yuck.)

That system, in hindsight, is completely overkill for the business' needs at that point.

 We had no users, no recurring revenue, nothing. So why did this payment system get built?

It's easy as a developer to get carried away with automation. "If only x was built, I wouldn't have to worry about y", is a common trap—and honestly, it's often not an incorrect one. 

As engineers, we're always thinking about scale.

 Yes, it's true that building this thing will make your job easier down the road when we have 10,000 users. The allure of stress-free development is tempting, especially if you have multiple tasks you're dealing with and want to run the business as passively as possible.

However, one must account for the business' position and its priorities. When considering further automation, you have to challenge yourself: "with the current position of our business, 

More often than not, it's not. Elon Musk has a brilliant quote in this department:

The machine that makes the machine is vastly harder than the machine itself.

The whole tweet is a perfect descriptor of what we're trying to accomplish: scale. If everything is automated, scale won't be a problem! However, the difficulty of automating that solution is much much much more difficult than creating a repeatable, manual process for solving that same problem.

That's what I wish we did for Gatsby. Instead of jumping the gun on automation, I wish I had created a lightweight admin interface where I can see whose turn it is to send an invoice that day. Then send them to a pre-built Stripe checkout page. That would've been the 

minimum viable product answer. Instead, we over-optimized by over-automating and burned through two months we could've spent on marketing or improving MVP features elsewhere.

I can't help but think about how this would've been avoided if I had properly outlined the work ahead and determined my 

 for this work. Basecamp created this idea of determining appetite, and 

When shaping, we focus less on estimates and more on our 

 Instead of asking how much time it will 

 to do some work, we ask: How much time do we want to 

If I had taken the time to understand that no, this payment integration idea isn't worth spending two months on, or 40% of our total development time, we could've avoided the over-automation.

In the end, it's a lesson learned. Treat all development efforts with great respect and always challenge what "needs" to get built next. I mean, it's not all bad; the payment integration is ready to go, so if we ever do hit scale we'll be set. However, we definitely skipped over some steps in between and certainly mismanaged our time.

This is one of those situations where it's tough balancing being 50% engineer and 50% businessman. Automating processes is tempting, sure, but automating too early can lead to wasted resources and wasted time.

It's easy as a developer to get carried away with automation. "If only x was built, I wouldn't have to worry about y", is a common trap. Here's how to avoid it.

Say No To Premature Optimization

One of the most important aspects of the Gatsby platform is enabling communities to earn money. We're "monetization-driven", which means many of our features will be designed to enable community owners to make some fat stacks of cash.

We came up with two strategies for implementing the collection method. Think about which one you'd choose. They differ very slightly, or so we thought...

The first method: when a user pays a community, the payment enters Gatsby's collective bank account. In our database, we keep track of the community owner's balance, not before Gatsby takes its percentage. When they're ready to use that money, they can set up a Stripe account within the Gatsby interface and trigger a deposit to their bank account.

The second method: before a community owner can start collecting money, they 

 to create a Stripe account. Then when a user pays a community, the money enters directly into their Stripe account. Gatsby takes a percentage on its way out. From there, they can send their money from Stripe to a bank account.

were building Gatsby, which method would you choose?

With the first method, you'll have direct control over the funds. Everything that enters the Gatsby platform will enter this account, giving direct control, insight, and safety to the business.

With the second approach, we don't have to worry about the security issues, balance tracking, and communities will get their money right away. However, it won't be so easy to reuse the money they earn. The term "Use your Gatsby Balance" probably won't be a thing.

Well, turns out, there are some serious legal implications operating with the first method. Technically, 

the platform would become a Payment Facilitator

, and like I said earlier, it's pretty similar to a bank. Now you have to be aware of how certain individuals could use your platform to cause harm. If you said option two, you are correct. (The first option is not impossible, but the overhead is way too much for a small team of one.)

In fact, the FTC would not take too kindly to a lackluster implementation of the first method. Here's an example:

Let's say you're a community owner and you happen to live in a country the 

. Then let's say, in the future, the platform had an option to withdrawal your money without using Stripe. The combination of those two things has now enabled a loophole for foreign entities to use Gatsby as a means for fraud and other financial crimes. Yikes!

When (not if) this gets uncovered, you'd be under investigation by the Financial Crimes Enforcement Network, the Office of Foreign Assets Control, the Federal Trade Commission, and whoever else decides they want to throw the book at you. They'd be queuing up fines in the many millions.

The reason method number two protects you is because we'd require Stripe authentication before you can earn money. So if you're cool with Stripe, you're probably cool with us. We'll let them do the hard work here.

Can't we still offer method one but not allow them to withdrawal to anywhere but Stripe later on? Yes, but that would set up a customer service nightmare (and potentially a PR nightmare as well). If these "restricted" users start earning money, then go to withdrawal and find out they can't because of where they live? Can you imagine the emails we'd get? "Robbery! Theft!"

Plus, another one of our pillars of success is a great user experience. And that, my friends, would not be a good user experience.

We came up with two strategies for implementing a payments collection method. One gets prison, one doesn't.

The Payments Dilemma

Growing a network reliant on network effects is extraordinarily difficult. This graph helps illustrate the “self-fulfilling prophecy” phenomena of growing a network reliant on network effects.

The orange line here is the expectation of users a potential newcomer has when joining the network. The blue line is the actual number of users. If the actual is less than their expectations, they will be disappointed and leave the network. If the reality surpasses their expectations, then they stay! The arrows denote “pressure zones”, or how the actual number of users will be affected in that area.

As an example of this graph in action, let’s say we’re starting a new social network. We have a huge advertising campaign, the product is great, launch day is a huge success. Users hop on to your social network day one and find… that none of their friends are on the network. Not just that, nobody they even know is on the network. But what about the expensive marketing campaign? The messages? The hype!? This was supposed to be the next big thing! That user may try again a few days later, but the results will probably be the same. The user is disappointed, and leaves the network forever. Sound familiar to something you've built?

Multiply this effect by a thousand people and a thousand dollars and… the network still fails. People still get disappointed and 

the total number of users can’t seem to get off the ground.

 This is that “downwards pressure zone” you see in the graph, in action. That first hill is extremely difficult to climb, and 

users need to quickly see and experience the network’s benefit before deciding to stay

. This is why you don’t see any successful private social networks. I know this because I

. Without a focus on discovery, without users having a feeling of how many people are on the network, without a clear benefit screaming in the user’s face, the platform will ultimately fail, because new users have no incentive to stay! Only by reaching that tipping point on the graph do we start to see success. Climbing that hill is hard, and I’ll show you how to beat it.

Now there are strategies for overcoming this initial downwards pressure zone and that's something I'd like to get a little bit more into. This is often called the chicken or the egg problem, and there are 

quite a bit of strategies for overcoming it

. But if we're talking about network effects, we have to talk about how we're going to apply this to our product and do it successfully.

I don’t want to understate how important this is. Being the first network to reach the tipping point is crucial to a platform’s success in a volatile market. In a market of products with network effects, there isn’t room for second place. It’s either sink or swim. The success of one network will make using the competitor’s network much less attractive. Reaching this tipping point is more important than being the “best”.

Every network has to start somewhere. There was day one for Facebook. There was day one for Twitter, a day one for YouTube. Every platform has its day one. And how you approach that day one is going to separate the winners from the losers.

Now, if your product has benefits other than just users, it’s a different story. So Figma, Venmo, and other services don’t fall victim to the ruthless downwards pressure zone as much. It becomes much easier to surmount that upwards hill if you also provide a service that benefits users without network effects.

The following strategies focus on facilitating a “surprise effect”. The goal is to beat the expectations of the user when they first enter the platform and surprise them with either direct benefits. Remember, if they become disappointed with what they see on the network, they’re going to leave and the total number of users will trend back to zero. You need to beat the downwards pressure.

There’s certainly psychology at play here, and I’d argue it’s working against us. Unfortunately, today’s users have a high-expectation of what a network will be. We’re used to being able to find anyone we’ve ever met on Facebook, any celebrity on Twitter, and any colleague on LinkedIn. We’re spoiled with diverse networks, and will make that initial user-disappointment phase hard to overcome.

is launch your network to the world with no initial content and no pre-existing users

. Do not do this. You’ll be cursed to the realms of downwards pressure forever as your network suffocates from stagnant growth. It will fail. No amount of marketing will convince a user to stay on an empty network.

The first real strategy is to convince a large initial group to join your network. By getting a large, connected group on the network, you can create a network with strong ties between them. Facebook unintentionally used this tactic to its benefit. Zuckerberg targeted students that went to Harvard, and users quickly hopped on to see their peers on the network. Within the college, Facebook went viral, with that virality serving as a catalyst for the large initial group. And by the way, 

Tinder, the location-based dating app, did something similar by targeting sororities and fraternities at local colleges and onboarding several users at once. 

 (that's the goal!) to find all those girls or guys they knew from the other sorority or fraternity. With several users joining at once, the network would become sustainable among them, and be able to support further growth from solo newcomers.

A similar strategy can be employed by influencers and having their followers join the network together.

By setting a low price, or even free, users will be more inclined to try the product. This is less tactical than the other approaches, but helps get that large initial group of users at once. 

, as “small changes in the properties of the market can cause enormous changes in the size of the equilibrium audience that is reached, starting from zero”. While you may be discouraged from lowering prices for various reasons, it may be worth it to beat your competitor. Once market dominance is achieved, the rewards are yours to keep 

: “This price below the cost of producing the good will result in early losses, but if the product catches on — if it gets over the tipping point — then your firm can raise the price and perhaps make enough profit to overcome the initial losses”. Remember: improvements to the product can always be made after. Reaching the tipping point first is most important.

Now, another thing to consider here is the velvet rope effect. 

 an article explaining how startups are using a “velvet rope” to create a hype cycle around their products before launch. In short, the velvet rope strategy is essentially creating a waitlist, then choosing which users you let into your platform. These are usually industry-leaders, influencers, or other notable figures.

The hype, while great for publicity and marketing, is a double-edged sword. On one side, it allows you to control the network effects of your product. That is, you decide who is “in” the exclusive network and who gets to create the content that others will later be able to consume. The downside, however, is that with hype comes expectations, and 

with higher expectations comes a higher chance for disappointment

. If new users wait months to access this network, constantly listening to the founders and other evangelists tell us how great it is, the content better be good. Because if it’s not, the disappointment will be very real and the user will promptly exit. Your hype has worked against you, and perhaps even sunk a ship that could’ve floated without it.

If you’re using the velvet rope strategy, you need to ensure the users you let in are planting their roots. 

New users need to be seeding exceptional content, and seeding the network with desirable information

. Imagine finally getting access to YouTube after being told it’s the best network ever! It’s so useful! … and seeing there are only three videos published. No amount of hype will fix a disappointing network. But if the network is good, the hype will create a list of users that can form the aforementioned large initial group. The content and its newly active users will push the network out of the downwards pressure zone and towards its stability point.

Bots, fake users, paid users, etc. Make it seem like more people are using the network than are actually using it. When Reddit first started, the founders were using several different accounts to post links and comments. They pretended to be several users, and by doing so, 

forced the perception that the network had more people on it than the actual

. New users would be surprised by how much content was being posted, and saw the benefit of the network. They’d stay around for a while, and 

soon those fake accounts would become useless, replaced by now-active users

. The network became sustainable on its own without those initial false accounts.

Now, this specific strategy is only possible for anonymous networks. But the point remains. Making it seem like more people are on the network will force your real user-base past the tipping point and towards success.

When I co-founded a product called HotTub, it was anonymous and we planned to incorporate a feature where users could 

 a post an unlimited amount of times. The app Citizen does this too.

Now, if you think about a feed with those two features, 

it's going to be impossible to tell whether it's one person creating all this content or 10,000 people creating this content

. With unlimited likes, you could sit there and spin the like counter 400 times. A new user will be shocked to see this small app has such an active network, and will decide to stay around. With this combination, the founders control the “actual” users line on the graph, forcing it beyond expectations, and towards its stability point.

Region Locking And Reputation Preservation

For localized services, like Lyft, Citizen, or Grubhub, it may be best to limit the availability of the network. At first, it sounds counterintuitive to lock the network down to a certain region and limit its growth, but with a locked region, 

we lower the burden of providing an active community to a fixed area

. Within this area, the evangelists of the app (most likely the developers and close friends) can populate the network with community-building in mind. A more focused attempt can be made at 

strengthening the engagement on a smaller network

, while also preserving reputation elsewhere. Essentially shrinking the size of the network will make what users see, how they interact, and what they perceive, easier to control.

you now control the expectations of users in certain areas

. For example, if Lyft becomes active throughout the whole country, but there are no drivers in one area, a user in that inactive location will become disappointed when trying to use Lyft for the first time. This perception of an empty network will lead the potential user to disregard the app in the future, possibly losing a customer for life. Repeat this several times as the user base grows, the network’s success will hurt its growth when trying to capture these users in the future; a victim of its own success. With region-locking, the network will be able to reduce these negative first-impressions with a coordinated roll-out and focused efforts, populating each new region with its valuable service, riding one success to another. In this example, Lyft would recruit drivers prior to opening the network in that area. Especially with limited resources, the company will be able to dedicate full attention to the upcoming rollouts, ensuring a beneficial adoption. Instead of becoming turned-off by the empty network, future users will become excited and look forward to when the network is released to their area.

The moment your users begin to feel not disappointed, but surprised by the content on a network, you’ll start to surpass the tipping point. Users will begin to feel like they’ve been missing out, they’ll spread the word about your platform, and become a regular user, hopefully contributing back as well. Multiply this by a thousand users and a thousand dollars, and you hit a point of explosive growth. 

That feeling of surprise drives the user to be a consistent one.

 This is where you enter the upwards pressure zone. It’s going to catapult you to a point where your network is sustainable and successful. This is where the bandwagon effect of something new comes into play and thrives. Users realize the value of being on your network, and decide to stay around a while. That’s when you reach the stability point. Your growth has become automatic, and you’ve become a major player in the market.

At this point in your network’s growth, you’ve become nearly immovable. You are now the big fish. It will be very difficult for a competitor to take your place as king. As long as you continue to capture the network effects of these users, your business isn’t going anywhere. Remember, network effects is about defensibility. Your company, your business, your network, has become defensible, and now you’re ready to reap the rewards.

it doesn’t matter if you have an inferior product

. It doesn’t matter if you’re the biggest fish or the smallest fish. You can turn market instability into market predictability, and you can lock in the market big time. With network effects, you become king. Your network becomes the defining aspect of a market, and there’s no way to stop your growth. Monetization possibilities become endless, and your time to figure that out only lengthens as more users join your network. And if, one day, you have to stop using the phrase network effects because of antitrust investigations, pop a bottle of champagne for me.

You launched your network and nobody's sticking around...now what?

How To Make Your Social Network Succeed

On Monday we're opening up Arcade to its first 10 customers. We're pushing a new website live, sending some emails, making some announcements, and more. It's gonna be a big week.

When starting a new project, I have the habit to use "when we launch" as a cornerstone of communication regarding timelines and goal-setting. We were using it all the time on our Zoom calls and Slack to frame some conversations.

It wasn't until we started getting into arguments about what needed to be done that we realized 

. We know it means some form of "something about this is becoming public", but we never specified what the heck we're launching, what's included, what that will look like, and more.

For our team, Dan set us on the right tracks and made it clear that "launch" would be incremental. It wasn't going to be all-or-nothing like I had originally thought. For our first launch, we'll release to 10 customers. That's it. No plan to launch beyond that (just yet).

Once that definition was set, it enabled us to actually plan for this launch way better and enabled clearer communication. Now when we talk about a launch, we know exactly what that means and makes our meetings much more productive as we remain on the same page.

For every subsequent launch that we have, for Arcade and elsewhere, I'll be sure that we define launch and get on the same page.

It's one of those things that nobody tells you to do when you're building cool things with other people. It's something we had to realize, learn, and fix. But since you're reading this you don't have to worry, I gotchu. Define "launch".

It's one of those things that nobody tells you to do when you're building cool things with other people. It's something we had to realize, learn, and fix. 

Define Launch

, we're discovering so much about design tokens that go against conventional understanding.

What does that mean? Today, most people would simplify design tokens by describing them as a key-value pair. A name and a value. However, 

we created a way for a single design token to have 

Before digging in to that concept, we need to address the idea that design token = key-value pair. To me, this is wrong. Instead, we've been thinking of a design token as a big object of instructions that include how to transform the token, the context of the decisions behind it, various meta information, and more.

This big object of instructions is the design token.

 Those CSS, SASS, iOS, whatever variables that get outputted are exactly that: an output of a design token. Not a design token itself. In short, 

design tokens only exist in a pre-processed state

So within this big object of instructions, we can now specify a field for 

, like what platform we're rendering.Dynamic values gives huge amounts of power in enabling tokens to support multiple platforms.

Dynamic tokens in Arcade allow the value to change depending on what platform is rendered

For example if we render CSS, we can use sizes in rems or px units. If we export to Android however, we can use values in dp, sp, or whatever we see fit.

This puts so much control in the hands of a designer or developer. There's no implicit transformation happening if you don't want it to. Everything can be explicit if you need it to be. 

It's worth noting that this is only possible with a custom engine. If Arcade relied on 

 for our transforming, we'd be very limited with what kind of operations and optimizations we can perform.

The more we work on Arcade, the more we understand the depth of what a design token is. Each day it becomes 

Most of all though, we're excited to see how people might use these concepts in a way we never imagined. For us, it's all about empowering the designer and developer.

Today, most people would simplify design tokens by describing them as a key-value pair. A name and a value. However, we created a way for a single design token to have multiple values.

Dynamic Design Tokens

Design tokens are a new concept in design and development that simplifies how we think about supporting brands across different platforms. They enable a single collection of variable objects to power the design of web, iPhone, and Android products, as well as any other branding that a team may need.

There's no standard for working with design tokens, however there are efforts currently underway that are trying to standardize definitions and best practices. The effort is being tackled by a 

, individuals, startups, and established companies alike.

 have been building a design token manager for this reason and have been learning 

Design tokens are new. As we think about them and apply them in our workflows, our understanding will evolve. Two days ago while discussing Arcade, that happened to me.

It's going to challenge the current consensus of what a design token is. You've been warned! Here we go...

Design tokens only exist in a pre-processed state.

Once compiled and transformed, the output is 

Instead, it's simply what it is: a key value pair fit for the platform. A variable in a form the platform can understand.

The reason for this conclusion is because the purpose of a design token is to exist as a value, surrounded by context, ready to be transformed. When the design token goes through that transform process, 

That meta information is very important: it provides context to the token and instructions for how that token should be transformed.

For example in Arcade, we have a schema for our tokens that supports fine-grain control of how the rendering engine will handle that specific token. Should this token be ignored for a certain platform? Does the value change depending on the platform? Should we 

render this token in certain circumstances?

This is only some of the information that makes up a design token. 

Each token object grows more and more as we find more useful information that can be stored in them.

 Once that crucial information is gone though, we lose its transform-ability.

Think about it: we can go from our token source to CSS very easily. We can also go from our token source to Android very easily. But can we go from CSS to Android? No. Because 

we lost all of the meta information and rendering instructions

 that were included in the original, pre-rendered design token. Not only that, but the name and value might have completely changed from the source!

When explaining this concept to the team, I used a metaphor of a tomato. You can go from a tomato to pasta sauce 

. You can go from a tomato to a slice of it on a sandwich 

But can you go from sauce to a sliced tomato? No! Because that original tomato has been completely transformed and its original state is completely unrecognizable.

So moving forward, I'm going to be using this frame of thought when talking about design tokens. I can't see it any other way. 

While organizations might not have this expansive amount of information around their design tokens yet, I imagine they will soon

 to further enable their teams. Considering what 

Design tokens only exist in a pre-processed state in their source. Do you agree? Disagree? I'd like to hear what you think.

Once compiled and transformed, the output is no longer a design token. Instead, it's simply what it is: a key value pair fit for the platform. A variable in a form the platform can understand.

Design Tokens Only Exist In A Pre-Processed State

As creators, it's our responsibility to keep up with the demands of users and build the best possible experience for them. As time goes on, users' expectations rise as they see what is possible with current technology.

 great experience to show what is possible and to change our users' expectations forever.

Consider dark mode! Just five years ago it was somewhat of a rare feature. But now, users expect the option from almost every website they use.

That's what makes building a product so difficult: our users' needs are 

 to our user's needs and provide the best experience for them.

 And like I said before—if we don't, our competition will. And users will always go where the best experience is.

It you go back to 2010, you'll see the emergence of 

that makes web pages render well on a variety of devices

". While the title is referring to a web page that responds to different viewport sizes, I like to think that term has another meaning: 

the ability of a web page to respond to users' needs.

In 2021, we're entering a new stage of user's needs and expectations—Responsive Design 2.0. Today, users expect a certain amount of theming abilities and accessibility features. Take a look at this Tweet below covering the new 

This is becoming standard across all websites and applications. Designers and developers have to adapt their process of building new products to account for this new demand. And if they don't, your company will lose users, and subsequently lose value.

So, how can developers and designers meet this new need of theming, accessibility, and customization? Think about it from the very start. Prepare your code to handle these types of features. Focus on creating a reusable design system from the very start, and consider how 

 might power the components to create beautiful experiences like this.

Don't put it off either. The longer you wait to face this challenge, the harder it'll be to fix later on. And the longer you take, the more time you give your competition to eclipse your functionality.

So there you have it. Looking for something new to learn and master?

 Responsive Design 2.0: themes, accessibility, and customization

. Let the user specify their preferences and 

Responsive Design 2.0: themes, accessibility, and customization. It only takes one innovator with one great experience to show what is possible and to change our users' expectations forever.

Responsive Design 2.0

How do we solve big problems? We break them down into smaller ones. And each of these smaller problems have their own, tiny solution. So we go down the line finding little solutions to our little problems, one after another. Until soon enough, we realize we've solved enough little problems that we've reached our original goal and solved our big problem!

Designers and developers, you know what I mean.

Think of the last big thing you designed. The last big thing you coded. It took several little steps and areas of focus before you got to a place where you could give it the chef's kiss and say "It's finished. And it's beautiful."

So when I hear a company is struggling with "design consistency", "designer-developer synchronization", "design system governance"... 

But just because they're big problems, doesn't mean they need one big solution. Instead, let's solve these problems like we solve all of our big problems: with a bunch of smaller, more manageable answers.

In my opinion, the big problems I listed and several other organizational issues can be solved with the same little solution: design tokens.

For those of you that humorously just blew a little extra air out of your nose, let me elaborate.

Design tokens are not just variables. They're a new way of thinking. They break big, complex decisions into small, manageable answers. They push modularity and reusability to the extreme.

And most beautifully of all, they can be whatever you need them to be.

How do we solve big problems? We break them down into smaller ones. Let's push this to the extreme.

A Case For Design Tokens

In an effort to further close the gap between designers and developers, we're happy to announce that Arcade has partnered with Adobe and will be supporting the Design System Package (DSP) file format upon release.

It's an honor to join the Customer Advisory Board with other innovative teams such as the Google Material Design team, Microsoft, Knapsack, Specify and others, and we're excited to collaborate with Demian Borba and the rest of the Adobe team to make inter-tool design communication a reality. By managing your tokens in Arcade, you'll be able to export your tokens to a tokens.json file, allowing 

With Arcade, it doesn't matter who is making what changes where— your design decisions will live in one place, as one source of truth. Arcade's decision-context schema will enable your team to keep in sync and build better products, faster. By supporting DSP, teams can now funnel Arcade's unique context data into the DSP with ease.

In addition to DSP, Arcade will be supporting numerous outputs right out of the box. With our custom Arcade Engine under the hood, we're able to build these exports with ease. And that's kind of our thing. As we keep building, we'll be forming more partnerships to understand how best to serve the community's needs. And with the power of our Engine, many new export formats are to come.

So thank you, Adobe! We're excited to see how the community will use Arcade and the DSP export to better their workflow, and further bridge the gap between designers and developers. For more information about DSP, you can 

Arcade joins Adobe's customer advisory board for the new Design System Package (DSP) file format.

Closing the Gap - Supporting The Design System Package Format

Special thanks to Dr. Steven Weber of Drexel University, for introducing me to the subject. To 

, for inviting me to give a talk on the subject and inspiring this post. To 

Award-Winning Technology Products