- 
+ 
- -We hope to see you in [Discord](https://discord.gg/sst) soon! - -PS: The Slack community will be around while we transition. diff --git a/_posts/2022-06-25-sst-dev.md b/_posts/2022-06-25-sst-dev.md deleted file mode 100644 index ad0e11fe8..000000000 --- a/_posts/2022-06-25-sst-dev.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -layout: blog -title: SST.dev -author: jay ---- - -We are now officially changing our name from Serverless Stack to SST. We are also moving our domain from [serverless-stack.com](https://serverless-stack.com) to [sst.dev](https://sst.dev). - -We were previously called Serverless Stack and we were hosted at serverless-stack.com. Aside from being really long, it was also easy to confuse us with the Serverless Framework folks. We've been informally using SST but now with the new domain, we can make the change official! - -You can call us **SST** and visit us at [**sst.dev**](https://sst.dev)! diff --git a/_posts/2022-06-28-create-sst.md b/_posts/2022-06-28-create-sst.md deleted file mode 100644 index 36bad0cb8..000000000 --- a/_posts/2022-06-28-create-sst.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -layout: blog -title: "`create sst`" -author: jay ---- - -Today we are launching [`create sst`](https://github.com/sst/sst/tree/master/packages/create-sst) — a CLI that helps you get started with SST. It creates a full-stack starter that you can use to build your serverless applications. - -While serverless has been around for a few years, there isn't a [Twelve-Factor App](https://12factor.net) setup for it. - -With `create sst`, we are trying to bake a lot of these principles into a starter that you can use right away. Simply run: - -```bash -$ npm init sst -``` - -This will bootstrap a full-stack serverless application with end to end type-safety: - -- RDS as the database (with an option to use DynamoDB) - - [Kysely](https://github.com/koskimas/kysely) for SQL - - [ElectroDB](https://github.com/tywalch/electrodb) for DynamoDB -- GraphQL as the API - - [Pothos](https://pothos-graphql.dev) for building GraphQL schemas -- React as the frontend - -It also does a few other things that you can step through using a new tutorial we added in our docs: [docs.sst.dev/learn](https://docs.sst.dev/learn/) - -## Launch event - -We livestreamed the `create sst` launch event. You can [check it out on YouTube](https://www.youtube.com/watch?v=wBTDkLIyMhw). - -We recently hit a big milestone for the SST community Slack.
— Jay (@jayair) June 10, 2022
2000+ members in a little over a year!
But we've been considering a move to Discord.
Let me share what's been going on because I'd like to hear what people think. https://t.co/pjtRx5UVBF
](https://twitter.com/funcOfJoe/status/1690115160877535232)
-
-We decided to build a prototype a couple of months ago. We worked with the Pulumi team and founders closely to understand how their system works. We figured out how we could create a fully open source deployment experience with the Pulumi deployment engine and their bridged Terraform providers.
-
-You simply install the SST CLI globally, create an `sst.config.ts`, and run `sst deploy`. There's nothing else to install, there are no `node_modules`, no CDK version conflicts, no services to sign up for, and no black boxes. Everything runs on your local machine.
-
----
-
-# How Does Ion Work
-
-In Ion you define your infrastructure almost exactly like you do in SST today. Except instead of using CDK underneath it uses a TS version of the underlying Terraform provider. Note that Terraform providers are written in Go and are basically calls to the AWS SDK. There's some additional code to make sure these run safely, so you aren't hammering AWS.
-
-When you run `sst deploy`, those resources make a call to an embedded Pulumi engine that makes a call to their bridged Terraform provider, and this makes the AWS SDK calls to create your resources. A _bridged Terraform provider_ is a Pulumi provider that's programmatically bridged to the underlying Terraform Go provider.
-
-If you are familiar with Terraform you might be wondering, isn't Terraform like CloudFormation templates in that you write JSON or HCL. When you deploy these templates through the Terraform engine, it translates these to calls to the Terraform Go providers for those resources. In Ion's case we don't use the Terraform engine, we use Pulumi.
-
-> You don't need to install Pulumi or Terraform or sign up for anything.
-
-You don't need to install Pulumi or sign up for it, their engine is embedded in the Ion CLI. Your deployments create a state file locally that are synced with an S3 bucket in your AWS account.
-
-There are a couple of key things with this model that pretty much addresses all the above issues.
-
-1. The code is executed exactly how you write it. The deployment engine is run from your local machine and it creates the resources directly. There is no layer or service in between.
-2. This simple execution order means there are no cyclical dependencies. If you have a linked resource, you need to create it in the order it is used.
-3. If you want to do something like the CloudFront and Lambda function example, where you want to set the distribution URL back into the function environment, you'll need to create a *dynamic provider*, this is basically code that's going to run locally after those resources have both been created. Again, the code you write is what's being executed and deployed. It's Infrastructure as Code.
-4. Any deployment errors are displayed directly and in full.
-5. Importing resources is a lot easier because you have visibility and control over the state of your deployment.
-
-> The code you write is what's being executed and deployed. It's Infrastructure as Code.
-
-This model isn't all perfect. Over the last couple of months we've had to work around some issues. But we have a couple of key tools at our disposal.
-
-1. We can submit PRs to Terraform providers, since these are open source.
-2. There is a process of patching Terraform providers if the changes in the PR are urgent.
-3. We can also fork the provider if necessary and create our own.
-4. We talk to the Pulumi team regularly and can work with them to find fixes or work arounds.
-
-The upshot is that we are not dealing with the CloudFormation black box. So we can ultimately do something about the problems we run into.
-
----
-
-# Roadmap
-
-Let's look at where we are currently and what we've done for Ion so far.
-
-#### Step 0: Ion Prototype Demo
-
-Status: *Complete*
-
-- Created a prototype by embedding the Pulumi engine
-- Created a repo for Ion on [GitHub](https://github.com/sst/ion)
-- Implemented the most complicated SST construct in Ion — Next.js
-- Implemented a few other components, including a new Vector component based on Amazon Bedrock
-- Built a complete full-stack demo application with Ion — [movies.sst.dev](https://movies.sst.dev)
-
-You can view the repo for our demo movies app on [GitHub](https://github.com/sst/demo-ai-app). The entire SST team worked on this app and it was great watching all the CDK issues we listed basically vanish.
-
-#### Step 1: Ion General Release
-
-Timeline: *Couple of weeks from now*
-
-Here's what we need to do next for a general release.
-
-- Implement a few more components and CLI features
-- Write up the docs
-- Do a lot of testing
-- Launch a new site — `ion.sst.dev`
-
-At this point you'll be able to create new apps from scratch in Ion. It'll give you a chance to try it out. We'll be directing new users that want to get started with SST to start with Ion first.
-
-#### Step 2: Ion → SST v3
-
-Timeline: *Couple of months from now*
-
-Once Ion is stable, it'll give current SST users an opportunity to migrate their apps to Ion. We'll create some tools and documentation that'll help with this process.
-
-Once we feel comfortable with it and we know many people will be able to move over, we'll set a date for the SST v3 release. This is when `ion.sst.dev` will become `sst.dev` and it'll become SST v3. While SST v2's docs will be moved to a separate site.
-
----
-
-# What About SST v2
-
-So what happens to SST v2 once Ion becomes SST v3? Here's what we are planning:
-
-- We'll release updates
-- We'll accept PRs
-- We won't add new constructs
-- We won't introduce breaking changes
-
-There might be caveats here of course but we are planning to let the community drive a lot of what happens with SST v2.
-
----
-
-# What About Migrating
-
-Ion is obviously a big change. If you are using mostly SST constructs in your apps, the migration won't be a big problem.
-
-But what if you are using a ton of CDK constructs currently in your SST apps? There are two types of these:
-
-1. L1s or low level CDK constructs
-
- This is far easier to move over because the Terraform AWS providers have support for these.
-
-2. High level CDK constructs
-
- But CDK is filled with a ton of high level constructs, especially ones that use the Custom Resource hack described above to make changes that are not in CloudFormation (and also not in Terraform).
-
-The latter tends to be really messy. There is no way to sugar coat this. Migrating those over is not going to be easy. We'd argue that the new Ion model is better but there are no drop-in replacements for those. You could leave your old SST app around with those resources and not move them over. They'll continue to work because SST v2 isn't going anywhere.
-
-We'll share more details on the migrations steps through the Ion docs. But in the long run you might have to make a choice.
-
-#### Is Ion Right For Me
-
-That brings me to something we should address directly. If your company is completely invested in the CDK & CFN model and you were using SST because of its strong ties to CDK; Ion is probably not going to be right for you. We'd still invite you to give it a try and build something non-trivial with it. But we know some folks are married to CDK.
-
-In this case, the solution would be to migrate your SST apps to CDK when you can. At the end of the day, SST v2 is open source and built on CDK. We chose this architecture because we did not want you to be locked in to us in case something happened.
-
-#### What Ion Is Not
-
-It's also worth mentioning what we are not trying to be. We are not trying to be an extension of CDK or Terraform or Pulumi. We are not AWS purists.
-
-So if you are choosing SST or Ion because it's basically CDK or Terraform but *nicer*, you might end up disappointed. SST is fundamentally trying to create something that didn't exist before. We've discovered many of our design patterns as a result of our personal experience with building products and working with teams that are doing the same.
-
----
-
-# What's Our Goal
-
-So then what is our goal? Why are we doing all of this?
-
-We want SST to be the best way to deploy an application. Let's take an example. This `sst.config.ts` is based on the movies demo from above. It includes AWS, OpenAI, and Cloudflare as components.
-
-```ts
-const db = new aws.dynamodb.Table("Movies");
-
-const bucket = new sst.Bucket("Assets");
-
-const vector = new sst.Vector("Vector", {
- openAiApiKey: new sst.Secret("OpenAiApiKey").value,
-});
-
-const site = new sst.Nextjs("Web", {
- link: [db, bucket, vector],
-});
-
-new cloudflare.cdn("Cdn", {
- domain: "movies.sst.dev",
- route: {
- "/": site.url,
- },
-});
-```
-
-We want you to be able to drop a single type-safe config file in your repo root, and run `sst deploy`. This should be able to create any kind of resource, in any cloud provider, and link them all together. We also want you to be able to customize any of this to the degree that the provider will let you.
-
-> Drop a type-safe config file and deploy it with a single command.
-
-We want the best possible developer experience for this idea. And to accomplish it we need to bet on tools that we think will get us there.
-
----
-
-# FAQ
-
-I'm sure you have a lot of questions. I'm going to try and add to this section as I address more of them.
-
-#### 1. Is Ion completely open source and self hosted?
-
-Yes it's open source and it'll run on your local machine without you having to sign up for anything Pulumi or Terraform related.
-
-#### 2. Our company only uses AWS, can we still use Ion?
-
-Yes. While Ion will support multiple providers, if you are using AWS it will deploy completely to your AWS account. There won't be any other services or providers involved outside of the one you choose.
-
-#### 3. Isn't Terraform not open source anymore?
-
-There's been some recent fallout from the Terraform licensing change but that applies to the Terraform engine itself. Ion doesn't use this.
-
-#### 4. What happens to the SST Console?
-
-It'll support Ion and SST v2 apps. We have some plans for making it easy to self-host the Console. We'll share more details once we launch Ion.
diff --git a/_sass/theme/_layout.scss b/_sass/theme/_layout.scss
index e273cb31c..46556e4cd 100644
--- a/_sass/theme/_layout.scss
+++ b/_sass/theme/_layout.scss
@@ -248,6 +248,12 @@
margin-top: calc($spacing-unit / 2 + 5px);
}
+ @include media-query($on-palm) {
+ &:after {
+ margin-top: calc($spacing-unit / 2);
+ }
+ }
+
@include media-query($on-laptop) {
padding: calc($spacing-unit / 2) calc($spacing-unit / 2) 0;
}
@@ -342,6 +348,12 @@
}
}
}
+
+ @include media-query($on-palm) {
+ .col1 {
+ margin-bottom: 0;
+ }
+ }
}
}
@@ -527,7 +539,7 @@
.site-author {
margin: 0;
- text-align: center;
+ text-align: right;
font-size: 16px;
color: $tertiary-text-color;
@@ -535,6 +547,11 @@
@extend %a-tertiary;
}
}
+ @include media-query($on-laptop) {
+ .site-author {
+ text-align: center;
+ }
+ }
}
//
//.footer-heading {
@@ -558,7 +575,7 @@
}
.footer-col {
- margin-bottom: 2 * $spacing-unit - 5px;
+ /* margin-bottom: 2 * $spacing-unit - 5px; */
margin-right: 1.5 * $spacing-unit;
@include media-query($on-laptop) {
@@ -568,60 +585,63 @@
&.footer-col-1 {
text-align: left;
flex: 1 0 auto;
+ display: flex;
+ align-items: center;
@include media-query($on-laptop) {
+ display: block;
text-align: center;
}
}
- &.footer-col-2 {
- flex: 1 0 auto;
- display: flex;
- flex-wrap: wrap;
-
- @include media-query($on-laptop) {
- margin-bottom: $spacing-unit;
- justify-content: center;
- }
-
- & > ul {
- @include media-query($on-laptop) {
- margin-left: 0;
- }
- }
-
- & > ul:not(:last-child) {
- margin-right: 2 * $spacing-unit;
+ /* &.footer-col-2 { */
+ /* flex: 1 0 auto; */
+ /* display: flex; */
+ /* flex-wrap: wrap; */
+ /**/
+ /* @include media-query($on-laptop) { */
+ /* margin-bottom: $spacing-unit; */
+ /* justify-content: center; */
+ /* } */
+ /**/
+ /* & > ul { */
+ /* @include media-query($on-laptop) { */
+ /* margin-left: 0; */
+ /* } */
+ /* } */
+ /**/
+ /* & > ul:not(:last-child) { */
+ /* margin-right: 2 * $spacing-unit; */
+ /**/
+ /* @include media-query($on-laptop) { */
+ /* margin-right: 1.5 * $spacing-unit; */
+ /* } */
+ /* @include media-query($on-palm) { */
+ /* margin-right: $spacing-unit; */
+ /* } */
+ /* } */
+ /* } */
- @include media-query($on-laptop) {
- margin-right: 1.5 * $spacing-unit;
- }
- @include media-query($on-palm) {
- margin-right: $spacing-unit;
- }
- }
- }
-
- &.footer-col-3 {
- margin-bottom: $spacing-unit;
+ &.footer-col-2 {
+ /* margin-bottom: $spacing-unit; */
margin-right: 0;
flex: 0 1 auto;
max-width: 450px;
}
- a.author-link {
- @extend %a-tertiary;
- font-weight: bold;
- }
-
- a.email-link,
- a.page-link {
- font-weight: 400;
- line-height: 2;
- }
+ /* a.author-link { */
+ /* @extend %a-tertiary; */
+ /* font-weight: bold; */
+ /* } */
+ /**/
+ /* a.email-link, */
+ /* a.page-link { */
+ /* font-weight: 400; */
+ /* line-height: 2; */
+ /* } */
.social-links {
- margin-top: $spacing-unit;
+ margin-bottom: 7px;
@extend %social-buttons;
@include media-query($on-laptop) {
@@ -940,6 +960,8 @@
}
.post-archives {
margin-top: 20px;
+ border-top: 1px solid $grey-color-light;
+ padding-top: $spacing-unit * 0.5;
color: $text-color;
font-weight: 600;
font-style: italic;
diff --git a/about/culture.md b/about/culture.md
deleted file mode 100644
index 059a67c6f..000000000
--- a/about/culture.md
+++ /dev/null
@@ -1,221 +0,0 @@
----
-layout: page
-title: How We Work
-editable: true
-description: This document is meant to be used as a user manual for SST team. In it we go over our cultural values and how we operate as a team.
----
-
-In this document we'll go over the cultural values that drive our team at SST. But before we get to these values, we want to go over a few things. We want to look at what we are building, why we are building it, and how we operate as a team. This'll give us a good sense of where our cultural values come from and why they matter to us.
-
-Here's what we'll be covering in this document.
-
-- [Background](#background)
-- [Our vision](#our-vision)
-- [How we build products](#how-we-build-products)
-- [How we operate as a team](#how-we-operate-as-a-team)
-- [Cultural values](#cultural-values)
-
-Let's get started!
-
-## About this document
-
-This document is meant to be used as a user manual for SST team. We think sharing it publicly serves two purposes:
-
-1. It helps the community get a better sense of how we operate.
-2. And, it helps keep us accountable to the standards we set.
-
-This document is a work in progress. If you have feedback on what's covered here, or have suggestions on what we should add, please let us know.
-
-## Background
-
-### What is serverless
-
-Serverless is a new way of building applications. Developers use infrastructure-as-code to define and provision fully-managed services. Resources are provisioned programmatically and the pricing is completely usage based.
-
-> Serverless is a perfect fit for startups.
-
-Since the infrastructure is fully-managed and completely programmable, a single developer should be able to build an application that scales to millions of users with no operational overhead.
-
-It's a perfect fit for a startup.
-
-### Problems with serverless
-
-However, there are few different problems with adopting serverless. Let’s just focus on the two biggest issues for now:
-
-1. It's extremely complicated to configure. This follows from the fact that a serverless application is a combination of at least a handful of fully-managed services. Each service has a large number of configurable options.
-2. The development feedback loop is broken. Since these applications are completely based in the cloud. Testing them requires you to either mock these services locally or redeploy them to test.
-
-## Our vision
-
-We think every startup should be built using serverless and we want to create a platform that makes this possible. They should be able to get started by using our platform. And continue to use it as their application and company grows. In a sense, they should be able to use our platform to go from _idea to IPO_.
-
-> Build a platform that a startup can use to go from idea to IPO.
-
-This means that our platform needs to be both:
-
-1. Easy to get started, by abstracting out the complexity of the underlying services.
-2. And completely configurable, allowing you to use the full power of the underlying cloud services.
-
-## How we build products
-
-Building a platform that's both easy to get started and completely configurable is a challenge. There are a broad number of use cases and each use case needs to be configurable. In a sense, the problem space is both wide and deep.
-
-Problems like these are a good fit for open source. Users of open source projects tend to naturally extend the use cases of the project. This is observed in the long-tail of use cases that an open source project addresses. Especially in comparison to its closed source counterparts.
-
-Users of open source software are also far more willing to provide feedback, when compared to closed source software. Whether it is sharing key information about their problems or even collaborating to solve it. We noticed that the sense of altruism amongst open source users leads to a much higher bandwidth of feedback.
-
-> The sense of altruism amongst open source users leads to a much higher bandwidth of feedback.
-
-The two above ideas together create a virtuous cycle that effectively describes how we build our products.
-
-1. Open source users extend our products to other use cases.
-2. They run into some problems with them.
-3. They provide us with detailed feedback, as only open source users can.
-4. This feedback allows us to do a good job while addressing their issue.
-5. This leads to our users being excited to try it for additional use cases.
-6. And the cycle continues.
-
-This virtuous cycle lets us traverse the problem space while prioritizing our user's needs. It also presents us with natural growth opportunities for the business.
-
-Let’s look at what this means practically. Starting with how we implement feature requests.
-
-### How we implement features
-
-Here’s a rough step-by-step process that we try to follow.
-
-Let’s assume we get a message on Discord or somebody opens an issue on GitHub.
-
-1. Start by understanding what the user is trying to do.
- - If it’s a bug, understand what's causing it. We don't need to have a solution, but we need to get all the information required to debug the issue. It's harder to get the user to send you debug information after they’ve moved on.
- - If it is a feature request, understand what the user is trying to achieve. Listen to their problems, not their solutions.
-2. Then we create a GitHub issue with:
- - Everything that was talked about
- - List of all the places that it’s been brought up in
- - List of all the people that’ve brought it up
- - If the issue has been brought up before, add the new person to the list
-3. After we understand the problem, figure out if it’s straightforward to implement or if we need to design a solution.
- - A straightforward solution usually includes bug fixes or features that don’t change the overall design of the product.
- - On the other hand, if the solution isn’t obvious or is a bigger change, we need to make some design decisions (more on this below). For design decisions, get the team involved.
- - Before the group discussion, come up with a proposed solution.
- - If the issue is urgent, don't hesitate to get somebody’s time. The leadership team needs to be on-call for urgent issues.
- - If the issue is not urgent, you can book a time on somebody's calendar. Or bring it up in the 1 on 1.
-4. We then propose the solution to the user. Preferably with code snippets, and ask the user if it solves their issue.
-5. Update the GitHub issue with the proposed solution. For something that's really simple to implement, we can skip this step.
-6. We figure out the priority for this issue and when we are going to work on it. More on this below.
-7. If you are working on it right now, tell the people that reported the issue. They are likely to help if you need some additional feedback.
-8. Implement the solution in a PR. You can read more about PRs and cutting releases in our [CONTRIBUTING.md]({{ site.sst_github_repo }}/blob/master/CONTRIBUTING.md).
-9. If the new feature has a new name or it's a new option, review the naming with the team.
-10. Write a doc for it and add it to the PR. It doesn’t have to be perfect but it needs to be functional. The copy will be reviewed later but the content needs to be figured out upfront.
-11. Cut a release. In the release notes mention how to use the feature.
-12. Tell everybody that requested it about the release. Mention the version number, so they can upgrade to it.
-13. Announce the release in Discord, with a snippet on how to use the feature.
-14. Make a list of all the copy and docs changes that need to be reviewed, create an issue and send it to the team.
-
-The key here is that it’s easier to gather the requirements and understand the problem when it’s first reported. Even if we don’t end up implementing the fix right away, users are far more engaged when the issue is first reported. We want to figure out a solution and get it validated by our users as early as possible. And document everything in a GitHub issue.
-
-> We want to figure out a solution and get it validated by our users as early as possible.
-
-We also want to notify users when we release a fix. It shows them that we personally care. And it makes it more likely that they'll give us feedback in the future.
-
-### How we prioritize what to work on
-
-We have a rough flowchart that we use to prioritize features. This will evolve as the priorities of the team changes.
-
-Is there a user blocked by the issue or feature request?
-
-- Yes ⇒ Fix it now
-- No ⇒ Is the issue related to a new user's experience?
- - Yes ⇒ Fix it now
- - No ⇒ Is it a quick change (will take less than 30mins to implement)?
- - Yes ⇒ Mark it as High priority
- - No ⇒ Has it been brought up before?
- - Yes ⇒ Mark it as High priority (bumped up from Low)
- - No ⇒ Mark it as Low priority
-
-So the priorities look like: "Fix it now", "High", or "Low". The "Fix it now" ones are the urgent issues that we work on right away. While the "High" priority ones are the issues that we are currently working on (when there's nothing urgent). The "Low" priority ones don't get worked on until we've run out of the "High" priority issues. Or they get bumped in priority.
-
-For the "Fix it now" and "High" priority issues, we tell the user the timeline for the fix (today or tomorrow vs this week or next week). On the other hand, for low priority issues we tell them we won’t get to it right away. But ask them to let us know if it becomes a blocker and we’ll bump it up in priority.
-
-While the above flow can seem a bit rigid, there are a couple of caveats. For example, we might prioritize a feature differently:
-
-- If it's being requested by a valued member of our community
-- If a person that's trying to contribute to the project needs it
-- If you think we can solve it in a novel way and it can have a big impact
-
-Feel free to pull the leadership team in, if you need any help. We hope that over time you are able to build a better sense of how to prioritize features.
-
-### Our design process
-
-As mentioned above, there are some issues that are not straightforward to implement. They require a certain amount of design. These are typically issues that have multiple solutions and it's not immediately clear which approach makes sense. It's important that we have cohesively designed products that work well together. We also care about making our products intuitive to use. This means that for some issues we need to put a lot more thought while designing a solution. We employ a "design" meeting to work through this. It usually involves:
-
-1. Understanding the root cause of the problem we are trying to solve.
-2. Looking at the prior art in the field and understanding their pros and cons.
-3. Weighing the different approaches we can take to solve the problem.
- - This involves putting together pseudo code or demos for the team to evaluate.
- - It's much easier to evaluate possible options based on something real.
-4. Making sure that the proposed solution works with the design choices made across our other products.
-
-It's important that we work through this process on our own, before a design meeting. The rest of the leadership team is there to help you make a decision. And it allows you to get better at making these decisions.
-
-> It's important to work through the design process on your own, before meeting with the team.
-
-It should also be mentioned that it's the responsibility of the leadership team to not make these meetings a blocker. If a feature needs to be implemented urgently, they are on-call for these meetings.
-
-### Naming things
-
-We also like to take care while naming features, config options, props, etc. For anything new:
-
-1. Suggest what you'd like to name it and why.
-2. Offer two other suggestions and what you like about them.
-3. Post this in the team channel. The rest of the team will quickly vote on them or add their own suggestions.
-
-Coming up with a good name can sometimes be hard. But it's worth thinking it through, especially for things that can be hard to rename later.
-
-## How we operate as a team
-
-The above should give you some sense of how we operate internally as a team. But let's look at it in a little more detail. We’ll look at it from the perspective of an engineer that’s building our products.
-
-The process of talking to users and building products is the core engine that drives our team. This implies a couple of things:
-
-- We want the entire product process to be run independently by our engineers.
-- This includes talking to users, gathering requirements, proposing solutions, implementing them, releasing them, and notifying our users.
-- We want to reduce the number of people an engineer needs to talk to internally to get something done.
-- For the cases where we need the leadership team’s input on design, we want to ensure that the leadership team is always available to provide feedback.
-- We also want each engineer to have ownership of specific parts of the product and manage the roadmap for it.
-- Keep track of the key input and output metrics of the product to drive its growth.
-
-The role of the leadership team is to give an engineer as much autonomy as possible and to make sure the product process is running smoothly.
-
-## Cultural values
-
-All of this leads us to our core tenets, our cultural values.
-
-### Having a services mindset
-
-We need to remind ourselves that our users are using our products to get their jobs done. While they need help with our products, it’s because there is a bigger purpose to what they are doing. So our mindset while interacting with our users should be helping them get to where they want to go.
-
-There's an unhealthy power dynamic in large communities between the "in" crowd and the new folks. We need to avoid this by having a high degree of empathy. No issue is too small or too trivial or too dumb. It’s our job to make sure the user is able to do what they want to do through our products.
-
-### Thinking as a user and paying attention to the details
-
-While we are trying to help our users build their products we are not merely providing “support” or “services”. We are trying to figure out how our products can do a better job for them. We need to pay attention to the details of their experience. This doesn’t always mean making big changes to our products. It could be something as simple as clarifying some small details in our docs. We need to think as a user and use their feedback to improve the product.
-
-As a team, we rely heavily on our users to guide our product roadmap. So it’s important that as engineers we spend time thinking about all the little details of their experience. This information helps us make better product decisions. And ultimately lets us make something that people want.
-
-### Having good taste
-
-A lot of the key products and features that we work on, require us to make design decisions on behalf of our users. In an industry where most solutions are overly complicated, we need to be able to design intuitive products that are easy to use. It also matters that we use similar design principles across our products, so as to minimize the number of concepts a user has to learn.
-
-We need to have a high personal bar when it comes to design. Design in our case is about all the small decisions we make while creating our products. We need to weigh our options carefully and try to make the right tradeoffs. This also makes our users feel that there was a certain degree of care that was taken while building it.
-
-### Moving with urgency
-
-As noted in the product process above, it’s important that we respond in a timely manner and gather feedback quickly. It’s important to capture feedback before the user moves on. Similarly, it’s important to push out features right when they need them.
-
-Moving with a sense of urgency that’s driven by user feedback allows us to delight users, build community engagement, and foster a culture internally that’s exciting to be a part of.
-
-### Taking ownership
-
-We want our engineers to run the entire product process. We want them to take on a part of the product and drive the roadmap completely. We want them to select the KPIs, set the goals, and take part in our weekly and monthly reviews as a representative of that product.
-
-We think it's naturally motivating to be responsible for building something that solves a problem for somebody else. So we want to create an environment where it's possible to take ownership of that entire process.
diff --git a/about/index.html b/about/index.html
deleted file mode 100644
index 22e67c7b5..000000000
--- a/about/index.html
+++ /dev/null
@@ -1,214 +0,0 @@
----
-layout: lander
-title: About Us
-description: SST is making it easy to build full-stack serverless applications. We've created an open source framework called SST, a guide for building serverless apps, and Seed; a service for teams to manage their serverless apps.
----
-
-
- 
- Founded with the sole purpose of making it easy to build serverless applications. We want to make sure you have everything you need to build great products.
-
- The SST Guide is the most widely read resource for building full-stack serverless apps. Follow our step-by-step guide and build a React.js app with a serverless backend.
-
- SST is an open source framework for building modern full-stack applications on AWS. Deploy Next.js, Remix, Astro sites and add any backend feature.
-
- Seed is the easiest way for teams to deploy and manage their serverless applications. It'll incrementally deploy your functions and send you real-time alerts when they fail.
-Originally founded by Jay V and Frank Wang in San Francisco. We now run distributed teams across the globe. We've written about how we work. So if you are passionate about developer tools, we would love for you to join our team!
- -
- We are lucky to have some of the greatest investors of Silicon Valley on our side.
-
- 
-
- Founded LinkedIn
-Founded PayPal
-Founded YouTube
-Founded Yelp
-Founded MySpace
-Founded BitTorrent Inc.
-Founded Hot or Not
-Founded Hot or Not
-Investor
-Investor
-Investors
-A huge thanks to all our contributors and community members.
- -We want to build the future of serverless and we could use your help! If you are passionate about building developer tools and love helping other developers, we'd like to meet you.
-We've also written in detail about how we work.
-We are looking for software engineers to help build out our open source framework, SST. SST is primarily written in TypeScript and Node.js. Knowledge of other languages is a bonus. It'll also be helpful if you have a general understanding of some AWS services. Please share some of your open source contributions with us and links to projects that you've worked on. If you care about building better developer tools, we'd love to meet you.
-We need technical writers to help grow our guide. If you like taking complicated concepts and finding ways to convey them in as simple of a way as as possible, we'd love to talk to you. It's a big bonus if you like teaching or have created educational content in the past. Please share articles, guides, tutorials, or docs that you've written.
-We could use some visual design help to create the graphical elements that we use across our entire portfolio. This includes things like icons, logos, posters, inforgraphics, UI design elements, and much more. If you like using design to make the complex more accessible, please send us your portfolio. We'd love to get in touch!
-Join readers from the biggest companies in the world
-Older sections of the guide available for reference.
-
- 
- Use our open source framework to deploy your Next.js, Svelte, Remix, Astro, or Solid site.
-
- - Extend your app with our preconfigured backend components. Even use any AWS service. -
-
- Add a serverless SQL or NoSQL database to power your app.
-Add a dedicated serverless GraphQL or REST API to your app.
-Authenticate your users through any auth provider.
-Run cron jobs powered by serverless functions.
-Go beyond our components and integrate with any AWS service!
-Create preview or feature environments. Or one for everyone on your team.
-
- Use the CLI to create and deploy to new environments.
-
- Lead Engineer,
- -
- Read Case Study
- 
- Engineering Manager,
- -
- Read Case Study
- 
- CTO,
- -
- Read Case Study
- 
- Founder,
- -
- Read Case Study
- GitHub stars
-Discord members
-Subscribers
-Join readers from the biggest companies in the world
Download the FREE 300 page ebook
-Join {{ site.stats.newsletter }} readers from the biggest companies in the world. We'll also send you updates when new versions are published.
-
- 
+ Older sections of the guide available for reference.
+
+ 
-
- 
- 
- 
- 
- 
- 
-