If you're not already familiar, React Server Components allow you to split server and client rendering out between individual components, rather than having your entire app be one or the other. This means that on the server, you can securely call server-only APIs without leaking keys to the client. On the client, you can use browser APIs knowing that your code will only be run in the browser.

And for the optimization nerds (it's us, we're the optimization nerds) you can drop server-only dependencies from your client bundle, significantly reducing how much code you send down the pipe. All of this is only scratching the surface of RSC — you can read more about the benefits of RSC in Vercel's blog post [Understanding React Server Components](https://vercel.com/blog/understanding-react-server-components).

But let’s assume for the moment that you already know about RSC and you’re here to read a case study containing Significant Perf Gains. We have you covered there:

## **Experiment:** [**productonboarding.com**](http://productonboarding.com)

### **Setup**

We recently launched a free visual catalog of industry best-practices for product onboarding, which can be found on (you guessed it!) [productonboarding.com](http://productonboarding.com). The project leverages the latest version of Next.js as well as React Server Components served through the new [App Router](https://nextjs.org/docs/app). We use Frigade to power the email subscription flow at the top of the index page.

### **Methodology**

To test the performance of using Frigade with RSC, we built both an RSC Version of the website and a non-RSC version that uses the [Pages Router](https://nextjs.org/docs/pages). We then deployed the two different websites to Vercel and measured performance using the Pingdom Speedtest as well as Google's PageSpeed Insights test.

### **Results**

We saw a whopping 62% reduction in bundle size as well as as 63% improvement in Google's Speed Index on the RSC Version of the website. While we expected an improvement in the RSC version, we were surprised to see such a significant impact. While the served page size increased in the RSC version, it still got to the first contentful paint significantly faster than the client-side version, which had a smaller page size and a larger bundle.

![rsc-graphs.png](/uploads/rsc_graphs_22cc595389.png)

### **Conclusion and what's next**

Given the results of the experiment on our own code, we see demand for RSC-compatible libraries growing going forward. You really can’t argue with dropping more than half your bundle.

On a related note, the Frigade React SDK now works with React Server Components! Wild coincidence eh? If you're using Next.js 13, you can use [@frigade/react 1.36.4](https://github.com/FrigadeHQ/frigade-react) or higher with the [App Router](https://nextjs.org/docs/app).

large_rsc-cover.png

medium_rsc-cover.png

small_rsc-cover.png

thumbnail_rsc-cover.png

rsc-cover.png

React Server Components Made Our Site A LOT Faster

When building product onboarding (or any great software for that matter), you never want to reinvent the wheel. That's why we've recently built and launched [productonboarding.com](https://productonboarding.com), a curated visual library of the best product onboarding examples from across the web.

![CleanShot 2023-09-18 at 15.59.50@2x.png](/uploads/Clean_Shot_2023_09_18_at_15_59_50_2x_43ee95ff51.png)

We build a lot of product onboarding at Frigade, and over the last year we’ve put together an internal library of hundreds of product onboarding examples that we refer to all the time with customers. It helps them find and copy patterns that work at other companies so they don’t need to create net new experiences or A/B test their way into the best performing pattern from scratch.

Given it's been so useful, we've decided to open it up to the world. We bought productonboarding.com and have started adding examples from our collection and made them browsable and sortable. We hope productonboarding.com will help PMs, designers, and engineers discover the patterns that other great software companies use to onboard their users. And then more easily build them with Frigade, of course.

We’re planning to add new examples weekly and even code snippets to help you quickly copy the patterns you like most. Check it out and let us know what you think!

large_p0-cover.png

medium_p0-cover.png

small_p0-cover.png

thumbnail_p0-cover.png

p0-cover.png

Introducing ProductOnboarding.com

Onboarding is a critical part of the user experience for software products. It can have one of the largest impacts on customer activation and retention. However, onboarding experiences often go overlooked due to the time and effort needed to build them properly, especially without the right tools and knowledge.

At our last startup, my cofounder Christian and I were surprised at just how hard it was to get right. It took a ton of time that would otherwise have gone to our core product. We also knew that much better tooling was possible because we had experienced it in the internal tooling at LinkedIn, where we first met and started working together in 2015.

## The State of Onboarding

Established software companies such as LinkedIn, Uber, Pinterest, and many others invest in internal developer platforms to give their teams advantages like the ability to quickly build great onboarding experiences. But these platforms only get built at scale.

Today, many software teams build their own onboarding solutions and platforms from scratch, which is a challenging but necessary task. My cofounder and I have both done this in the past. It can be time-consuming, taking away from the development of the core product.

There are no-code tools for onboarding, but they’re rigid and clumsy. They’re designed for marketers and managers, not developers, so they don’t blend in with your product. They’re not part of your codebase, so they can break without teams noticing, and there are limits to what you can create with them. Unlike these tools, Frigade uses native SDKs and provides an API for developers to build new onboardings in code.

## Developer-First Product Onboarding

Frigade provides native SDKs and an API, allowing developers to build onboarding experiences with the same quality and flexibility as in-house solutions, but faster and with less effort.

* Set up onboarding Flows in **less than an hour**
* **Quickly modify and test** new onboarding variations
* Access to a library of **customizable drop-in UI components**
* Get immediate visibility into your **onboarding funnel and analytics**

## Our Investors

We're building the platform that we wished we had, and we’re pumped to have world-class investors along for the journey. We have raised $3M in seed funding led by Craft Ventures and La Famiglia with support from Y Combinator, Defy.vc, and Magic.fund. 

We also have a number of incredible individual investors who have experienced this problem firsthand:
* **Guillermo Rauch** (founder of Vercel)
* **Arash Ferdowsi** (founder of Dropbox)
* **Jean-Denis Greze** (CTO of Plaid)
* **Mads Johnsen** (CPO of Calm)
* And more

## Let's Do This

With Frigade, our goal is to develop the platform that every growth engineering team would love to have, but can’t afford to build themselves, and we're just getting started. If you're interested in using Frigade, joining our team, or just want to chat about onboarding, don't hesitate to reach out!

Frigade is free to sign up and get started. Create an account at [app.frigade.com/sign-up](https://app.frigade.com/sign-up) and start building!

**Eric Brownrout**, Co-founder, CEO

As reported originally by [SiliconANGLE](https://siliconangle.com/2023/07/20/frigade-secures-2-7m-funding-react-based-onboarding-solution/)

large_frigade-3m.png

medium_frigade-3m.png

small_frigade-3m.png

thumbnail_frigade-3m.png

frigade-3m.png

Frigade raises $3M in seed funding

If you're a SaaS startup, you have likely heard about SOC 2 compliance. If you've been putting it off, this article might convince you to get it started sooner than later. As we came to learn, SOC 2 comes with a series of great side effects that make you build your architecture and processs the right way from day one. I'll cover how Frigade went through this process as fast as it's legally possible without cutting corners or compromising on our product roadmap.

### What is SOC 2 compliance exactly and why should I care?
SOC 2 compliance is a set of standards created by the American Institute of CPAs (AICPA) that aims to ensure that companies that handle sensitive customer data have appropriate controls and safeguards in place. SOC 2 covers five Trust Services Criteria (TSC): security, availability, processing integrity, confidentiality, and privacy. Companies undergo an audit by an independent third party to assess whether they meet the SOC 2 standards. Achieving SOC 2 compliance can help companies gain a competitive edge by demonstrating their commitment to protecting customer data, and can open the door to selling to larger companies that require SOC 2 compliance from their vendors. There are two types of SOC 2 certification: Type I, which evaluates your security systems at a single point in time, and the more stringent Type II, which checks for compliance continuously over six months.

### Why get SOC 2 compliant sooner rather than later


Being SOC 2 compliant is essential when selling to larger companies. Enterprise companies take data protection seriously, and if you can demonstrate that you're SOC 2 compliant, you're more likely to win their business. Additionally, if you implement SOC 2 practices from day one, it will be less painful later on and reduce future throwaway work. This means you'll build your infrastructure in parallel with becoming compliant, allowing you to make better decisions early on and avoid cutting corners. For Frigade, this meant that we got to build our stack and process in parallel with our SOC 2 audit. It directly impacted our choice of service providers (avoiding future migrations),  setting up proper monitoring, multi-colo failover, backups, device encryption, and much more. These decisions would otherwise very likely have been put off or been made arbitrarily.

### How to become SOC 2 certified, fast.
The key to a fast and painless audit and certification is starting as early as possible. We started the process of becoming SOC 2 compliant shortly after incorporating Frigade despite still exploring different product ideas. **You do not need to have PMF to get SOC 2 certified** and unless you hard pivot into something radically different, your compliance should still stand.

Additionally, there are many other advantages to starting early on such as:

- **Small staff.**  With 2 founders as the only employees, the process for everything from background checks, anti-virus, disk encryption, and more was infinitely easier to set up than for a company with 20 employees.
- **Fresh stack.**  We built out our infrastructure based on SOC 2 requirements rather than migrating an existing stack.
- **No process.** If you're a small startup, you likely do not have any existing process that will need to be refactored. SOC 2 helps you set up proper on-call, monitoring, and HR. Measure twice, cut once.

Whether you're able to start early or not, the other thing that will help you significantly speed up the process is working with a modern Compliance as a Service company to complete the audit and certification. We worked with [Vanta](https://vanta.com), which helped us speed up and automate the process immensely, and [Drata](https://try.drata.com/) is a popular choice among startups as well. Most modern compliance companies offer integrations with AWS, Github, Google Drive, and dozens of other integrations that help automatically run SOC 2 compliance tests against your system to ensure you remain compliant. 

### Conclusion
Becoming SOC 2 compliant is an essential step for any SaaS product that wants to protect its customer's data and grow its business. If you're an ambitious SaaS company, we highly recommend getting it done sooner to expedite your growth and make the process as simple as possible. 


large_soc2.webp

medium_soc2.webp

small_soc2.webp

thumbnail_soc2.webp

soc2.webp

How we got SOC 2 (Type II) certified in just 3 months

We've all been there as frontend engineers. You want to show a user a tooltip, modal announcement, or some other UI element, but you don't want to show it to them every time they visit your site.

You want to show it to them once, and then never again. So what do you do? You store a cookie or something in `localStorage`, and then check for it every time the user visits your site.

In React, you would do something like this:

```
import React, { useState, useEffect } from 'react';

const App = () => {
  const [showTooltip, setShowTooltip] = useState(false);

  useEffect(() => {
    const hasSeenTooltip = localStorage.getItem('hasSeenTooltip');
    if (!hasSeenTooltip) {
      setShowTooltip(true);
      localStorage.setItem('hasSeenTooltip', true);
    }
  }, []);

  return (
    <div>
      {showTooltip && <Tooltip />}
      <RestOfApp />
    </div>
  );
};
```
Mission accomplished! What could go wrong? But then your PM pings you later that night on Slack and asks you why they are still seeing the tooltip when they opened up the website on their home computer.

This is when you try to explain that localStorage is scoped to the browser, not the user. So if a user opens up your site in Chrome and then opens it up in Firefox, they will see the tooltip again.

Okay, that's not too bad, right? A user sees the same tooltip twice, big whoop. But what about the 5 other tooltips you have on your site? And the announcement about your new cool feature? Now they have to see all of those again too.

In addition to that, `localStorage` comes with a few other problems:

1. Limited Data Storage: `localStorage` can only store string data, which severely restricts its usability. Storing anything more complex than a simple string becomes cumbersome and involves convoluted workarounds of endless serialization and deserialization.
2. Synchronous Operations: `localStorage` operates synchronously, meaning each operation runs one at a time. This can significantly slow down the runtime of complex applications, making it unfavorable for efficient performance.
3. Data Size Limitations: Across all major browsers, `localStorage` imposes a size limit of approximately 5MB. This restriction poses a significant challenge for developers working on data-intensive applications or those requiring offline functionality. Even though your application only uses a limited amount of data, third party libraries may silently be using up your quota.
4. Lack of Data Protection: `localStorage` lacks any form of data protection. Any JavaScript code on your page can access it freely, [raising serious security concerns](https://snyk.io/blog/is-localstorage-safe-to-use/). This disregard for data privacy has become a prominent issue and is particularly worrisome in recent years.

## How to actually do impression tracking

The solution is to use a service that is scoped to the user, not the browser. To implement this, you can build a simple key-value store API around your database, and then call it from your frontend. This way, you can store a key-value pair for each user, and then check for it every time they visit your site.

This would look something like this in React:

```
import React, { useState, useEffect } from 'react';

const App = () => {
  const [showTooltip, setShowTooltip] = useState(false);

  useEffect(() => {
    const fetchImpression = async () => {
      const hasSeenTooltip = await fetch('/api/userImpressions?key=hasSeenTooltip');
      if (!hasSeenTooltip) {
        setShowTooltip(true);
        await fetch('/api/userImpressions', { method: 'POST' });
      }
    };

    fetchImpression();
  }, []);

  return (
    <div>
      {showTooltip && <Tooltip />}
      <RestOfApp />
    </div>
  );
};
```

If you're using Node.js with Express and MongoDB, your API implementation would look something like this:

```
const express = require('express');

const app = express();

app.get('/api/userImpressions', async (req, res) => {
  const { key } = req.query;
  const user = await User.findOne({ _id: req.user._id });
  res.json(user.impressions[key]);
});

app.post('/api/userImpressions', async (req, res) => {
  const { key } = req.body;
  const user = await User.findOne({ _id: req.user._id });
  user.impressions[key] = true;
  await user.save();
  res.sendStatus(200);
});
```

This is a very simple implementation, but it gets the job done. You can now store any key-value pair for each user, and check for it every time they visit your site. This is a much better solution than using `localStorage` because it is scoped to the user, not the browser.

### Going beyond impression tracking

With any homegrown solution, things will start getting complicated fast. What if you want to show a tooltip to a user once every 6 months, but you want to reset that timer if they click on a button? Or say you're building a SaaS product and you want to show an announcement, but only to the account admin?

Beyond the simple binary flags of "seen" vs "not seen" there's also more nuanced progress you may want to track. Imagine for instance an onboarding checklist. Now, you're no longer trying to track a single item, but a whole sequence of actions that get checked off depending on your business logic.

Debugging also becomes harder. For instance, to understand why a user is not seeing a certain experience, you'll soon find yourself rolling up dashboards and scripts to help manage the data.

The above situation a common pitfall we all fall into. For instance, many companies start out building their own feature flag management platform from scratch in a similar fashion as the above example.  Things once again become more complex as your system evolves, and for that same reason many companies eventually mange to feature flag management platforms such as [Launch Darkly](https://launchdarkly.com) or [Posthog](https://posthog.com).

## Product Adoption as a Service

If you don't feel like rolling your own API and SDK to solve this problem, we built [Frigade](https://frigade.com) to handle all of this for you. Frigade comes with all the API and UI components you need to properly track user impressions and show the right UI elements to the right users at the right time.


large_local storage.png

medium_local storage.png

small_local storage.png

thumbnail_local storage.png

local storage.png

Stop storing impressions in localStorage

We recently announced that Stuart Norrie is joining Frigade as our Founding Designer. Well, good news comes in bunches.

Now, we're thrilled to share that Micah Snyder is joining us as our Founding Engineer!

Micah is an outstanding front-end engineer with experience building user interfaces, onboarding, and engineering design systems for companies such as Discord, Digit, and Digg.

He is passionate about developing systems and tools that help designers and developers create excellent software. He is thrilled to expand his engineering influence and passion delightful user experiences through Frigade.

Welcome to the team, Micah!


large_micah2.png

medium_micah2.png

small_micah2.png

thumbnail_micah2.png

micah2.png

Micah Snyder joins Frigade as Founding Engineer

Today we're pumped to announce that Stuart Norrie is joining the Frigade founding team to lead design.

Over the last 16 years, Stuart has refined his craft working on and leading design teams at companies such as Digit, Pulse, Meta, Hipstamatic, Strava, and more.

Stuart has designed onboarding for countless companies in his career, and he brings with him a fresh perspective on how we can rethink product onboarding through the lens of a cohesive, and flexible design system.

I feel incredibly fortunate to have crossed paths with Stuart as his product counterpart for two years at Digit. He is one of the most talented designers I have ever worked with, and we are incredibly fortunate to have him joining Frigade to lead our design efforts.

Welcome to the team, Stuart!


large_stuart.png

medium_stuart.png

small_stuart.png

thumbnail_stuart.png

stuart.png

Stuart Norrie joins Frigade as Founding Designer

> "Why did you pick the name Frigade?"

We get this question frequently. Frigade is a nonsense word so people are inherently curious about what it means and why we chose it. Well, the short and possibly disappointing answer is that it doesn't have any specific or punny meaning when it comes to product onboarding.

#### So, how did we settle on the name Frigade, then?

At a high level, we followed a simple framework made popular by Y Combinator, and we think this framework is useful to any founder thinking about naming their startup. The following was our guiding criteria for our name.

1. Do you own the .com for your name?
2. Can people pronounce it when they read it?
3. Can people spell it when they hear it?
4. Will people find it when they Google it?

#### Do you own the .com for your name?

Yep, we were able to get the .com, .ai, .so, .co, and more for a decent price.

#### Can people pronounce it when they read it?

Mostly! Frigade is combination of two real words: frigate and brigade. It's pronounced like the latter, though we occasionally hear people say it like the former.

#### Can people spell it when they hear it?

We ran spelling tests on friends, family, and former colleagues before making the purchase.

#### Will people find it when they Google it?

The advantage of a made up startup name is that there's not much competing on it. When we first launched, Google automatically showed results for "frigate" instead of Frigade. Now, with additional SEO hits, we are the number one result when someone Googles us.

## Lessons learned

We took this framework seriously since we learned the hard way with our last startup called Perform (joinperform.com). Perform was a great name for what we were building, but the problem was that it was also a great word for many other things. We never got close to the first page of Google search results, even when people were actively looking for us.

## Other names we considered

We churned through a ton of possible names for what is now Frigade. Check out the image at the top for some of our favorites from our search. You can use websites like Brand Bucket and Brandpa to find startup name domains. Enjoy and best of luck!

large_logos.png

medium_logos.png

small_logos.png

thumbnail_logos.png

logos.png

How to pick a good startup name

Today, we are excited to share that we are participating in Y Combinator's Winter 2023 cohort with Frigade, a new developer platform to build quality product onboarding, faster. 

Y Combinator is the preeminent startup accelerator and has helped build incredible companies like Stripe, Airbnb, and Doordash. We are thrilled to participate.

## What we're building
Onboarding is a critical first experience for software products. It makes a huge difference for customer activation and retention. However, onboarding experiences often do not get the attention they deserve because, without good tooling, they’re a pain to build.

At a previous startup, my cofounder and I were surprised at how hard it was to get right. It took a ton of time that would otherwise have gone to our core product. We also knew that much better tooling was possible because we had experienced it in the internal tooling at LinkedIn, where we worked at a previous job.

Established software companies such as LinkedIn, Uber, Pinterest, and many others invest in internal developer platforms to give their teams advantages like the ability to quickly build great onboarding experiences. But these platforms only get built at scale. With Frigade, our goal is to develop the platform that every growth engineering team would love to have, but can’t afford to build themselves.

There are no-code tools for onboarding (e.g. Pendo, Appcues, Intercom), but they’re rigid and clumsy. They’re built for marketers and managers rather than developers, so they sit on top of your product instead of feeling native. They’re not defined in your codebase, frequently break without teams noticing, and there are limits to what you can build with them. Unlike these tools, Frigade uses native SDKs and provides an API for developers to build new onboardings in code.

## How Frigade works
How to use Frigade in your product: first install our SDK (React for now); choose a production-ready Frigade UI component or go headless; create a “Frigade Flow” in our admin panel and hook it up to the SDK (Flows are where you set the logic, targeting, content, and more); publish your flow to go live.

Frigade automatically tracks users’ progress through your Flows. Your team can sign in to our admin panel to see which customers have completed what steps or input data, and you can use our API to sync tracking events to your analytics platform, send drip campaign (emails that guide users through setup), or show product reminders (e.g. “Finish connecting your data” banners). 

Frigade leverages server-driven UI, so once a Flow is live, you can easily update content (e.g. change copy, add another step) and logic (e.g. who should see it and when) in real-time without new code deploys.

## What's next?
We’ve spent most of our time building out the platform with early customers so far, but our self-serve flow is (ironically) coming soon. Please let us know if you’re interested in trying Frigade, we’d love to get your feedback on what we’ve built so far! We work mostly with web-based B2B companies today, and our pricing is competitive with other tools on the market.

Eric Brownrout, Cofounder @ Frigade



large_YC.png

medium_YC.png

small_YC.png

thumbnail_YC.png

YC.png

Frigade joins Y Combinator

Today, Christian Mathiesen and I have begun working on a new company called Frigade. We are tackling a problem that we have experienced firsthand, most recently while building our last startup from the ground up. This is an issue that is faced by all software businesses and which has an enormous impact on their success.

We're not quite ready to share more details, but we have started building the platform and can't wait to get Frigade into customers' hands. Stay tuned for updates on our progress and journey.

Eric Brownrout, Cofounder @ Frigade
