I personally love trying to optimize and speed things up. On the flip side, I really hate doing CSS and Javascript front-end things (I can do them, but just prefer not to). Speed/optimization stuff (which I'm still getting better at every day) just feels more quantifiable and is a more interesting problem.
If the writer can open themselves to remote people, they've definitely got a better chance at pulling in some good people to help. But the one caution is against someone who wants to some in and do a rewrite of 90% of the stuff- optimize, don't start over.
I like to gently tear apart the tangled spaghetti code and figure out what data store goes with what process.
One thing I absolutely refuse to do is compromise on tools.
Telling the factory-trained Mercedes-Benz mechanic at the dealer where you bought your $120K SL550 that you want him to use only a hammer and a screwdriver to service the brakes on your car will get you laughed out of the dealership.
By that time, you're having to solve the "hard" problems. That's where a back-end guy shines.
This is where you need the pragmatic developers who you probably wouldn't have hired at the start. They are (relatively) slow and tedious, but the job will be done right. This tends to be a natural flow of from start-up to mature company.
Unfortunately companies rarely make this distinction when perusing candidates. After all, software is software, right?
I tend to find that these are long-term projects that could take 4 to 5 years to get done. You need a different type of person - and definitely the support of management - to make this a reality.
The weak point is there tends to be little interest from management. 'Why do we need to invest in fixing that? It's working already! We need feature [1, 2, 3] first.'