Profile / Krish Gera

Build the thing. Understand the system.

Product Designer. Product engineering at Rebuildr, with a background in security and a habit of working inside other people’s systems until their behaviour makes sense.

The work matters. So does the reasoning behind it.

Engineering as a practice

My work is product software: features and fixes on a live product, and the small decisions that have to keep making sense after they ship. I’m interested in the whole system: the implementation, its constraints, and the consequences of a change.

An adversarial perspective

My background is in security: hands-on Hack The Box Pro Labs (Dante and Zephyr, 2024) and freelance threat-intelligence work on external exposure and attack surface. It shows up in how I read a system, including asking what an API reveals to someone who shouldn’t see it.

Thinking in public

I write to make technical ideas easier to examine. LEMMiNO’s way of explaining complex subjects is an influence. Disagreement and corrections are welcome.

Read my writing

Chronology The route so far

Engineering log
  1. Now: Production work.

    Product engineering at Rebuildr: shipping and maintaining software that people already use.

    • Rebuildr — Product engineering
  2. 2026: Writing, and working upstream.

    A published guide to operational security. Then a bug report in someone else’s codebase that became two merged fixes, and a lesson in how far one change reaches.

  3. 2025: People used it.

    The game modification from the previous December became the most downloaded Alien: Isolation mod on Nexus Mods for the year.

  4. 2024: Reading systems from the other side.

    Long, hands-on security labs: enumeration, lateral movement, trust boundaries. In December, a public release that changed how an existing game behaves.

    • Peaceful Sevastopol released
    • Hack The Box Pro Lab: Zephyr
    • Hack The Box Pro Lab: Dante

Drawn from the stories Patterns in the work

  1. Understand the existing system before changing it.

    Find where the behaviour is actually decided, then change it there.

    Seen in GROWIPeaceful Sevastopol

  2. The right small change can move the whole system.

    Leverage comes from placement, not from the size of the diff.

    Seen in Peaceful Sevastopol

  3. Good engineering includes knowing what not to change.

    Scope is a decision. What stays untouched is part of the design.

    Seen in Peaceful Sevastopol

  4. A fix is only correct if the rest of the system agrees.

    Clients, translations, and security properties depend on behaviour a single route cannot see.

    Seen in GROWI

  5. Prefer evidence over confidence.

    Tests that exercise the real path, run more than once, beat an argument that the change is right.

    Seen in GROWI

  6. Keep changes small enough to review honestly.

    Split the work so each review can be about the behaviour, not the size of the diff.

    Seen in GROWI

For engineering conversations, collaboration, or feedback on a piece of work.

Get in touch