How the Ladder Gets Built

The interesting part: whoever built that ladder wasn't a bad developer. In the old world, even the most innocent flow — fetch a user, then their avatar — inevitably ended up looking like this:

func loadProfile(id: String,
                 completion: @escaping (Result<Profile, Error>) -> Void) {
    fetchUser(id) { result in
        switch result {
        case .success(let user):
            fetchAvatar(user.avatarURL) { avatarResult in
                switch avatarResult {
                case .success(let avatar):
                    completion(.success(Profile(user: user, avatar: avatar)))
                case .failure(let error):
                    completion(.failure(error))
                }
            }
        case .failure(let error):
            completion(.failure(error))
        }
    }
}

Twenty lines for two requests. The actual logic is three words — get user, get avatar, combine — yet it's nowhere to be seen. Every layer carries its own error handling, and if you forget to call completion on one branch, the app silently hangs. No compiler will ever tell you.

await: Wait, but Don't Block

The same function with async/await:

func loadProfile(id: String) async throws -> Profile {
    let user = try await fetchUser(id)
    let avatar = try await fetchAvatar(user.avatarURL)
    return Profile(user: user, avatar: avatar)
}

Wherever you see await, the function pauses without blocking the thread; the system runs other work in the meantime. Error handling moved from closures to throws: no more unwrapping Result by hand, no more forgotten completion. If a branch is missing, you find out at compile time, not in production.

Don't Queue Up Independent Work

In the code above the avatar depends on the user, so waiting in order is fair. But awaiting three independent requests one after another is plain waste. async let starts them all at once:

func loadDashboard(for id: String) async throws -> Dashboard {
    async let profile = fetchProfile(id)
    async let feed = fetchFeed(id)
    async let badges = fetchBadges(id)

    return try await Dashboard(profile: profile,
                               feed: feed,
                               badges: badges)
}

Total time is now the slowest request, not the sum of all three. In that inherited project, this one change took the home screen from 1.8 seconds to 700 milliseconds. We wouldn't have believed it without measuring.

Shared State: Enter the Actor

The part of concurrency that actually burns you is data races: two tasks writing to the same dictionary at the same time — sometimes a crash, sometimes silently corrupted data. Swift's answer is the actor: only one task can touch its state at a time, and the compiler guarantees it:

actor ImageCache {
    private var store: [URL: Image] = [:]

    func image(for url: URL) -> Image? {
        store[url]
    }

    func insert(_ image: Image, for url: URL) {
        store[url] = image
    }
}

// Access always goes through await:
let cache = ImageCache()
await cache.insert(avatar, for: url)
let hit = await cache.image(for: url)

We used to build this with locks on a DispatchQueue and hope everyone used them correctly. Hope is not a concurrency strategy.

async/await doesn't make code shorter; it makes it readable. The win isn't in the line count — it's on the face of whoever opens that file six months from now.

That 'do not enter' function is thirty lines today, and every new hire understands it on first read. We haven't met anyone who misses the callback ladder.

How a Leak Is Born

Look at this function — it could be from a textbook:

void process() {
    Widget* w = new Widget();

    if (!w->init()) {
        return;            // leak: delete is never reached
    }

    w->run();
    delete w;
}

If init() fails, delete never runs and the Widget is orphaned in memory. If run() throws, same story. The problem isn't carelessness — it's entrusting 'clean up on every exit path' to a human. Humans forget. The bigger the codebase, the more they forget.

RAII: Let the Object Do the Cleanup

C++'s answer has a bureaucratic-sounding name — Resource Acquisition Is Initialization — but the idea is one sentence: tie the resource to an object's lifetime. When the object leaves scope, its destructor runs and releases the resource. How you leave doesn't matter — normal flow, early return, an exception... the destructor always runs:

class FileHandle {
public:
    explicit FileHandle(const char* path)
        : file_(std::fopen(path, "r")) {}

    ~FileHandle() {
        if (file_) std::fclose(file_);
    }

    // Copying is disabled so two objects never close the same file.
    FileHandle(const FileHandle&) = delete;
    FileHandle& operator=(const FileHandle&) = delete;

    std::FILE* get() const { return file_; }

private:
    std::FILE* file_;
};

There's no 'remember to close the file' task anymore; the moment a FileHandle leaves scope, the file closes. std::lock_guard, std::vector, std::string — the standard library is built on this same pattern. You've probably been using RAII for years without naming it.

Smart Pointers: Life Without new/delete

The same pattern comes prepackaged for pointers: unique_ptr for single ownership, shared_ptr for shared ownership.

#include <memory>

auto w = std::make_unique<Widget>();
if (!w->init()) {
    return;               // no leak; w cleans up after itself
}
w->run();

// Shared ownership: the object is freed when the last owner goes.
auto config = std::make_shared<Config>();
useConfig(config);

The entire bug class from the original process() — the forgotten delete, the double delete, the leak on the exception path — disappeared with a one-line change. The performance cost? Zero for unique_ptr; the compiled code is identical to a raw pointer.

One honest warning: shared_ptr is not a cure-all. Its reference count is atomic, so it isn't free, and cyclic references — A holds B, B holds A — never let the count reach zero. Make unique_ptr your default; reach for shared_ptr only when ownership genuinely is shared, and use weak_ptr on the edge that risks a cycle.

If you see naked new and delete in modern C++ code, either something very special is going on or a bug is waiting. Experience says: usually the latter.

Back to that 2 a.m. valgrind session: we fixed that leak by hand, because the codebase wasn't ready for smart pointers. The next month we made the rule — new code doesn't write naked new. We haven't been on a leak hunt since.

& Gives the Address, * Follows It

int x = 42;
int *p = &x;          // p holds x's address

printf("%d\n", *p);   // 42 — the value p points at
*p = 7;               // x is now 7; p points at it

&x answers 'where does x live'; *p answers 'what's at the place p points to'. They're inverses. When you write *p = 7, you're changing x directly, because both look at the same address.

The first real payoff of this idea is functions that can modify outside variables. Every argument in C is passed by copy — but pass an address and the function reaches the real data:

void swap(int *a, int *b) {
    int tmp = *a;
    *a = *b;
    *b = tmp;
}

int i = 1, j = 2;
swap(&i, &j);         // i == 2, j == 1

If you've ever wondered why scanf needs &num: that's the answer. You hand it the address so it can write the value it reads into your variable.

Arrays: Closer Kin Than They Look

The fact that surprises C beginners the most: an array name, in most contexts, turns into the address of its first element. This is called 'decay':

int nums[3] = {10, 20, 30};
int *p = nums;              // same as &nums[0]

printf("%d\n", *(p + 2));   // 30
printf("%d\n", p[2]);       // 30 — exactly the same thing

p[2] and *(p + 2) are two spellings of the same expression; the brackets are just shorthand. The subtlety people miss: p + 2 advances two ints, not two bytes. Pointer arithmetic accounts for the element size on your behalf.

const: A Promise to the Compiler

Every function that takes a pointer also receives the power to modify the data. const is how you hand that power back:

void printName(const char *name) {
    // *name = 'X';  -> compile error
    printf("Hello, %s\n", name);
}

One tiny keyword doing two jobs: it guarantees the caller you won't touch their data, and it gives you a compile error if you try by accident. Free insurance — be generous with it in your signatures.

The bad reputation of pointers comes, I think, from bad teaching. Diving into syntax before the address concept settles — without drawing boxes and arrows — turns the symbols into meaningless magic. Once the address idea clicks, though, arrays, strings, dynamic memory and linked lists all stack neatly on the same foundation. Nothing to fear; this is the heart of C.

Same Question, Two Different Answers

The software we're used to produces the same output for the same input. A language model doesn't — and instead of fighting that, you build the architecture around it. Rule one: never trust the model's output raw. If you expect structured data, validate against a schema and retry on mismatch:

const Invoice = z.object({
  vendor: z.string(),
  total: z.number().positive(),
  currency: z.enum(["TRY", "USD", "EUR"]),
});

async function extractInvoice(text: string) {
  for (let attempt = 1; attempt <= 3; attempt++) {
    const raw = await model.complete(prompt(text));
    const parsed = Invoice.safeParse(tryJson(raw));
    if (parsed.success) return parsed.data;
  }
  throw new ExtractionFailed();
}

When three attempts still don't fit the schema, the right move is an honest error to the user — not silently accepting bad data. A system that can say 'I'm not sure' earns far more trust than one that speaks confidently without being sure.

Context Beats the Model

The sentence we hear most on projects: 'Would a stronger model fix this?' Usually no — because what determines answer quality is mostly what you show the model. In a RAG setup the real engineering lives in the retrieval layer: a system that can't find the right document will fabricate, whatever the model. It has no other material to work with.

Stuffing the context window isn't the fix either. Ten irrelevant documents distract the model and inflate the bill. In our measurements, two relevant paragraphs consistently beat twenty added 'just in case'. Less, but on target, wins.

Don't Change Prompts Blind

You changed three words in the prompt; is the system better now? Without measurement, the honest answer is 'no idea'. For every critical flow we keep an evaluation set compiled from real user questions — inputs and expected behaviors, an ordinary file in version control:

{
  "input": "Who approved last month's AWS invoice?",
  "expect": {
    "must_cite_source": true,
    "must_not_contain": ["I guess", "probably"],
    "tool_called": "search_invoices"
  }
}

Whenever the prompt or the model changes, the set reruns; if the score drops, the change doesn't reach the main branch. This is the regression test of the LLM world. It took half a day to set up; in return, deployments stopped being gambles.

The Token Bill and the Three-Second Void

Nobody looks at cost in a demo; in production every request is real money. The most effective remedy is routing: send classification and short summaries to a small model, and save the big one for genuinely hard questions. That single decision cut our bill by more than half. On the latency side, streaming is non-negotiable: if the first word lands in 300 milliseconds, users don't mind a three-second total. Three seconds staring at a blank screen, though, is an eternity.

A demo is a showcase of the happy path; a product is the sum of the unhappy ones. With LLMs, that gap is wider than ever.

The chasm can be crossed. Schema validation, targeted context, an evaluation set and cost discipline — together they turn a mesmerizing demo into a dependable product. In order, and without rushing.

LCP: When Did the Page 'Arrive'

Largest Contentful Paint marks the moment the biggest piece of content — usually the hero image or the headline — shows up. In that project the culprit was a late-discovered hero image: the browser downloaded the CSS first and only then learned the image existed. The cure is telling it up front:

<link
  rel="preload"
  as="image"
  href="/hero.avif"
  imagesrcset="/hero-800.avif 800w, /hero-1600.avif 1600w"
/>

Then there's the webfont classic: sites that hide text until the font arrives show users a long blank stare. font-display: swap renders with a system font first and switches when the brand font lands:

@font-face {
  font-family: "Space Grotesk";
  src: url("/fonts/space-grotesk.woff2") format("woff2");
  font-display: swap;
}

Those two changes plus converting images to AVIF took that site's LCP from 4.1 seconds to 1.9. Nothing exotic — just making the browser's job easier.

INP: I Clicked, Why Is Nothing Happening

Interaction to Next Paint measures the time from an interaction to the first visible response. The chief enemy is JavaScript that locks the main thread for hundreds of milliseconds: while the browser is busy with one long task, clicks queue up and the UI feels frozen. The cure is splitting the work:

async function processRows(rows) {
  for (const [i, row] of rows.entries()) {
    handle(row);
    if (i % 100 === 0) {
      // Let the browser breathe every 100 rows:
      await new Promise((r) => setTimeout(r, 0));
    }
  }
}

Crude but effective: the long loop now yields the main thread periodically, and pending clicks get processed. There are nicer tools — scheduler.yield(), Web Workers — but the principle never changes: the main thread belongs to the user; you're a guest there.

CLS: I Was About to Tap It, and It Moved

Cumulative Layout Shift measures how much content jumps around while loading. Everyone has lived it: the paragraph you're reading dives down because a banner popped in above. The cause is almost always the same — images and embeds with no declared size. In modern CSS the fix is two lines:

img {
  aspect-ratio: 16 / 9; /* space is reserved before the image loads */
  width: 100%;
  height: auto;
}

The moment the browser knows the aspect ratio, it reserves the spot up front; nothing jumps. Same principle for dynamic banners and ads: reserve the area first, drop the content into it.

Lab tests measure your computer; RUM measures your user's phone. When deciding, look at the second one.

The lesson that project left us with: performance isn't a one-off spring cleaning, it's managed like a budget. Every new feature spends from it. Keep measuring and the debt stays visible before it piles up; stop, and it comes back with interest.

The Boolean Swamp

The classic example, because it's still everywhere: three separate fields — isLoading, isError, data. Three fields give you eight combinations; three of them are meaningful. A state that's both loading and failed doesn't logically exist — but it exists in the type system, and one day it shows up in production. Model the state as a discriminated union and the absurd combinations drop out of the language:

type State =
  | { status: "loading" }
  | { status: "error"; error: Error }
  | { status: "success"; data: User };

data is now reachable only on the success branch. Code that tries to read it while loading doesn't even compile; that whole bug class dies in the editor, long before production.

The lesser-known bonus of this pattern: combined with switch, the compiler catches missing branches too:

function render(state: State) {
  switch (state.status) {
    case "loading":
      return spinner();
    case "error":
      return alert(state.error);
    case "success":
      return table(state.data);
    default: {
      const missing: never = state; // breaks here if a new state is added
      return missing;
    }
  }
}

Six months later, when someone adds { status: "empty" } to State, this switch fails to compile and every place that needs updating reports itself. The compiler writes your to-do list.

When Everything Is a string

User id: string. Email: string. Order number: string... When they're all the same type, nothing stops you from writing sendEmail(user.id). Branded types turn that mix-up into a compile error:

type UserId = string & { readonly __brand: "UserId" };
type Email = string & { readonly __brand: "Email" };

function sendEmail(to: Email) {
  /* ... */
}

sendEmail(user.id); // compile error — an id is not an Email

At runtime these are ordinary strings; the cost is zero. But for values where a mix-up is expensive — money, dates, units of measure — this zero-cost fence prevents real accidents. The Mars Climate Orbiter was lost to a metric-imperial mix-up; a well-shaped type system would have caught that before launch.

Validate at the Boundary, Trust Inside

Types only hold inside your own code. Calling as User on JSON from an API is not a fact — it's a wish. Do runtime validation at the boundary; inside, trust your types with a clear conscience:

const User = z.object({
  id: z.string(),
  name: z.string(),
  age: z.number().int().min(0),
});

const user = User.parse(await res.json()); // blows up here if it doesn't fit

Now the failure happens at the door where the data enters, with a readable message — not three layers deep as 'undefined is not a function'.

as is an expression of hope; parse is proof. Demand proof at the boundary.

Once you start treating types as a design tool, something interesting happens: you see the gaps in your design while modeling, before writing any code. The compiler makes you answer 'what happens to this field in that state?'. A type definition that feels bad to write is very often the first symptom of a bad design decision.

The Five-Minute Test: Drop the Mouse

The fastest read on your site's state: put the mouse away and navigate with Tab, Enter and the arrow keys only. Can you see where focus is? Can you reach every button? Can you close that menu with Escape? An interface that fails this test is broken not just for disabled users but for everyone who prefers working from the keyboard.

The mistake this test catches most often is well known: building buttons out of divs.

<!-- Looks like a button, does none of the job: -->
<div class="btn" onclick="save()">Save</div>

<!-- Keyboard, focus, Enter, screen reader — all free: -->
<button type="button" onclick="save()">Save</button>

The first one works with a mouse and stops there: it can't take focus, doesn't hear Enter, never tells a screen reader it's a button. You could patch all of that back with tabindex, role and keydown — but why? The right HTML element does with zero lines what a hundred lines of ARIA patchwork can't.

Structure Is Told, Not Shown

A screen reader user doesn't scan the page visually; they listen, jumping between headings and landmarks. That's why <nav>, <main>, <header> and a sane heading hierarchy aren't a 'clean code' aesthetic — they're an actual navigation instrument. Alt text is part of the same job, and a craft of its own: 'chart' carries no information; 'line chart showing revenue up 20 percent in Q4' does. The rule is simple: don't describe the image, convey what it says.

Color Can't Speak Alone

If you marked invalid form fields with red alone, then for a color-blind user you marked nothing — and that's one in twelve men, not a rounding error. Color always needs a second channel: an icon, a label, a pattern. Contrast is equally non-negotiable; that elegant light-gray text disappears on a phone screen at noon.

Motion is less talked about, but for some users it's not comfort — it's health: large parallax and sweeping transitions can trigger genuine physical nausea in people with vestibular disorders. Respecting the user who asked their system to reduce motion is one media query:

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Captions were invented for deaf users; today we all watch videos with them on the subway. What's designed for the constraint gets clearer for everyone.

Since that user test, the team rule is: every new component gets keyboard-tested before merging, every image arrives with its alt text, every color is chosen with its contrast. On paper it looks like extra work; in practice, next to the cost of fixing it later, doing it right up front is nearly free.

Don't Deep-Track Everything

By default Vue makes every level of an object reactive. Attaching a tracker to each of 5,000 chart points just burns memory — you never mutate those points individually anyway. If you replace the data wholesale, tracking the reference alone is enough:

import { shallowRef } from "vue";

const points = shallowRef<Point[]>([]);

// Replace wholesale when new data arrives — one trigger:
async function refresh() {
  points.value = await fetchPoints();
}

The rule in practice: if you reassign rather than mutate, use shallowRef. In our dashboard this was the single biggest win; memory visibly dropped and the stutter on large updates disappeared.

Fat computed, Lazy Chain

The second culprit was one giant computed doing everything: filter, sort, group, sum — all in one. Any dependency twitching reran the whole chain. We split it:

// Before: everything in one computed, everything reruns on any change.
// After: each link runs only when its own input changes.
const filtered = computed(() => rows.value.filter(matches(query.value)));
const sorted = computed(() => sortBy(filtered.value, sortKey.value));
const total = computed(() => sum(sorted.value, "amount"));

When the sort key changes, filtering no longer repeats; only sorted and downstream recompute. Small computeds are both faster and more readable — nobody could tell what was going on inside the giant one anyway.

v-memo: Powerful, but Sharp

The final touch: v-memo on the table rows. A row skips re-rendering as long as its dependencies haven't changed:

<tr
  v-for="row in rows"
  :key="row.id"
  v-memo="[row.id === selectedId, row.updatedAt]"
>
  ...
</tr>

When the selection changes, only two of the 5,000 rows — the previously and newly selected — re-render. But let's be honest: v-memo is a sharp knife. Get the dependency list wrong and you've told Vue 'never update this row'; the UI goes silently stale. We use it only on a measured bottleneck — never 'just in case'.

Measure first, then optimize — but once you've measured, don't hesitate either. Optimization by guesswork creates more problems than it solves.

The outcome: first paint halved, the typing freezes gone, and the code more readable than before. That's the satisfying part of performance work — once the diagnosis is right, the fix is usually a few lines.

Decisions, Not Values

What a design system actually standardizes isn't colors — it's decisions: how many variants does a button need? When does a card get a shadow? When is the error color used — and more importantly, when is it not? A palette picked before answering those questions is a pretty color collection, nothing more. Values are the output of decisions, not the input.

Three Layers: Raw, Semantic, Component

Our token architecture has three layers, and components never look at raw values — only at semantic roles:

// 1) Raw values — no meaning, just constants:
@berry-500: #ff3d77;
@ink-900: #0a0a10;

// 2) Semantic roles — 'what is this value for':
@color-danger: @berry-500;
@surface-base: @ink-900;

// 3) Component tokens — one specific use:
@button-danger-bg: @color-danger;

At first glance it looks like a needless indirection — until the first theming request arrives. Dark theme, branded white theme, high contrast: all of them come out of changing only the second layer, without touching a line of component code. The moment you write #ff3d77 inside a component, that flexibility is gone; the value now lives there and won't travel.

Resist Variant Inflation

On the component side the principle is the same: a Button offers 'primary, secondary, danger' — not 'blue button, red button'. The designer says 'this action is destructive', the developer picks the danger variant; what color that is stays the system's internal business, not the page's.

Keeping the variant count low is a conscious fight. Every new variant is another surface to test, document and keep consistent. Those 14 buttons in our first system taught us the lesson: everything added 'just in case' becomes the fastest-rotting corner of the system.

The One Hard Rule

The rule that has kept the system alive for two years is one sentence: no value that isn't in the design enters the code, no component that isn't in the code enters the design. Both sides feed from the same token source. The rule gets annoying at times — the 'it's a two-minute job, I'll just hardcode it' temptation never dies — but those two-minute jobs are exactly what kills systems. Special-case CSS is the first sign of rot; let one in and more will follow.

A design system isn't a project — it's an agreement. Projects end; an agreement lives as long as both sides honor it.

Our second system has been growing for six months without a single line of special-case CSS. Opening a new page no longer means writing CSS; it means arranging existing components. And everything we learned from the wreck of the first system sits under this one — which might be the real first step of building a design system: crashing one.

Don't Reinvent the Spring

iOS's spring animations are the product of a decade-plus of tuning. An animation with the right duration but the wrong curve leaves users with a 'something's off' feeling they can't explain. With the real thing available, there's no reason to draw curves by hand:

withAnimation(.spring(response: 0.35, dampingFraction: 0.8)) {
    isExpanded.toggle()
}

Two parameters, and the animation speaks the platform's language. Haptic feedback lives in the same cheap-win category: a tiny, well-timed tap — sensoryFeedback(.success, trigger:) — gives an action the feeling that it 'really happened'. These aren't decoration; they're the building blocks of user trust.

Keep Views Dumb

The one principle we hold onto tightly in architecture: views are dumb. They know no business logic; they take data and draw. State management lives in the container layer, navigation in its own:

struct AvatarView: View {
    let user: User

    var body: some View {
        HStack(spacing: 12) {
            Circle()
                .fill(.pink.gradient)
                .frame(width: 44, height: 44)
            Text(user.name)
                .font(.headline)
        }
    }
}

The everyday payoff of this split shows up in previews: a dumb view can be previewed on its own, without booting the app. We sit with the designer looking at the same screen and settle the 'should this gap be 4 or 8' debate on the code, instantly. Previews became our living design document; the 'is it actually the same?' gap between Figma and code closed.

Knowing Where the Border Is

SwiftUI has matured, but it's not the weapon for every battle. Text editors that demand millimetric control, camera interfaces, very custom scroll behaviors — there we still drop down to UIKit and bridge with UIViewRepresentable. There's no defeat in that; the craft is knowing where to draw the line. A dogmatic 'everything must be SwiftUI' stance is the most reliable way to turn a simple task into an epic.

The question is no longer 'can SwiftUI do it?' — it's 'where is it done cleanest?'

Where things stand today: the native feel comes nearly free, and you spend your effort on your own product decisions instead. A one-person team that respects the details can ship something App Store quality in weeks. 'Wouldn't Flutter have worked?' It would have. But the difference is felt in those first three seconds users can't put into words.

The Comfort of Atomic Change

The real promise of a monorepo is one word: atomicity. Rename a field in the API schema and the web and mobile code consuming it update in the same pull request. Whatever breaks is right there in the diff, in front of your eyes. In separate repos the same job becomes a version-bump dance: publish the package, bump it in three repos, keep a table of which version is compatible with which. In one repo, the main branch is consistent with itself at every moment — for us, that was the sentence that ended the architecture debate.

The Setup: Less Than You'd Think

Our recipe is pnpm workspaces + Turborepo; the core is two small files:

# pnpm-workspace.yaml
packages:
  - "apps/*" # web, mobile, api
  - "packages/*" # shared: ui, config, api-client

{
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": { "dependsOn": ["build"] }
  }
}

^build means: before building a package, build what it depends on. Turborepo works out the task graph and serves everything unchanged from cache. As the repo grows this cache becomes gold — the repo tripled in size and our CI is still faster than on day one.

The Real Issue: Layer Discipline

The bad news: tools won't save you. Where monorepos collapse isn't technical, it's disciplinary — boundaries blur, everyone reaches into every package, and six months later you're holding a dependency tangle the size of a repo. Our rule is one-directional: apps may depend on packages; packages never on apps. And we entrust the rule to lint, not to people:

{
  "rules": {
    "import/no-restricted-paths": ["error", {
      "zones": [
        { "target": "./packages", "from": "./apps" }
      ]
    }]
  }
}

Once the ban is automated, the debate ends too: a violation is a red CI mark, not a difference of opinion in code review. People spend their energy on the work, not on remembering rules.

As the repo grows, add automation, not rules. A rule enforced by tools is permanent; a rule people remember lasts until that person goes on holiday.

One honest footnote: a monorepo isn't free. CI takes real effort to set up, git history gets crowded, and misconfigured, everyone ends up waiting on everyone. For products that don't share a contract and live separate lives, we still recommend separate repos. But ever since that three-day production bug, we can't accept code that speaks the same contract living in different houses.