The product runs and customers use it. That’s the trap: it worked well enough that nobody had to understand it, until the day someone did.

  • The person who built it left years ago
  • Documentation is a README from 2019
  • Small changes take weeks, out of caution
  • One deploy everyone is afraid of
  • An error log nobody reads anymore

How the reading goes

Reading other people’s code is the job.

  1. Read it

    I get the project building and trace the flows your business actually runs on: sign-up, checkout, whatever earns the money.

  2. Write it down

    Understanding stays perishable if it lives in one head, so the deliverable is understanding you keep: documentation, a map of where the risk sits, and a person who can make changes with confidence again.

Where I’ve done this

I’ve built inside big established codebases, including Twitch’s, where the conventions were someone else’s and understanding came before changing anything.

If what you need after that is someone who stays close to the code week after week, that’s fractional work, and the two connect naturally.

Also: iOS apps · Web apps · An existing product · Fractional work · All services

Tell me what you're working on

I've got room for a few new projects. Write to me and I'll reply with how I'd approach it. I read every message myself.

hello@nerdtower.com