nerdgeschoss Guide to the Galaxy

Hello and welcome to nerdgeschoss GmbH. This document is here to help you find your way around the company, gives you all needed contact data and a general overview on how we work.

The Why

Company Values

How do we make decisions? What are our strategic movements build on? We tried to define six core values that we want to base our decisions on.

🔝 Always Raise the Bar.

We strive to create awesome work that we can be proud of and others look up to. We never stop improving ourselves.

🧙‍♂️ Be Gandalf!

All heroes need guides. Help others achieve their goals. Empathise, care and challenge.

🎟 Solve Problems, not Tickets.

Don’t create solutions for problems that do not exist. Ask better questions, listen and repeat.

🚪 Be open, be Honest.

Honesty is the foundation of good communication. Show trust and respect for each other by always choosing transparency over secrecy.

🧟‍♀️ Bring Your Whole Self to Work.

What makes you weird and special makes you memorable. And not only that, it makes you authentic and original. This is your superpower.

A Short and Incomplete History of nerdgeschoss

nerdgeschoss GmbH was founded in 2013 as a legal entity as a project of Christian and Jens. Before they worked as colleagues in a design agency called nulleins. From the beginning we had a focus on apps, mobile and ux while the term responsive design wasn’t even a buzzword yet. During the first years we focused on native and hybrid apps (iOS, Mac, Android) while spending the majority of time wrestling with Wordpress. In 2014 we joined a Startup called MyLane, trying to disrupt the point of sale of german local retail with iOS based point of sale systems. As it turned out this was quite a nice idea (as Square proved a bit later), but failed quite badly for us.

Recovering from this fail nerdgeschoss pivoted back to the initial idea: Doing serious applications instead of Wordpress pages and startups. We started taking Ruby on Rails as our main stack and extended it in 2017 to use React on the frontend, targeting companies from startups to bigger corporates. This is where our technical mission statement came from: Build solid and maintainable software that is focused on helping and delighting the end user.

The How

Your First Day at nerdgeschoss

You arrived at the office, signed your contract and probably already had your first coffee. Now the fun can start! After receiving your new MacBook and other hardware, you will get access to a lot of web based tools we use for collaboration.

Gmail / Google Calendar

The first thing that will happen. You get a Gmail invite for your personal [email protected] address. From now on please use this email account for all business related signups and conversations. This is an email account to document your work, so we reserve the right to have a look into it if we urgently need any info from it (just store your vacation bookings and loveletters in a private account, please 💁‍♀️).

This invite also includes a Google Calendar. All calendars in the company are connected and public to each other. If you’re interested, you can add others from the web interface to your view (this also applies to Calendar on Mac/iOS).


n.U.T.S. stands for nerdgeschoss Unified Tech Stack, our common architecture for Rails applications. It’s so amazing, it even has it’s own handbook page.


All collaboration happens in GitHub. We have a company account for both private repos for our customers and public open source repositories. You will be added to the developer team and therefore will have admin access to all repositories (this is intentional – waiting for an admin should never be a thing). More on how we use Git later.


This is where internal communication happens. Every project has its own channel. Also make sure to subscribe to #office to communicate with everyone in the office. More on the slack workflow later.


Our time tracker. Most of our projects are billed by time and material to our customers, therefore it’s important to track your time every day. We do not use the time tracker to check how many hours you spend in the office, but just to bill our clients (so please don’t make up numbers here to look like you’re working more – we won’t see it anyway). You might want to install Harvest for Mac which allows you to start time tracking via hotkeys.

For entries, please make sure to use the format #123 - Title of Issue whenever possible so we can automatically generate invoices from them. This also helps in finding entries that accidentally get made for wrong projects.


If you survived the job application process you probably already touched Heroku. In our experience it is the easiest and most stable hosting solution we tried so far. We use it for everything from simple Wordpress to microservice-backend-apps. Have a look at Heroku Review Apps if you need more arguments for it. We use Heroku Flow as a development style. The rule is simple: Whenever you don’t have an explicit reason not to go for Heroku, always go for Heroku and don’t host it yourself.

nerdgeschoss App

The nerdgeschoss app contains everything company-related you might need at Here you can check on your paychecks, remaining holidays or sprint performances. This app is open source and available in our GitHub account. Feel free to do pull requests to improve it.

Github Issues

This is where project management happens. There is a Sprint Board that contains everything that is currently being worked on with filters for each project. More about columns below.

Other Software we are Using


Website · iOS App · Contains all passwords and software licences you might need. Ask Christian or Jens for access.


Website · To interact directly with the database, we use TablePlus.


Website · This is our preferred choice for development as it has the best developer tools.


Website · Miro is our tool of choice for visual brainstorming and idea mapping. Whether we're sketching out database diagrams, crafting flow charts, ideating on virtual boards, designing wireframes, or plotting roadmaps.


Website · We use Tower for all of our git operations from cloning repos to generating pull-requests. Unless you are a git master, we recommend that you use this too!


Website · It's a design software!

Visual Studio Code

Website · It's a good, extensible code editor. And it's free! You could do worse than using this.

You got everything set up correctly? Time to get some work done!

Your Time in the Office

We’re here to help you grow and get the best work possible done. If we can support you in any way with that just let us know. This includes everything from drinks to software licences you might want to use or additional hardware.

Dumpling Dienstag 🥟

At nerdgeschoss, fostering community is as important as our technical pursuits. As a remote-first team, we understand the value of face-to-face gatherings, and hence we've introduced our cherished tradition – Dumpling Dienstag 🥟.

Each Tuesday, our team gathers at a pre-specified location, often our office, for a lunch filled with delicous dumplings. It's a casual event that offers a breather from work, encouraging rich conversations and shared experiences.

This tradition isn't exclusive to our team. We believe in openness and welcome clients, friends, and family to join in the feast, enhancing the diversity of our interactions.

Invitations to Dumpling Dienstag 🥟 are sent out weekly, ensuring everyone is free to join or skip based on their convenience. Even if you're remote, you're always welcome to join when in the area.

Please note, participation is entirely voluntary. Respecting personal choices and work-life balance, we aim to create a relaxed and social atmosphere. We hope to see you there, relishing the culinary delight that is Dumpling Dienstag 🥟!

Drinks and the Snackbar

For all employees the snack bar and drinks are free.


For credentials to our Wifi, check 1Password.

Using the Meeting Room

There is no calendar for the meeting room as of now, so it’s used on a first-come-first-serve basis. If you need to reserve the room for specific meetings, just let the others know via slack.

The meeting room has a 55inch 4k TV with an attached Chromecast or Apple TV, so you can mirror your screen or individual windows and tabs without installing additional software (although you need Chrome for the Chromecast).

On the other side of the room you will find a magnetic whiteboard and markers. If you use the board, please clean it after the meeting. Those markers have the nasty habit of becoming quite permanent over night and are super hard to remove the next day.

Where to Work

We pride ourselves on not only being remote-friendly, but remote-first. All processes are designed to support an asynchronous workflow across timezones that should help you to adapt work to your life – and not the other way around. There are no minimum office days, you can individually decide where to work.


Feel free to work remotely as much as you want; there is no minimum of days in the office. We have some recommendations for you though:

  • Make sure you have a productive environment. That includes a decent office chair and desk – your body will thank you for it.
  • When you are in calls, you need an environment where others can actually understand you. A busy cafe might not be the best place for this.
In the Office

Feel free to switch between tables whenever you want. We try to keep all tables equipped with the same hardware so it’s easy to switch. If you feel like it, you can also work in the kitchen, on the couch or on the balcony. If you have long phone calls, it might be a good idea to switch to the meeting room or the phone booth to not disturb the others too much.

When to Work

Work at nerdgeschoss happens asynchronously, there are no fixed working times. We believe that work should adapt to your life and not the other way around.

Nevertheless we have some rules to make working (especially across timezones) easier:

  • during the sprint you should reach an average of 7.5 hours per workday, which accumulates to a normal 37.5 hour work week. If you want to split this across 6 or 7 days instead of 5, this is also ok; we're interested in outcome, not in you having busy-work.
  • We encourage you to reach 6 billable hours per workday. This leaves 1.5 hours of sprint meetings and working on non-profit projects or personal development.

Core Meeting Times

To simplify the planning of required team meetings, there is a Core Meeting Time from 9:30 to 12:00 (Berlin time). Do not schedule any other appointments and make sure that you are available during this time. This also includes any private meetings or doctor appointments (these can usually be scheduled to a later hour or if it's really urgent you of course can take a day of sick leave). This way we can schedule company wide meetings without having to schedule with each person individually.

At the End of the Day…

You’ve done your best for today and it’s time to head back home and enjoy some time away from the keyboard. Before you leave please check some things:

  • Write a short paragraph about what you’ve done today and plans for tomorrow into The Daily Nerd channel in slack. There’s also an automatic reminder pinging you at 5pm to not forget about this (this basically replaces daily stand ups).
  • Check your time tracking and add missing entries. If you forgot to track your time, we can’t charge the customer! Make sure your entries follow the conventions.
  • Clean up your workplace. Put bottles back into the trays, trash into the bins and used dishes into the dish washer. Your place should be ready to be used by another person.
  • If you’re the last one in the office
    • check if all windows are closed
    • double check that the doors to the balconies are closed
    • turn off the light (there’s a huge button next to the door that turns off all lights)
    • lock the door after you leave via the app

After you left, don’t bother with work. Your free time is yours, so you don’t have to answer slack messages or emails (if we manically call you 15 times and leave hundreds of slack messages pinging you, it might be worth checking in with us though 🙄).

Overtime is neither expected nor seen as a good thing. Focus on the time during work, work efficiently during the day and use your free time to restore your energy. And if you still stay in the office we might kick you out at some time 🚪.

Your Week Comes to an End

Every second Friday during Review we recap what we achieved during the sprint together. We discuss impediments and their solutions and how to continue during the next sprint. This is also the moment to showcase your work, present libraries and helpers you’ve written during the week and give each other feedback.

Vacation and Time Out Of Office

Vacations and sick days are managed via the nerdgeschoss app.

Calling in Sick or for Personal Reasons

As we’re all not machines, unforeseen things can happen. First things first: If you’re sick, stay home and take care of yourself. No one will be happy if you get worse by forcing yourself to the office – or worse: make your coworkers sick, too. So stay in bed and take care of your health.

Nevertheless there are some legal/organisational parts to this, too: If you are sick, tell us before the core office hours. If you’re sick for more than one day, we need a notice about this from your doctor from the second day.

Visiting doctors or related services during work times depends on the severity of your condition: You have a fever and can’t breathe? Probably you shouldn’t be in the office in the first place. You’re going to your quarterly health checkup or yearly dentist appointment? Do this outside of work hours. We offer quite flexible core working hours, so it should be possible to shift your appointment accordingly. Keep in mind that time at the doctor is not working time (unless they write you a sick note, in that case it’s part of the sick time).

Working on Tasks

The following are guidelines to help you coordinate your work with your team. They are just general ideas and can always be adapted to specific project needs.

Planning the Work

Any ideas and customer requests go first to the Shaping status and stay there until all external factors are determined and all open questions are resolved. This usually involves talking to the customer, creating mockups or doing user research, figuring out API documentation or deciding on props for a component. You have any ideas what you would like to change about a project? Throw it into the "Shaping" status.

Shaping a Story

Before any work on a sprint starts, it is time to shape all stories. To have a story shaped, make sure the following things are documented within the issue by posting a comment:

  • How is the interaction flow? Which mutations/queries/controller actions are done in which order? Make sure to name the mutations/controller actions already.
  • If the story involves creating a GraphQL API, document the types and mutations involved. This should be done via the GraphQL schema language.
  • If there are database changes, document the new fields. This includes name, type, indices and nullability.
  • You're planning to create a graph of multiple objects (e.g. a database schema, multiple services or models calling each other etc)? Document them as a diagram with mermaidjs.
  • If there are any external APIs involved, document the endpoints you're planning to call as cURL commands. These commands have to be working at this point!
  • You found any loopholes in the acceptance criteria? Missing Screens? This is the time to make sure all the input is there for development.

Shaping a story usually involves multiple people, e.g. a backend developer and a frontend developer working together, maybe even involving a designer to discuss behaviour of certain elements and components.

Once all of this is documented, review it together with another developer either in person, call or chat. Adapt the shaping comment until both of you are confident in the implementation. Then the reviewer should move the story to the Todo column.

What to Work on

All tasks in the task board in the “Todo” column that are not assigned to a specific person can be worked on. If there is a task marked as “important”, you should consider taking this one first. Also make sure to check if you can help your peers in a peer review before starting new work.

If you find something you want or need to work on that is not on the task board, create a task in the backlog and advocate to get it into the next sprint.


If inspiration strikes and you envision a potential enhancement to our projects, we welcome your input in our dedicated Ideas segment. Here, your innovative proposals can be articulated, discussed, and refined within our team. Following the consolidation of an idea, we will incorporate it into an upcoming sprint for further development. If your task list ever runs dry, feel free to delve into this section – your insights could help shape these ideas or facilitate their inclusion in the current sprint. We also encourage team members to bring forth these topics for discussion in our bi-weekly team meetings.

Starting a new Task

Pick the card and move it to the In Progress column and assign yourself. Next up, create an empty pull request (in status draft if possible) in the project. Your branch should be named feature/123_task_i_am_working_on - make sure to include the issue number. Give that pull request a descriptive name (“Bug Fix” is not descriptive!) and add either the ticket number or a proper description to this pull request (again, “fixing a bug in cards” is not descriptive!). The early pull request is there for your team to see what you’re working on and prevent duplicate work. To simplify the process, you can also use the pull-request gem which installs a pr command.

Finishing a Task

Your work is done, now it’s time to integrate it into the project. Have a look at your pull request in GitHub and check the following:

  • are all tests passing on the CI server?
  • (if existing) open the deployed review app and check if your feature is working as intended
  • is your branch up to date?
  • have a look at the committed files. Did you check in anything that shouldn’t be there? This is also a good opportunity to review your own work and check if this is actually the best solution to this problem.
  • check the acceptanc criteria again – make sure you didn't miss something.

Before marking your task as ready for review, you should take some additional steps to ensure your feature is easily testable. Configure the review app as necessary and provide reviewer notes in the Issue. These notes should contain information that will assist in the review process, such as login credentials and specific instructions on what and how to test your feature.

When you're confident in the quality of your work, move the corresponding task to Review and mark your pull request as ready for review. If there's a specific coworker whose input you believe would be valuable, feel free to request a review directly from them using GitHub's review request feature. However, avoid making such requests for every PR as you don't want to overwhelm your colleagues' inboxes.

With your task now in the Review stage, the peer review process can begin in earnest.

Peer Review

Peer Review and QA happen in parallel.

This state is designed to have your code reviewed on a technical level. We use GitHub’s review feature to leave comments directly in the changed code. If you request a change, move the issue back into the Todo column.

Things to look out for as a reviewer:

  • Reviewing code has precedence over coding new features. Always first check for open peer reviews before starting something new.
  • Does the code match our coding guidelines?
  • Did you try out the feature as a whole? This means running it from a review app or running it locally. A grean CI status does not mean that the feature actually works – so try it manually.
  • Try to break it. Put strings into number fields and numbers into string fields. Click things that are not supposed to be clicked. Check options that don't work together and see what happens.

Once you're done and everything is fine, approve the PR in GitHub.

Quality Assurance

QA means testing the feature once more before the end users see it. This happens in parallel with code review to not block each other.

  • does the implementation feel right? This is mostly about user experience and behaviour in real world scenarios like performance, usability, accessibility, …
  • does the implementation look right? This checks if the feature looks like the design that was offered upfront.
  • does it fit the product vision? Did it use any technical assumptions that we cannot keep up at a later stage?

Once you're done and everything is fine, approve the PR in GitHub.


When the pull request reaches the Peer and QA approvals, it is time to merge. The last person to approve a PR is responsible for merging into the main branch (usually with a squash commit) where it’s directly picked up by deployment scripts and deployed to staging/production servers. This also means nothing should be merged before it is finished, including translations, icons or other assets. Once the feature is released, move the issue to Done.

Salary and Compensation

To create an inclusive work environment and reduce bias in salaries, we use the nerdgeschoss Human Growth Framework to determine salaries.