Skip to content
Go back

Debugging Berlin’s Housing Market

Published:  at  03:32 PM

Berlin’s housing market feels like a production system that’s permanently degraded.

Everyone knows it’s broken. Everyone has a theory about why. Everyone has a horror story. And yet, no single person “owns” the system end-to-end—so it keeps running in this strange state where demand is spiky, resources are scarce, behavior is unpredictable, and success feels non-deterministic.

If you’ve tried finding a long-term apartment in Berlin, you already know what I mean. If you haven’t, imagine being dropped into a legacy codebase with no documentation, partial observability, inconsistent requirements, and a flaky test suite—but your family’s stability depends on shipping a fix under time pressure.

This post isn’t a rant. And it’s not a definitive guide.

It’s a personal story about how my family moved from South Africa to Berlin, how we navigated temporary housing for more than a year, and how applying an engineering mindset—measurement, iteration, reducing ambiguity, increasing signal—helped us land a long-term place with minimal disruption.


Understand the System Before You Try to Optimize It

When we moved from South Africa to Berlin a little over a year ago, the first question wasn’t “Where will we live forever?” It was “How do we land safely?”

Relocating countries with a family is a set of interdependent variables that don’t resolve in a neat order. Immigration and administrative timelines collide with work routines, commutes, and the realities of day-to-day life. Add a child into the mix and one decision—like KITA—can change the map of what “good location” even means. Budgets also need time to calibrate; what looks affordable on paper feels different once you’ve lived with Berlin’s cost structure for a few months.

So instead of optimizing immediately for a forever home, we optimized for stability and learning. We started with three months in temporary accommodation via Wunderflats, then extended into a one-year rental. That wasn’t indecision—it was intentional. We were buying time to understand the system we were operating in.

In engineering terms, we were prioritizing observability before optimization. We needed real signals—how neighborhoods felt, how commuting worked, where our routines would form—before we could confidently lock in long-term constraints.


Treat the Apartment Search Like a Distributed System Under Load

Berlin housing does not behave like a fair queue. You can submit a perfect application and hear nothing. You can do everything “right” and still get timed out.

The best mental model I found was a distributed system under heavy load: high contention for limited resources, inconsistent requirements across agents and landlords, and failure modes that don’t necessarily correlate with your effort. Some rejections are explicit. Many are silent. And a portion of outcomes will always feel random, because the system is saturated.

The critical mindset shift for us was this:

Rejection is expected behavior of the system—not a personal failure.

That one idea made the process survivable. It helped us stay methodical instead of emotionally spiraling. When you stop interpreting every “no” (or silence) as a verdict on your worth, you can focus on what you can actually control: improving your inputs, widening your search space, and iterating.


Optimize the Input: Build a High-Signal ImmoScout Profile

Your ImmoScout profile is essentially an API contract. It’s the interface through which a landlord or agent decides whether you’re worth spending additional cycles on. And because they’re scanning fast—often through dozens or hundreds of applicants—your goal is not to impress. Your goal is to reduce friction.

We treated our profile like something we were shipping to production: complete, predictable, and easy to evaluate.

We made our situation explicit: we’re a family with a child, and we’re looking for a long-term home. We kept it personal without turning it into a life story—human, grounded, and respectful. And we clearly stated our net salary. It felt blunt, but the market is blunt. That single detail reduced ambiguity immediately and helped position us within affordability constraints without back-and-forth.

Completeness mattered more than cleverness. A profile that answers the obvious questions up front is easier to trust than one that looks half-finished—even if the person behind the half-finished one is great. In a high-load system, the clean requests get processed first.

In short: we optimized for easy evaluation, not uniqueness.


Start Early as a Data Collection Phase (Not a Commitment Phase)

We started searching in June for a December / January move. Not because we expected to sign something in June, but because we wanted time to learn what the market actually looked like and how it behaved.

Early on, the biggest value wasn’t landing a contract—it was collecting data. Each application and each response (or lack thereof) helped calibrate our expectations: pricing, demand patterns, neighborhood trade-offs, and what “good” really meant for our family.

At this stage, we focused on feasible rather than perfect. We applied broadly to apartments we could realistically live in, even if they weren’t dream options. That broadened our learning surface area and prevented the common trap of over-optimizing for a set of requirements that only exist in your head.

Exposure changes your requirements. The more you see, the more precisely you can define what you actually need.


Viewings Are Interviews (and You’re Always Being Evaluated)

Once viewings started, we treated them as two things happening simultaneously: an inspection of the apartment, and an evaluation of us.

Practicalities matter—light, layout, noise, the building, the street. But in Berlin, viewings are also a social environment where behavior becomes signal. Landlords and agents aren’t just assessing whether you can pay; they’re assessing whether you’ll be easy to work with and low risk over time.

So we kept the basics rock-solid. We were on time. When possible, we arrived early—not to “game” anything, but because being early sometimes creates a natural moment to briefly introduce yourself before the crowd. Inside the apartment, we were polite and respectful to everyone present, not only the landlord or agent. That’s not a tactic; it’s just good behavior. But in a high-stress, high-competition system, those small signals compound.

We also stayed prepared without projecting desperation. Documents ready, questions ready, but emotionally steady. Calm reads as stability.


Redefine “Central”: Why We Looked Outside the Ring

One of the most meaningful decisions we made was to search outside the Ring while staying in premium, well-connected areas.

This is where the engineering mindset helped again: we changed the metric.

Instead of optimizing for geographic centrality, we optimized for latency to what we actually cared about—S-Bahn access, daily livability, and time-to-the-places we realistically spend our lives in. When you treat “central” as a function of travel time and routine rather than a boundary on a map, your solution space opens up.

And in Berlin, opening the solution space often means reducing competition without compromising quality of life. That shift alone changed the experience of the search.

Centrality is about latency, not geography.


Optionality Is the Real Advantage

This part matters, and I want to be honest about it: one of the biggest advantages we had was flexibility.

We were fortunate enough to be able to pay double rent for a short period if needed. That gave us optionality on timing—something that many people don’t have, and something that can dramatically alter outcomes in Berlin.

Landlords often want someone who can move in immediately or on a very specific date. If your timeline is rigid, you’re constrained to a narrow window. If you can overlap, you can choose the best option rather than the one that happens to align perfectly with your end date.

This is also where the uncomfortable truth shows up clearly: Berlin’s housing market is not meritocratic. Effort helps, preparation helps—but so do timing, buffers, luck, and the particular preferences of whoever is selecting tenants that week. The goal isn’t to assume fairness. It’s to increase probability while staying sane.


The Outcome: Four Viewings, Two Contracts, One Decision

Our process didn’t involve dozens of viewings. In total, we went to four.

Two we eliminated early, based on fit. Two progressed to contract stage. We were offered both contracts. We declined one, even though we could have signed, because it didn’t win on the things that mattered most for our family.

We signed the other because it minimized disruption. It was close to our current temporary apartment, which meant our son could stay in the same KITA, our commute didn’t need reinvention, and the move became a logistics problem rather than a life reset.

In engineering terms, it wasn’t just a working solution—it was a solution with minimal blast radius.


What This Taught Me (as an Engineer and an Immigrant)

This entire experience reinforced how well engineering principles transfer to real life—especially when the system is messy.

Observability matters. If you can’t see the system, you can’t make good decisions inside it. Reducing ambiguity helps, because humans under load will choose the easiest-to-evaluate option. Success is probabilistic, so you need iteration without emotional collapse. Constraints define outcomes, and sometimes the best move is changing your constraints rather than pushing harder inside them. Optionality is leverage. And small signals—how you show up, how you behave—compound when competition is high.

Most of all: stability is a platform. Without it, everything else runs slower.


Conclusion: You Can’t Fix the System—But You Can Debug Your Approach

Berlin’s housing market remains broken. That didn’t change because we signed a contract.

But you can still operate intelligently within a broken system.

You can start early—not to commit, but to learn. You can increase signal and reduce friction in how you present yourself. You can widen your search space strategically. And if you have the ability to build any optionality into timing, you can reduce pressure and increase your choices.

Sometimes engineering isn’t about fixing the bug.

Sometimes it’s about learning how to operate safely—and calmly—inside a system that stays imperfect.

If you’re in the middle of this process right now: it’s exhausting. It’s frustrating. It can feel personal.

It isn’t.

Keep iterating.



Next Post
A Practical Guide to Writing Better AI Prompts as a Software Engineer