---
title: "A year at 37signals"
url: https://stanko.io/a-year-at-37signals-8s17uw9GPHgD
author: Stanko Krtalic Rusendic
published: 2026-08-05
updated: 2026-08-05
tags: [work]
---

# A year at 37signals

A year ago I had my first day at 37signals (the people behind Basecamp, HEY and
Fizzy).

This was a dream come true for me.

I wanted to work there ever since I read Rework over a decade ago. The books,
podcasts and talks that followed showed me that we also share a similar
philosophy towards work and the craft of coding. That just cemented my resolve.

Not to mention that it's the birthplace of Rails! The single piece of software
that made me decide to turn my programming hobby into my career.

I had an incredible year, so I want to share how I got here and what I learned
that might not be obvious when looking from the outside-in.

### Getting the job

I'm not sure how many times I applied for a job here over the years. It must be
at least six, maybe more.

Out of those I passed to the final round twice.

The first round is notoriously difficult, which is quite funny because it's just
a simple cover letter.

We write a lot internally. Nearly all communication is written and most of it is
long-form comments and notes. Being able to write is essential.

I wasn't a good writer. It took me a few attempts to realize that. But I was
determined to get better at it, so I worked on it.

The first step to writing better is to read more. Not just technical books,
self-help and similar, but stories, essays, opinion pieces. Learn what's out
there and expand your vocabulary and literary horizon, then forge your own style
from the things you like.

A funny side-effect of reading more is that I started to hate [corporate
newspeak](https://stanko.io/corporate-newspeak-v2E1RTcmIUfi) - it's so bland and
dull that I immediately tune out as soon as I start to read or listen to it now.
To me it's like communicating in memes.

The second step is to write more. I started writing more often on this blog,
which helped with long-form technical writing. But later on I started keeping a
diary. Nothing fancy, I'd just jot down what happened every day and some
thoughts bouncing around in my head - this helped me in general, not just with
writing.

The third step is to learn how to write a cover letter. This took several
attempts and it boils down to: be yourself.

I always felt a pressure to make the cover letter sound professional. You know,
the things they tell you in school: serious tone, respect, warm but also not too
personal.

That's terrible advice. And I realized that only after I started hating
corporate newspeak. It makes you sound the same as everyone else, and dull on
top of that.

A cover letter should explain why you want to work there. It's your chance to
tell your story. It's supposed to be personal, fun and interesting.

The second round is a take-home exercise.

I was never worried about this. For me Rails and the OSS that 37signals puts out
has always been [a treasure trove to explore and learn
from](https://stanko.io/building-twice-a-clone-of-once-gJKxLYCe26Ak) so I was
familiar with their style, and I already spent a lot of time internalizing why
they structure code like they do.

I could write a whole essay about this, but to keep it short: ergonomics and
domain design are important; the code should read like prose.

Lastly there is the interview.

I fumbled the first one. I was unbelievably anxious and over-thought and
over-explained every question; the conversation didn't flow. But I got good
feedback from it and spent a lot of time improving on it. The second time around
I was relaxed and we had a fun chat.

Then, one evening I got an email ominously titled "Some news" telling me that
they'd like me to join the company! I was over the moon!

### Working here

I have a hazy memory of the first few weeks - they felt like a dream. What I
remember the most is reading, and reading a lot.

As soon as I started working on actual tasks a new feeling hit me: doubt. I
started to second-guess my own work and this thought formed in my mind that I
just lucked out with the hiring process and that someone would soon notice that
my work wasn't any good.

This feeling lingered on for months and passed only when I started getting fewer
comments on my PRs.

It sounds like a curse, and it felt like it, but now I see that it was also a
boon. It motivated me to get better and to learn. I figured that's the only
thing that would cure that feeling, and it did.

Then came [Fizzy](https://www.fizzy.do/)'s launch.

I got to work on Fizzy as soon as I joined. My first task was to [add
FizzyAsk](https://github.com/basecamp/fizzy/pull/857) - an LLM-powered chat
where you could tell Fizzy what to do or ask it questions about your data.

After adding it I barely ever used it. And to my surprise [it was completely
scrapped](https://github.com/basecamp/fizzy/pull/1389) alongside all AI features
after a month.

This was the first time I ever saw features get cut - not pivoted, not moved,
not put on hold - after they were built and before they were even released.

The reason behind the cut was eye-opening: [delightful or
nothing](https://world.hey.com/jorge/delightful-or-nothing-56d86b31).

Imagine an overgrown garden with hundreds of different plants in it - that's
what the products of most companies look like to me: an eclectic collection of
ever-growing features. The garden is "designed" by adding whatever plants the
neighbours added to their gardens this week. Everything is overgrown because
nobody has the time to care for so many plants, and even if they do they don't
know how. The plants that are cared for are overshadowed by the overgrowth.

By comparison, what I saw with Fizzy was gardening. There was a vision. The
garden had just a few flowers, but all of them were curated to work together and
arranged to be delightful. If something new didn't work with what was already
there it wouldn't make the cut, or we'd remove some of the old flowers to make
room for the new ones.

I talked to a few friends about this and some of them had an interesting
comment: "Isn't that soul-crushing? You spend so much time building something
just to see it go down the drain."

No, it isn't. In fact, it's liberating. Not all ideas are good, but you can't
know that ahead of time. Sometimes you have to try them to understand why they
don't work. It would be far more soul-draining to have to support an experiment
for years than to admit that it wasn't very good and bury it right away.

Whenever I talk about this I think of Buddhist mandalas. These are intricate
artworks made of colored sand that can take weeks to complete. Once they are
done they are admired for a while and then swept up and thrown into a river.
Nothing is permanent.

Later on I was tasked with building a new magic-link-based auth system. Sounds
easy, right? It wasn't.

Fizzy was built on two new in-house gems:
[activerecord-tenanted](https://github.com/basecamp/activerecord-tenanted) and
[beamer](https://www.youtube.com/watch?v=lcved9uEV5U). AR-tenanted separated
each tenant into their own database, and Beamer replicated those SQLite
databases to the whole fleet of servers. The catch was that there had to be a
central identity database for sign-in, but each server was the writer for a few
tenant databases, so you could never write to that database and then the
tenanted database in the same request because the two databases would be on
different servers most of the time.

As I was untangling that I realized that I was used to working with the latest
release of Ruby and Rails, even with Rails edge. But this was different. We were
ahead of Rails edge. We were building what might become Rails edge at some point
and dogfooding it ourselves to work out the kinks!

This can sometimes become a challenge. The magic links took two weeks to
implement and I spent a good part of those two weeks wondering if it could even
be done.

Some of my work on Fizzy did make it into Rails. I added Crockford's Base32 to
Fizzy for magic link codes and that became
[`SecureRandom.base32`](https://github.com/rails/rails/pull/56288). Later on I
added passkeys to Fizzy, and [that might also land in
Rails](https://github.com/rails/rails/pull/57100) as `has_passkeys` in Active
Record.

After the launch we shifted into cycle work. This was the first time I
experienced Shape Up.

Shape Up has two modes: cycle work and [new-product
mode](https://world.hey.com/bb/new-product-mode-48a43806). Cycle work is the
thing most people associate with Shape Up - six week cycles with cooldown
periods in between. In new product mode there's no fixed cycle, no appetite, no
kick-off, no pitch. It's like jazz, things are made up as we go.

After working in both modes I realized that what I thought of as "agile
development" was just waterfall with extra steps.

Take scrum as an example: two week sprints, task pointing, standups. It sounds
quite similar to Shape Up: six week cycles, appetite, check-ins and hill-charts.

The magic is in what happens behind the scenes.

In every company I ever worked at there was something like a "product roadmap" -
a document that laid out each feature that would be added in the fiscal year and
in which order they would be worked on. Then scrum gets slapped on top of that.
So now you are working in cycles, but there is this Gantt chart called the
"roadmap" in the background that suspiciously looks like a waterfall and if
anything slips the cascades become a bit wider. [Scrum isn't there to get things
done, it's there to keep you on
schedule](https://stanko.io/scrum-is-for-time-estimates-not-projects-23ULmuBVSMqo).

In Shape Up the plan is laid out six weeks at a time. It isn't set in stone, it
can shift; projects are dropped, shortened or extended. The important part is
that after the six weeks are over a new plan is laid out that takes into account
not only what was done in the last six weeks but also what happened in the
world.

[Jason Fried had an excellent article about this where he compared it to running
like a squirrel](https://world.hey.com/jason/like-a-squirrel-bd821787). A
squirrel runs a little, then stops, looks around, picks a new direction, and
then runs some more. As it does that it takes its surroundings into account. It
goes in a direction but it regularly re-evaluates. That's agile.

I've seen so many serendipitous situations where one project became the
groundwork for another that was just the right fit at the moment. You can't plan
this, you have to see and feel the previous work to form a vision of what you
could build with it next.

These are just the most eye-opening things I learned.

Last week was a big week for me because the company decided to keep me! After
the first year everyone goes through a review that asks one question: knowing
what the company knows now, would they hire you again? A huge weight has been
lifted off my shoulders even though I knew the review would go well.

I'm grateful I get to work alongside and learn from my amazing colleagues at
37signals.

When I joined I expected a challenge, I wanted to learn and to grow, and that's
exactly what I got. I'm glad I managed to rise to it. This really was a dream
come true.