This was written on April 4, 2023. Some of this information may be outdated when you're reading it.

With the release of Next.js 13, there’s finally a framework to use React Server Components and all of its capabilities in a straightforward way. This is an overview of integrating Next.js 13 into an existing application.

Some cool features that we get access to in Next 13:

Layouts, error boundaries, and route handlers

Here are some acronyms I’m going to be using:

Usually when people mention RSC, it includes all of the concepts including streaming and suspense

These changes are big and are not instantly backwards-compatible with existing Next.js projects. Instead, Next now has a new `app` directory which enables these new features. The new app directory can live side by side with the new pages directory. For integrating with our code in lyceum, we’d keep all of our existing code in the pages folder and progressively add new work to the app directory as we see fit.

If you’re familiar with Next.js, you might be familiar with getServerSideProps and similar functions you can export from a file in the pages directory. To explain how RSC differs, let’s compare the different approaches:

A user enters a website URL, the browser makes a request to a server, and the server responds with barebones HTML with a JavaScript bundle of React code. The browser receives this and constructs the interface from that JavaScript code. Any future navigation is all client-side JavaScript, and any new data is sent from the browser to a server via API calls. Only upon a page refresh will the HTML and bundle get re-sent to the browser.

The bundle contains your whole application, which means it’s slow TTFB, slow FCP, slow TTI, and as a cherry on top, bad SEO and out of the box experience. Fun fact, React docs no longer suggests using Create-React-App anymore and instead recommends a framework that fully leverages its features (like Next.js).

When a URL is entered, the browser makes a request to the server, and the server will process the getServerSideProps logic and prerender an HTML page. The server will respond with that HTML page and the rest of the JavaScript bundle. Subsequent requests will use the bundle to navigate and construct other interfaces (usually, depending on if you use other Next processing features like getServerSideProps, getStaticProps/Paths). This is certainly an improvement over SPAs, because the prerendered HTML will lead to faster First Contentful Paint and Time To Interactive.

While an improvement over SPAs, we still have to send that huge JavaScript bundle, and only the initial page can be prerendered on the server. The broswer has to wait for that JavaScript bundle to send before it can become interactive, reducing TTI.

With React Server Components, the behavior starts out mostly the same. A browser makes a request to a server for a web page, and similarly to SSR, the data is fetched as the server prepares the initial HTML. However, RSC is able to see which components need 

data, so instead of waiting for that inital request to complete, it instantly sends components that don’t need data. A header, a sidebar, maybe a navigation. That HTML will be sent to the user right away (very fast FCP). When the server finishes processing that request, then the server will 

that HTML to the browser. Then, only the client components (will explain what this means) required for that page are bundled up and sent to the browser. This process happens on every request. So our HTML is streamed as fast as possible, our bundle is as small as possible, and everything that is static will be cached by the server so subsequent requests and navigations are 

These features make RSC really fast in each category:

Time To First Byte is faster because the server can pre-render Server Components as HTML and only Client Components are sent in the bundle.

First Contentful Paint is faster because the HTML is pre-rendered and sent before any data needs to be fetched.

Time To Interactive is faster because the JavaScript bundle is going to be much, much smaller, allowing the download to be fast and page to be functional sooner.

You probably noticed me mentioning these as if they’re different things. Well, in Next 13, they 

We can now specify which components are Server Components and which are Client Components.

Now, everything by default is a Server Component. You can think of a Server Component as requiring no React functionality (no hooks, no state, no user interaction like onChange). Layout components, menus, sidebars, a logo, etc are great examples. Server Components can also be async, so we can fetch data with await right inside them. I’ve found you can make 

components Server Components, as long as you pull out the interactive parts accordingly. Server Components 

Client Components are all the components that require interactivity. This includes onChange events, hooks, and state. By default, everything in Next 13 is a Server Component, so you have to specify "use client" at the top of your Client Components.

Next will error if you try to use them inappropriately. 

The new features of RSC gives us much more flexibility to improve performance across the application. Smaller bundle sizes, faster Time To First Byte, faster Time To Interactive, faster First Contentful Paint.

Admittedly, there are some hurdles to maintain speed of delivery on the engineering side:

Emotion is not fully supported with Next 13.

 Neither are most styling libraries, which makes using existing design systems difficult. We’re hoping that changes as soon as possible. We’d have to figure out a way to specify which components can be Server Components and which can be Client Components, and we want to ensure our design system can work with Next 13, while also working with our other repos that use regular React. There’s many unknowns regarding RSC and third party libraries, including the design system itself and its dependencies, so integrating would take experimentation.

There is definitely a learning curve to this new way of building applications. There would have to be education on these new features and how to write performant code. It’s easier than I’d like to accidentally block the server from returning initial HTML. Suspense & Streaming is really cool and can lead to excellent performance, but it’s not 

 to understand and requires a new understanding of React.

RSC is still in Beta, and Vercel claims Next.js 13 it isn’t stable and should not be used in production yet. We definitely don’t want to ship an unstable solution to our customers. That doesn’t mean we can’t start experimenting!

In this same vein, the docs are still being written, and so much knowledge around these concepts are not covered well. There’s very few StackOverflow threads, very few blogs solving specific problems, and thus, LLMs like ChatGPT are not yet trained. So this is very much an exploratory phase of the technology.

With the above issues in mind, it’s clear to see that immediate widespread adoption across engineering teams would be difficult. We’d have to take it one step at a time (maybe slower) for while before we can reasonably expect a developer to ship something using these features in a reasonable amount of time. Across the industry, it'll take several years before the understanding of RSC becomes more common.

React Server Components vs. Server-Side Rendering

Overview of potential challenges and opportunities when integrating Next.js 13 and the new app directory into an existing codebase.

Integrating Next.js 13 and React Server Components into an Existing Codebase

First time founders are obsessed with product.

Second time founders are obsessed with distribution.

This hits home. Undoubtedly our biggest struggle when creating companies in the past has been distribution. We spend months and months engineering the perfect product, then when you feel it’s ready, nobody uses it. We try marketing it, but after few successes, we move onto the next idea. This story probably rings true for many founders, and it’s one we see time and time again.

There are many reasons why this cycle exists. First and foremost, 

the founder is a builder and not a marketer

. This makes sense considering a product has to exist in order to market it (or does it?). Second, 

. It’s an unsexy problem to solve compared to building and styling your product. There’s a whole world of marketing knowledge and expertise to learn, it feels intimidating, and without intrinsic motivation, that hill may be too high to climb. Third, 

. By showing our product, we open up our work to criticism and rejection. Both being extremely likely for a new product. 

has a great section on this. When considering why a friend won’t finish a piece of work, this is how the philosopher responds:

He wants to leave the possibility of “I can do it if I try” open, by not committing to anything. He doesn’t want to expose his work to criticism, and he certainly doesn’t want to face the reality that he might produce an inferior piece of writing and face rejection. He wants to live inside that realm of possibilities, where he can say that he could do it if he only had the time, or that he could write if he just had the proper environment, and that he really does have the talent for it.

It’s easy to make excuses. It’s hard to do the thing and risk hurting your ego. The name of that book is fitting: it takes courage to be disliked. And only through being disliked will you find those who 

like you and your product. Or at least, learn enough to change your product so that more people do appreciate it.

However, this all relies on the fact that we market our products in the first place. Doing those aforementioned things is difficult while convincing yourself that 

 is easy. Except no product will succeed without distribution. So unfortunately, we must overcome this challenge or let our product die. Distribution is key.

Considering this is key, so my co-founder and I put together a simple plan. I focus on product, he focuses on distribution. Outlining the separation of concerns, while also enabling and encouraging collaboration, is our recipe for success.

First-time founders focus on product, second-time founders focus on distribution. Can we do both?

Mastering Product & Distribution

Sometimes, a simple website is exactly what a business needs. Short, sweet, and immediately gets to the point. However, in the case of Experienced Advisory Consultants (EAC), their website was simple to a fault. The design was outdated, unprofessional, and was certainly not driving any new clients to the business.

After about six months of iteration in design and development, EAC had a brand new website to call home:

With all development done in-house, the website is reliable, built with the latest technology, and ready for public use. Excellent scores in accessibility, performance, search engine optimization, and best practices. See it for yourself at 

So, how did we get here? Here’s a little about our process for designing the home page.

EAC came to us with clear parameters: they needed a new website that evoked professionalism and hinted at the cutting-edge nature of their business. A mixture of traditional and cutting-edge. While most of their existing clients were acquired through word-of-mouth, EAC also wanted their website to act as a funnel for new potential clients.


We began iterating immediately on designs:

With the first pass, we focused on more traditional designs. Their feedback would help us gauge exactly where they wanted to fall on the spectrum between traditional and modern design.


Feedback from those designs pushed us into a more modern approach. “Get rid of the stock images, remove the box-y shapes, make a more interesting hero.” Can do. Our next iteration pushed the envelope into more modern designs. Instead of stock images, we began experimenting with 3D graphics and simulations.

We even experimented with a dark mode version (this was a quick iteration, so many of the contrast values on overlapping elements are incorrect):

Dark-mode-first was not what they were looking for, but everything else was starting to connect. The text felt good, the layout was coming together; this design started to click for EAC. But we weren’t quite there. The simulation was too thin, not visible enough, and looked outdated. We needed something richer that matched the rest of the website. Something more pronounced, but still elegant.

At this point, we started to run into concerns about the old logo clashing with the new designs we were creating. We expected this, and initially offered to create a new logo, but the task wasn’t accepted into the statement of work so we had tabled it for later. Instead we decided to just modernize the existing logo. This included tracing into a vector shape and exporting it in multiple formats with different color schemes; SVG and PNG files of the logo in color, black, white, and with transparent or solid backgrounds.

This work came out great, but about halfway through our interface design iterations, the talks of a new logo were renewed. The goal wasn’t to completely redesign the logo, more so iterate on the current logo to match the designs of the new interface.

We first adjusted the proportions of the E in EAC to balance out the weight of the logo:

And eventually, we combined them all and started matching colors to the ones we saw in the interface:

This was our recommendation for use in the new website and general branding for the business. It never got adopted, but we’re proud of the work that went into the process.

At the same time this logo exploration was underway, we started to make progress on the landing page. We found a particle simulation library we could use to generate an interactive background for the landing page. Choosing a background color that meshed well with the simulation was our next challenge:

The consensus was, the light blue was a clear winner. However, the particle simulation wasn’t enough. It looked too thin and too basic for what we were looking for. Fortunately the particle simulation library we were using to generate the effects had a massive configuration API that we could use to customize the simulation. Here is some of the configuration object we used to make the effect:

After several iterations, we ended up with a configuration that was unique and in our opinion, looked great:

After some adjustments to the fonts and copy, we had our landing page.

This is some of the design work that went into the landing page of the new website. Many more sections, conversations, and deliberations occurred with every section of the website, leading to a result EAC is very happy with. We put an emphasis on accessibility and performance, and we keep all development in-house to ensure excellent results:

We encourage you to visit the new website and see the landing page in action, as well as the other sections and pages we created that required as much attention to detail: 

It was a pleasure to work with Mike and Carbonology on updating and institutionalizing our website. Mike prides himself on putting out great work, and he delivered with our newly revitalized website. He was easy to work with, extremely responsive, and put out an impressive, finished product. Every person that has seen our updated website has talked about how great it looked, and that is credit due to Mike and his team. We look forward to working with Mike again in the future.

How we designed and developed a new website for EAC, a leader in the financial outsourcing industry.

A New Home for Experienced Advisory Consultants

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 

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.

Integrating Next.js 13 and React Server Components into an Existing Codebase

Mastering Product & Distribution

A New Home for Experienced Advisory Consultants

Say No To Premature Optimization

The Payments Dilemma

How To Make Your Social Network Succeed

Define Launch

Dynamic Design Tokens

Design Tokens Only Exist In A Pre-Processed State

Responsive Design 2.0

A Case For Design Tokens

Closing the Gap - Supporting The Design System Package Format

The Billion Dollar Value of Immovability

A Launch Into The Unknown