The name doesn’t make any sense, and the execution of the idea usually is even worse. Often you end up sprinting right into a waterfall.

You shouldn’t be sprinting when trying to deliver something.

Instead, you should be prioritizing things and doing them one at a time.

A sprint is a fixed period of time where a team tries to accomplish a goal and ship some kind of value. Both the goal and value 

 be variable, but in practice tend to be static.

You literally can’t sprint forever. As you move, energy is consumed. There is a finite amount of energy. It takes time to recharge this energy.

Let’s say you are a typical product-delivery team, working on 2-week sprint cycles.

You’ll meet for planning, define the object, maybe do some estimation, and maybe generate some stories/tasks. Then you’ll start the sprint.

You’ll get some work done, maybe chat with design on the UX requirements, maybe plan out some data models, maybe start stubbing out an API endpoint or two…

An assumption you made is not true. Maybe you thought implementing a specific UI requirement would be easy and it turns out not to be. Maybe an API endpoint is taking longer to develop than you anticipated. Maybe a third party is taking a long time to respond to questions about their API documentation.

Now it’s nearing the end of the sprint. You are definitely sprinting, but, you notice that you have a calendar event coming up: “Retrospective”.

And then right after that, “Sprint Planning”.

You are not sprinting. You are running a marathon. Your energy is depleted and you are already jumping into the next run.

Stop sprinting. Limit your in-progress work, stick to an obvious, prioritized list, and build in cooldown periods to recharge the batteries.

Doing sprints in the Agile-prescribed way is not sustainable. It does not unlock the potential of your team.

It’s really hard to keep a lot of things in your head at once. With sprints, you always have an entire iteration’s worth of stuff to think about. You might create a theme or a goal, but in practice, there’s always a lot of stuff that we shove into our sprints.

People on your team should only work on one thing at a time and they should work on it until it’s finished.

Estimate the effort when you start working on it.

You’ve probably heard of Kanban. I’m not going to prescribe it, but I’m going to prescribe a concept crucial to its implementation.

Have one list of work that is always prioritized from top-to-bottom.

To my previous point, energy is finite! You need to take a break. And by a break, I mean, working on things that are not at the top of our priority.

When you finish something, take some time to work on something else.

Depending on your team, this can be an hour, a day, a week, or anywhere in between.

When you finish something, take a break! Tackle a bug, do some professional development, pay down some debt, or work on a side project.

Yep! Stop sprinting. Create a prioritized list. Do one thing at a time.

But what about roadmaps? Stakeholders? Requirements? Discovery???

Maybe you should approach those with this framework in mind. 😆

I don’t like sprints. You shouldn’t be sprinting when trying to deliver something. Instead, you should be prioritizing things and doing them one at a time.


Sprints are stupid. Just use a prioritized list and take breaks

Recently, I’ve decided to go all in on two things, Typescript and GraphQL, after spending most of my coding career building RESTful APIs and avoiding types using languages like Python, Ruby, PHP (before type hints), and plain old Javascript.

TypeError: Cannot read property of undefined

While recently working on a sizable codebase written in plain JS + React, the most common error was our friendly neighborhood 

 . This would almost always surface as a result of a front-end developer trying to navigate a deeply nested object provided by our REST API. The result was a lot of frustrating, unexpected behavior or crashes(we definitely could have done a better job at error handling).

The front-end developers did not have a deep understanding of our APIs data models. This wasn’t their fault — we lacked documentation and our APIs were not designed consistently.

We used a CMS (Contentful) that returned lots of unstructured data whose structure could be changed by external sources (marketing, product, etc).

It was the responsibility of our front-end developers to use safe object access methods and manual type-checking when accessing data from our APIs, which was difficult to enforce as a standard practice.

While you can fix these things with non-technical solutions, they had caused me enough frustration that I wanted to bake a solution into my stack that didn’t require any process or developer responsibilities.

Creating predictability and understandability in my APIs

tldr; Write mutations that do one thing, add descriptions, use introspection as documentation

The first issue, empowering front-end engineers to easily understand our APIs, I’ve decided to fix by using GraphQL. The old programming meme of self-documenting code is sorta true here — GraphQL has a lot of things that make it inherently easy to figure out.

Mutations can be written to do one, obvious, and specific thing

In our REST world, if you wanted to do something like update a subscription interval you would issue a POST:

PUT /api/subscriptions/:id
{ 
   interval: 28, 
   interval_units: 'days'
}

Underneath this request, the API would have to recognize that the interval was changing and then dispatch the proper action to handle an interval change.

You can use the same API to do something like cancel a subscription:

PUT /api/subscriptions/:id
{ 
   state: 'canceled'
}

An argument can be made that, from a front-end developers' POV, this is simple — they only have to remember a single API, and this is valid.

However, in practice, I’ve found that it's difficult to document and educate what each attribute of a RESTful resource can do when you change it. For example, how does a front-end developer know what states there are to change when a certain state change is valid, and what happens after a state change is completed?

You could pop all of this into your API documentation, but I find that to be clunky and difficult to maintain.

Instead, having mutations that do specific things helps bridge the gap with a very clear thing:

mutation ChangeSubscriptionInterval($id: ID!, $days: Integer!, $interval: SubscriptionInterval) {
  changeSubscriptionInterval(id: ID, days: $days, interval: $interval) {
    id
    days
    interval
    updatedAt
  }
}

mutation CancelSubscription($id: ID!) {
  cancelSubscription(id: $id) {
    id
    state
    updatedAt
  }
}

The intent of each operation is clear and someone can understand what the potential side effects are (e.g CancelSubscription will…. cancel a subscription).

The parameters and their types are clearly documented, right in the code. No additional documentation is needed to clarify intent.

Introspection, descriptions, and auto-completion

When you are writing new queries or mutations to integrate into your front-end code, you have the ability to run introspection queries against your GraphQL schema.

If you’re lucky, your back-end engineers can write descriptions for every field returned, giving you additional commentary.

 will run introspections in real-time, providing cool stuff like auto-complete as you write your queries too.

tldr; Generated types from your GraphQL schema == 😍

I think my aha moment came when I discovered graphql-codegen and started using it to generate types for my GraphQL schema. This has led to an insane amount of productivity and stability in my development cycles.

Write the query in a file operations.graphql

End up with auto-generated .ts the file containing my types.

At the end of all of this, I have access to all the types, queries, and mutations in my API:

// operations.graphql
query getSubscriptionById($id: ID!) {
   subscription(id: $id) {
      id
   }   
}

// app.tsx
import { Subscription, useGetSubscriptionById } from 'graphql/api'

const { data: Subscription } = useGetSubscriptionById(id);

subscription.id  // <-- fully typed!

There are a bunch of ways to configure graphql-codegen which their 

Overall, I’m at the point where I vastly prefer this setup, namely because of the reasons above. For my style of development, I feel like it leads to me being able to write code with more confidence resulting in faster and safe cycles.

I’m excited to explore this concept further, especially with stuff like 

Recently, I’ve decided to go all in on two things, Typescript and GraphQL, after spending most of my coding career building RESTful APIs and avoiding types using languages like Python, Ruby, PHP (before type hints), and plain old Javascript. So, why the change?


How I discovered end-to-end type safety with GraphQL + Typescript

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.

Founding engineer, advisor, consultant. Outdoors enthusiast.

Sprints are stupid. Just use a prioritized list and take breaks

How I discovered end-to-end type safety with GraphQL + Typescript

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

Work