Modern web development is fantastic. There are so many great tools available!

Modern web development is exhausting. There are so many great tools available!

Each of these sentiments is true. What’s great is that most of the time, it’s hard to make a choice that is wrong. Seriously. The trade-offs of most of the frameworks and tools you could use to build your application fit within the constraints of the vast majority of apps.

Despite this, engineers consistently struggle with **analysis paralysis**. Nobody likes the feeling of having to make a decision they’ll have to live with for the foreseeable future and find out it was the wrong one. Like a hungry person getting hungrier looking over menu that’s too long and full of great options, engineers find themselves guessing and second guessing our technology choices.

On top of that, getting team of engineers running the same direction with the chosen technology can be a big challenge. There are numerous considerations, existing skills, training for new skills, the hiring pool, personal preferences and experience, and more.

Oh, and then once you’ve finally selected a web framework, UI library, testing framework, hosting provider, etc. etc. you have to wire everything together before any meaningful work can get done.

And all of this is just a **big distraction** from what we’re really trying to accomplish here: **ship a quality product**.

## It’s time to just ship

I’ve been developing modern web applications big and small for nearly a decade. In that time, I’ve worked all over the stack. Significant technical decisions I’ve made are still in use at my previous companies (like PayPal). I’ve also made a number of technical decisions that didn’t pan out very well at all and I had to pay the price.

With the help of my team, I’ve shipped web applications to millions of users all over the world as well as smaller internal apps to a handful of stakeholders. I have a solid grip on what it takes to ship excellent user experiences and make choices that keep developer velocity (and morale) high.

That’s why I’ve decided to encode my experience on how to build excellent modern web applications into **an opinionated project starter** that allows teams to ship their ideas to production faster and on a more stable foundation. And it’s called “The Epic Stack”:

![](http://res.cloudinary.com/epic-web/image/upload/v1683707705/epic-stack-logos.svg)

The primary goal of the Epic Stack is to help your team get over analysis paralysis by giving you solid opinions for technologies to use to build your web application. The Epic Stack is really two things:

1. A project starter
2. A reference implementation

For those of you starting a new project, you can use the `create-remix` CLI custom stacks feature to bootstrap your app with `npx create-remix@latest --typescript --install --template epicweb-dev/epic-stack` and you’ll be set.

But most people don't startup their computer every day and start a new project. Most of us work on an existing app. For those folks, the Epic Stack can be a great reference for configuring tools and integrating with solid libraries and services. <a href="https://github.com/epicweb-dev/epic-stack/tree/main/docs/decisions" target="_blank" rel="noopener">The Epic Stack decision documents</a> can also serve as a good place to find good arguments for the decisions and trade-offs made.

## The Epic Stack

There’s far too much for us to talk about in a single blog post, so I’ll encourage you to dive into the <a href="https://github.com/epicweb-dev/epic-stack/tree/main/docs" target="_blank" rel="noopener">docs</a> for more and [star the repo](https://github.com/epicweb-dev/epic-stack), but let’s get a high-level view of what you get when you use or follow The Epic Stack.

We’ll start with <a href="https://github.com/epicweb-dev/epic-stack/blob/main/docs/guiding-principles.md" target="_blank" rel="noopener">the guiding principles of the stack</a>:

* **Limit Third Party Services:** If we can reasonably build, deploy, maintain it ourselves, do it. This saves on cost and reduces complexity.
* **Include Only Most Common Use Cases:** As a project generator, it is expected that some code will necessarily be deleted, but implementing support for every possible type of feature is literally impossible. _The starter app is not docs_, so to demonstrate a feature or give an example, put that in the docs instead of in the starter app.
* **Minimize Setup Friction:** Try to keep the amount of time it takes to get an app to production as small as possible. If a service is necessary, see if we can defer signup for that service until its services are actually required. Additionally, while the target audience for this stack is apps that need scale you have to pay for, we try to fit within the free tier of any services used during the exploration phase.
* **Optimize for Adaptability:** While we feel great about our opinions, ever-changing product requirements sometimes necessitate swapping trade-offs. So while we try to keep things simple, we want to ensure teams using the Epic Stack are able to adapt by switching between third party services to custom-built services and vice-versa.

With that context, here are a few things you get today:

* [Remix](https://remix.run/) is the Web Framework of choice
* [Fly app deployment](https://fly.io/) with [Docker](https://www.docker.com/)
* Multi-region, distributed, production-ready [SQLite Database](https://sqlite.org/) with [LiteFS](https://fly.io/docs/litefs/).
* Healthcheck endpoint for [Fly backups region fallbacks](https://fly.io/docs/reference/configuration/#services-http_checks)
* [Grafana](https://grafana.com/) Dashboards of the running app
* [GitHub Actions](https://github.com/features/actions) with testing and deploy on merge for both production and staging environments
* Email/Password Authentication with [cookie-based sessions](https://remix.run/utils/sessions#md-createcookiesessionstorage)
* Transaction email with [Mailgun](https://www.mailgun.com/) and forgot password/password reset support.
* Progressively Enhanced and fully type safe forms with [Conform](https://conform.guide)
* Database ORM with [Prisma](https://prisma.io/)
* Role-based User Permissions.
* Custom built image hosting
* Caching via [cachified](https://npm.im/cachified): Both in-memory and SQLite-based (with [better-sqlite3](https://github.com/WiseLibs/better-sqlite3))
* Styling with [Tailwind](https://tailwindcss.com/)
* An excellent, customizable component library with [Radix UI](https://www.radix-ui.com/)
* End-to-end testing with [Playwright](https://playwright.dev/)
* Local third party request mocking with [MSW](https://mswjs.io/)
* Unit testing with [Vitest](https://vitest.dev/) and [Testing Library](https://testing-library.com/) with pre-configured Test Database
* Code formatting with [Prettier](https://prettier.io/)
* Linting with [ESLint](https://eslint.org/)
* Static Types with [TypeScript](https://typescriptlang.org/)
* Runtime schema validation with [zod](https://zod.dev/)

And that’s what we have today, here are some things that will likely find their way into the Epic Stack in the future:

* Powerful, yet simple sitemap control
* Error monitoring with [Sentry](https://sentry.io/welcome/)
* Ecommerce support with [Stripe](https://stripe.com/)
* Ethical site analytics with [fathom](https://usefathom.com/)
* Internationalization
* Image optimization route and component
* Feature flags
* Light/Dark/System mode (without a flash of incorrect theme)
* Documentation on production data seeding process

## More than a list of features

A list of features is fine, but really what you’re getting out of this is a break from analysis paralysis. You get to ship faster on top a solid selection of technologies and tools.

Additionally, my goal is to make the Epic Stack second-to-none with regard to learning resources so your entire team can all get up-to-speed on your stack quickly. And having your entire team on the same page with regard to your stack is invaluable.

And that’s what <a href="http://EpicWeb.dev" target="_blank" rel="noopener">EpicWeb.dev</a> will be all about: How your team can take the Epic Stack foundation and build a quality application on top of it.

## Conclusion

After all the time I’ve spent building web applications and learning from engineers with more experience than myself, I feel extremely confident that the Epic Stack will help tons of engineering teams focus on their core offering, move fast, and build excellent user experiences. I hope you give it a shot. Please join the community by participating in <a href="https://github.com/epicweb-dev/epic-stack/discussions" target="_blank" rel="noopener">discussions on GitHub</a> and <a href="https://kcd.im/discord" target="_blank" rel="noopener">the Epic Stack channels Discord</a>.

See you around the web!

Introducing an opinionated project starter that enables web development teams to ship their ideas to production more efficiently.

The Epic Stack

There’s this pattern I’ve been using in my apps that has been really helpful to me and I’d like to share it with you all.

Full Stack Components

The main thing that makes end-to-end type safety difficult is simple: boundaries. The secret to fully typed web apps is typing the boundaries.

Fully Typed Web Apps

Web is made up of technologies that got started over 25 years ago. Now, we are transitioning to a new and improved architecture for building web applications.

Epic Web Dev Articles by Kent C. Dodds

The Epic Stack

Full Stack Components

Fully Typed Web Apps

The Web’s Next Transition