What I eventually came up with was pretty much exactly what this post is advocating for. YAGNI was the rule, I was new and wanted to demonstrate results quickly. Instead of classes, I put constants in modules, realizing that all that a class I'd written was holding was basically a hash, and since that data wasn't changing anytime soon, they might as well go in a constant.
I caught the refactoring bug sometime around when I was tasked with adding a third service. I found turning the logic I'd created into proper classes incredibly easy, make changes, run rspec, rinse, repeat. The interfaces between the various pieces were surprisingly loose. So I could play around with different implementations of a piece of logic and at every point have something that could be made to work if I suddenly had to shift gears.
I had two services and they were each slightly different. Waiting to build the abstractions until I had multiple implementations of them wound up being a big win. Now that I have a third, I can already tell that it's going to be an easy add. I spend much more time figuring out service-specific stuff than wrangling with my code.
Hard-coding really does get a bad rap. You're not building a castle, you're fixing a pressing business need. If you do it well, then one day you'll be able to open-source your work, because your company will want to add more and more to it because of how badass it is. Not because your delusions of grandeur led you to over-abstract everything to the point of uselessness.