I've been using RoR/Ruby for most of my back-end development over the last 5 or so years and I've decided that it will not be something I reach for going forward.

This is less about RoR itself and more about how I'm working and the DX / productivity gains I'm getting out of the TS/Node ecosystem.

When you are trying to build quickly, context-switching is brutal. Even more so when moving between different languages.

I've found myself inserting semicolons into my Ruby and assuming that the last line of my TS functions will return automatically too often.

Since most of the front-end world is Typescript these days, it just makes too much sense to finally bridge the gap and write TS on the back end too.

This is especially true now that I've gotten further into the Node ecosystem and found things that I've taken granted for in RoR like Prisma (e.g Rails migrations), tRPC (e.g ruby-graphql), and BullMQ (e.g sidekiq).

 Yes, there's more work to get all of this setup as you lose the opinion of a framework like Rails, but, I find the end result much more flexible and fun to work with.

Builds and hot reloads are fast and easy.

The early days of Grunt/Webpack really put me off of the client-side build process and even further when I found myself working on a stack with an Express API + SSR that also used Webpack.

Waiting around for a 10-minute build is no fun, nor had I ever found an E2E hot-reload setup that worked well.

Maybe a year ago I moved all of CRA (using Webpack) front-ends to Vite and it was such a painless and immediately beneficial process.

Build times went down, hot-reload was blazing fast, and the configuration was simple and transparent.

Compiler and runtime errors for types on the front AND back-end is a game changer for full-stack productivity.

It's funny -- I've spent a lot of time in languages that don't really use typing natively (PHP, Ruby, vanilla JS)... 

Since I made the switch to TS, I haven't looked back.

It immediately made my front-end code more readable, predictable, and much less error-prone.

All good things when trying to build quickly and safely.

Most monorepo tooling is written for TS setups.

While polarizing, I've found monorepos to be a huge productivity and DX boon. Sure, there can be pain points with managing dependencies and wiring up your tooling to work well together, but overall, the decision to build my latest tech stack as a monorepo has paid off.

A lot of the ecosystem around the modern monorepo has its roots in JS/TS and, as such, most of the tooling to help you manage your monorepo assumes your packages and apps are all in JS/TS.

While not impossible, it's definitely a lot easier to get Nx or Turborepo to work well with everything being the same language, especially when you are just trying to build and not worry about maintaining the build.

Ruby isn't dead, but, the community is definitely weaker.

This is anecdotal -- it seems that well-maintained gems are hard to come by these days. 

I've had to reach for a few gems that have not had contributions in years and even some of the more popular gems are lacking maintainers.

I definitely don't want to discount the work orgs like Shopify and Stripe have done for the ecosystem and Ruby/RoR is definitely not dead in the water. It is, however, not as popular or robust as the Typescript ecosystem is in its current state.

Yeah, NPM sucks and managing dependency versions can be a nightmare.

But I seem to find a well maintained solution more often than not.

Anyway. Pour one out for my usage of RoR. It served me well.

I've had a lot of fun and success building things on top of Rails but I've decided to no longer reach for it when building new things. Here's why:

I like Rails, but here's why I might not reach for it for a new project

If you’re building a delivery team (Product + Engineering) there are two metrics that you should always be aware of to assess the health of your cycles. These metrics exist outside of your product metrics but gauge how effectively you can ship value to your customers.

: performance KPIs like these should always measure the team, not the individual.

You also don’t need to track these metrics. 

Especially at an early-stage startup. You should be able to know these metrics intuitively.

I define lead time as the time it takes for something to hit our project board and then make it into production. There’s a bit of wiggle room for personal preference, for example, often I’ll consider something complete even if it's hidden behind a feature flag. Others might not consider something complete until a customer can see it.

Either way, you should be aiming to get everything that hits your team to your 

Anything that you think might take longer than that needs to be:

Effective lead time is tightly coupled with our next KPI because if you aren’t deploying a lot, then your work is constantly waiting to be finished.

The important thing about deploy frequency isn’t the actual number you are deploying (a mistake I’ve made in the past…) but 

your ability to deploy as many times as you want

When your deploy pipeline meets these expectations, you don’t have to worry about some of the metrics you might find at larger delivery organizations.

What about the other metrics? (velocity, uptime, defect rate, MTTR, etc)

You might find value in these, but I think anyone who prescribes to these at an early stage is missing the point of being early stage. The goal is to iterate rapidly, find product market fit, and get your business to the next goal.

It doesn’t matter how many tickets you ship, so long as you can ship them quickly.

If you have uptime or defect issues, then you aren’t deploying enough or you haven’t deployed enough to work through these issues.

I’ll have a lot more to talk about in regards to how to optimize these KPI’s in future articles!

If you’re building a delivery team (Product + Engineering) there are two metrics that you should always be aware of to assess the health of your cycles. You also don’t need to track these metrics. Especially at an early-stage startup. You should be able to know these metrics intuitively.


The only 2 KPIs that your delivery team should care about at an early-stage start-up

Starting a new project can be equal parts fun and terrifying. There are so many decisions to be made that will impact how its development is done for years to come and it's impossible to know how that all plays out. This is especially true at an early-stage startup where speed is crucial and your product will evolve exponentially as you look for market fit. Your stack needs to adapt efficiently and not get in the way of rapid iteration cycles while maintaining its structural integrity. 

 and I wanted to talk about some of these key decisions that I've made with our tech stack and how they've played out so far.

Go with a Monorepo (and enforce these 3 important rules)

Drawing on some frustrations at a previous job, I decided to go with a mono repo very early on. This setup empowered me to easily: 

Make changes that impact the entire stack in one pull request.

Quickly add and integrate more apps without much bootstrapping. 

Set up a development environment that can run everything with one command.


While these points are not unique to a mono repo, the barrier of entry to getting this setup was incredibly low. I had the shell of my stack setup in hours and the structure hasn't changed much as we have scaled.

There are a lot of counter-points to a mono repo, particularly at scale (dependency management, coupling, performance, complexity, etc) but I think you can address a lot of those arguments with these enforceable rules:

 -- Each app/service must be independently deployable. yarn deploy web-app , yarn deploy api

 -- Each app/service must use shared libraries via a package manager (npm, gems, etc). yarn add @internal/packageRule 

 -- Each app/service must have the same interface for building, testing, and linting. e.g yarn build , yarn test , yarn lint

The end result is a stack that lets me add apps and packages very quickly, with the ability to make sweeping product changes in a single change request. I also have the comfort in knowing that because of these rules, if the decision is made to split the mono repo up later, it will not be as painful as it could be.

One downside of a mono repo is that you do need to invest more time and energy into scripts and tooling to manage your dev and build pipelines. For example, it took me some time to figure out how I could set up a GitHub action that only ran when changes were detected in a specific sub-folder.

Fortunately, you are able to easily trigger builds when changes are detected in a particular directory:

name: app-1-build
on:
  push:
    branches: [main]
    paths:
      - "app-1/**/*.tsx"
      - "app-1/package.json"
      - "app-1/yarn.lock"
  pull_request:
    branches: [main]
    paths:
      - "app-1/**/*.tsx"
      - "app-1/package.json"
      - "app-1/yarn.lock"


Another issue I ran into (which I plan on talking about a lot more, later) is the developer experience. Initially, you had to cd into each app/service to run commands like yarn test or yarn serve. 

This context swap is minor, but annoying, as you have to do a lot of folder navigation in the terminal.

My current solution is to just add yarn commands at the project root, which do all that for you:

This definitely works, but there's a lot of tooling out there specifically to manage mono repos, a lot of which is documented here:

I never start a new project without immediately setting up a linter and autoformatting. Inconsistent code style or a lack of basic static analysis is a huge source of stupid bugs and developer frustration.

One might argue that the upfront cost of investing in linting is too much when you're trying to rapidly iterate but I completely disagree for these reasons:

CI/CD pipelines are cheap and easy. eg Github actions, CircleCI, etc.

Linters are common, well-supported, and popular in all languages.

Most ship with recommended suggestions that require zero or minimal configuration.


A lot of times you'll see teams neglect this early on, leading to multiple style choices across multiple services. When you jump into an environment like this, you end up losing cycles on just parsing the format vs. the syntax or intent of the code itself. Setting up strict linter rules (and failing builds accordingly) is crucial so that your code style does not drift over time as you add more people to your project.

Some engineers argue that code style limits their productivity or freedom to be creative, but that's a pretty thin argument. Adhering to the needs of a single engineer's personal preference compromises the productivity of everyone else.

On top of that, code style is just one part of linting:

You can run a linter for security or performance checks (such as rubocop-performance for ruby)

You can run a linter for accessibility compliance (eslint-plugin-jsx-a11y)


In my case, I had this running from day 1. A lot of my stack is React, Typescript, and TailwindCSS, all three of which I have a ton of linting being done with eslint. When I switch between my services, the code style can always be expected to be consistent. When I add new developers to the project, they are unable to create style drift by adopting their own standards.

 Here are some rules/plugins that I have found to be super beneficial:

eslint-plugin-simple-import-sort - This ensures that my import statements are always ordered exactly the same at the top of my files. e.g React first, third party next, then my own components after.

eslint-plugin-tailwindcss - This ensures my tailwind classes are always sorted consistently and do not have duplicates or conflicting uses.

eslint-plugin-jsx-a11y - Baseline accessibility compliance for aria tags is pretty nice to have at this stage.

Typically when you're just starting off you'll have a rotating cast of developers coming through your project. In-house, freelancer, in-shore, off-shore, etc. With that sort of cast, it's important that the time it takes for them to get onboarded, set up, and start coding is highly optimized.

This is something I struggled with early on until I took the time to do a few things right.

While often unpopular with developers because of its overhead, I think it's at the point where the performance concerns on Mac/Windows have been mostly invalidated by faster machines and the new virtualization frameworks that have been shipping with Docker desktops.

In my case, I decided to go with a single root-level docker-compose.yml setup that lets me run my entire stack with one command:

version: "3.9"
services:
  # ------------------------------------------
  # web-app (React/Typescript)
  #
  # running on port 3000
  # ------------------------------------------
  web-app:
    depends_on:
      - rails-api
      - strapi-cms
    build:
      context: web-app/
      dockerfile: Dockerfile.dev
    restart: unless-stopped
    command: yarn start
    volumes:
      - ./web-app:/app:cached
      - web_app_node_modules:/app/node_modules:cached
    ports:
      - 3000:3000
  # ------------------------------------------
  # design-system (React/Storybook)
  #
  # running on port 3005
  # ------------------------------------------
  design-system:
    build:
      context: valesco/
      dockerfile: Dockerfile.dev
    restart: unless-stopped
    command: yarn storybook
    volumes:
      - ./valesco:/app:cached
      - valesco_node_modules:/app/node_modules:cached
    ports:
      - 3005:6006
    environment:
      - CHOKIDAR_USEPOLLING=true
  # ------------------------------------------
  # rails-api (Rails)
  #
  # running on port 3008
  # ------------------------------------------
  rails-api:
    depends_on:
      - rails-db
      - rails-redis
      - strapi-cms
    tty: true
    stdin_open: true
    build:
      context: rails-api/
      dockerfile: Dockerfile.dev
    restart: unless-stopped
    command: [ "rails", "server", "-b", "0.0.0.0" ]
    volumes:
      - ./rails-api:/app:cached
      - bundle:/usr/local/bundle:cached
      - cache:/app/tmp/cache:cached
    ports:
      - "3008:3000"
    environment:
      PIDFILE: /tmp/pids/server.pid
    env_file: rails-api/.env
    tmpfs:
      - /tmp/pids/
  # ------------------------------------------
  # rails-db (Postgres)
  #
  # database for rails-api running on port 5432
  # ------------------------------------------
  rails-db:
    image: postgres:14-alpine
    volumes:
      - ./rails-api/bin/pg_hba.conf:/var/lib/pg_hba.conf:cached
      - rails_api_db:/var/lib/postgresql/data:delegated
    environment:
      POSTGRES_PASSWORD: ...
    ports:
      - "5432:5432"
    command: [ "postgres", "-c", "hba_file=/var/lib/pg_hba.conf" ]
    # ------------------------------------------
    # rails-redis (Redis)
    #
    # redis cache for rails-api
    # ------------------------------------------
  rails-redis:
    image: redis:6-alpine
    command: redis-server
    volumes:
      - rails_api_redis:/data:delegated
    ports:
      - "6379:6379"

  # ------------------------------------------
  # rails-sidekiq (Rails/Sidekiq)
  #
  # sidekiq workers for rails-api
  # ------------------------------------------
  rails-sidekiq:
    depends_on:
      - rails-db
      - rails-redis
    build:
      context: rails-api/
      dockerfile: Dockerfile.dev
    restart: unless-stopped
    command: bundle exec sidekiq
    env_file: rails-api/.env
    volumes:
      - ./rails-api:/app:cached
      - bundle:/usr/local/bundle:cached
      - cache:/app/tmp/cache:cached
  # ------------------------------------------
  # strapi-cms (Rails)
  #
  # running on port 3009
  # ------------------------------------------
  strapi-cms:
    build:
      context: strapi-cms/
      dockerfile: Dockerfile.dev
    restart: unless-stopped
    env_file: ./strapi-cms/.env
    command: [ "yarn", "develop" ]
    environment:
      - DATABASE_CLIENT=postgres
      - DATABASE_HOST=...
      - DATABASE_PORT=...
      - DATABASE_NAME=...
      - DATABASE_USERNAME=...
      - DATABASE_PASSWORD=...
    ports:
      - 1337:1337
    volumes:
      - ./strapi-cms/.:/app:cached
      - strapi_cms_node_modules:/app/node_modules:cached
    depends_on:
      - strapi-db
  # ------------------------------------------
  # rails-db (Postgres)
  #
  # database for rails-api running on port 5433
  # ------------------------------------------
  strapi-db:
    image: postgres:14-alpine
    restart: always
    volumes:
      - strapi_cms_db:/var/lib/postgresql/data:delegated
      - ./strapi-cms/bin:/opt/bin:cached
    env_file: ./strapi-cms/.env
    environment:
      POSTGRES_USER: ...
      POSTGRES_PASSWORD: ...
      POSTGRES_DB: ...
    ports:
      - 5433:5432

volumes:
  web_app_node_modules: null
  strapi_cms_node_modules: null
  bundle: null
  cache: null
  rails_api_db: null
  rails_api_redis: null
  strapi_cms_db: null


Write a provisioning script that does everything

This can be difficult when your project pulls in many dependencies but having a single entry point to rebuild the entire stack on a whim empowers you to run it often.

For example, here is my provisioning setup:


// package.json
{
    "provision": "yarn provision:envs && yarn provision:docker && yarn provision:db",
    "provision:envs": "cp api/.env.example api/.env && cp cms/.env.example cms/.env",
    "provision:docker": "docker-compose -p wellen down --volumes && docker-compose -p wellen up --build -d",
    "provision:db": "yarn provision:db:cms && yarn provision:db:api",
    "provision:db:api": "docker-compose -p wellen run api-db sh -c \"/opt/bin/setup-db.sh\"",
    "provision:db:cms": "docker-compose -p wellen run strapi-db sh -c \"/opt/bin/setup-db.sh\""
}


As a new developer, you can run yarn provision which will:

Delete all volumes, start from a clean state.

Rebuild all Docker containers, so dependencies all up to date.


This runs in only a few minutes and results in an easy way to start the entire stack from scratch. Because this is so easy, developers can do it a lot which in turn makes sure that the new developer experience is smooth. With this setup, I rebuild my entire stack weekly which lets me catch potential onboarding issues early and often.

This is a topic I could write about for a long time, so we'll leave it at this for now.

Starting a new project can be equal parts fun and terrifying. Over the last year, I’ve been building Wellen and I wanted to talk about some of these key decisions that I’ve made with our tech stack and how they’ve played out so far.

3 important decisions I made when setting up the tech stack for my startup

 currently working as a member of the founding team at a 

. I’ve always been a bit squirrely about sharing stuff on the internet, but lately, I’ve been in the mood to start writing things down somewhere.

I’ve been a software engineer since 2011, primarily in the D2C start-up space. A lot of my early work was in PHP, but right now I’m a big Typescript and Ruby fan.

Right now I’m doing the whole technical co-founder thing at an early-stage startup which has been a blast. I think a lot of what I’ll write will be around my successes and failures in that particular endeavor.

Why I went with some of the technology choices I made

What choices panned out well, and which ones didn’t

Things I’d do the same or differently the next time

End-to-end type safety with GraphQL + Typescript

Building a component library and implementing a design system

When I’m not working, I like to go outside and enjoy nature. Fishing, camping, kayaking, hiking, walking, looking, breathing…

I also play video games, write music that will never see the light of day, and watch lots of home improvement videos on YouTube.

My name is Nate. I’m an engineer currently working as a member of the founding team at Wellen -- a startup in the health-tech space. I’ve always been a bit squirrely about sharing stuff on the internet, but lately, I’ve been in the mood to start writing things down somewhere.

All posts

I like Rails, but here's why I might not reach for it for a new project

The only 2 KPIs that your delivery team should care about at an early-stage start-up

3 important decisions I made when setting up the tech stack for my startup

Gotta start somewhere… 👋