This is actually a good thing. You've got something working, it doesn't matter if it's pretty. I've seen a lot of successful things that started out as ugly cod

This is actually a good thing. You've got something working, it doesn't matter if it's pretty. I've seen a lot of successful things that started out as ugly code. The ones that start out pretty and "architected" always collapse under their own weight before they ship. We've all written crufty legacy code, at least if anyone is any good they've written bales of it. I would respect that ugly code, because it shipped. What I don't respect is someone who claims code is great and doesn't need fixing. Now you need someone who can come in and turn it into something beautiful and scalable and whatever. So when you interview them, just lay out the situation. "How would you turn a terrible codebase into something great?" "Give me some examples of legacy code that you cleaned up 'in-flight', without starting over or disrupting operations or putting things on hold for six months". "What are some difficult bugs you had to deal with in a messy pipeline, and how did you fix them"? Ask about how they would improve real pain points in your current pipeline. If their answers are broad, ask them to be specific. You don't have to know what they are talking about, but if they can talk about specific steps and strategies, it will be clear they've done this kind of work before. If they are hand-waving about best practices and generalizations, and can't drill down any further, move on. Make sure they can actually write code, too, there's plenty of people out there who can talk about code but don't sit down and write it every day. If it's going well, take them out to lunch, tell them about this post. You need someone who you can trust and be honest with, someone who will give you honest feedback on technical decisions. You don't want someone who resents that you have less technical experience and are in a more senior role.