Codeflow will remain free for use on repos owned by small teams or individuals. If you had a larger use case in mind, we’d be happy to discuss more via email: usecodeflow@gmail.com.
My experience with large codebases is it is hard to follow a critical path, especially with multiple things running in parallel. This leads to lots of back and forth between the new engineer and the rest of his team, taking up time for both parties -- which is why we created Codeflow.
However, if there is a better way to follow the critical path/best practices that you do follow to do so, I'd be glad to hear them!
Looking forward to any insights you may have, and thanks for the feedback
We're changing the dimming of the non-highlighted code right now -- that's feedback that we've gotten before.
We're also looking into ways to embed code into the markdown, and scrolling to the relevant code is a particularly good idea.
I think a lot of the value comes from when you're not sure how to navigate the codebase, so I agree that the example doesn't show the total value of the code. In larger codebases that are harder to navigate, I expect these to be much more useful.
Right now, we save the ref of the commit the slide was created on, so it's possible that the code will go out of date, but the slides will always be in sync.
One niche we were exploring was remote teams. We saw that they generally resort to screensharing to explain code and thought that this may be a better, faster alternative.