Yea, you identify bottlenecks and refactor those as needed (with something like rails it's pretty easy to change out parts of your system while retaining the rails core). Every business will have different bottlenecks and it's very hard to identify them before you start accumulating customers and see how they are using your app

Literally yes. Outside of a few very basic common sense optimizations (avoid n+1 queries, use indexes liberally, maybe sprinkle some caching on heavily used endpoints) you should focus entirely on shipping features with the knowledge that your product and by extension your code almost certainly won't look anything like it does now in 18-24 months.

Cost of capital for a startup that is succeeding is almost always far higher early on, so you want to focus on moving fast over scaling as long as you can scale enough to get to big enough raise to throw far more resources at the problem.

There comes an inflection point in a startup when you have to move from MVP to scale, and there are two different kinds of tech and two kinds of people for each stage

If you are fire-fighting production issues at scale all the time with the original version, you may find yourself out-of-capacity for a refactoring/rewrite. After experiencing this terrible state of affairs, I prefer getting performance and robustness (mostly) right the first time.