Tips on finding technical co-founder?

I've had 2 interesting experiences recently that inform this (for me):

Be up front and honest about the exact state currently.
It's tempting to oversell and claim you have more users than you do or your idea is "validated" but friends & family using the app for free is not the same as paying customers. Making false claims only come to light later on causing the [potential] CTO to lose faith in everything you've said.

Do not commit to a specific solution, language, data store, etc.
No one, on the front-end, cares what language your app is written in and turning down a perfectly good CTO because they prefer a different language is, IMO, a mistake. It's not uncommon for companies to change language or data storage at some point in the future. A good CTO might be able to build a microservices architecture allowing a slow transition to a new language or data store. I had a phone call with someone who was "looking for a CTO b/c we don't know how to code; but the MVP is written in Django so the CTO must know Django". If I were an unethical person I'd say I know Django then rewrite the app in the language of my choice, if you don't know how to code you won't know anyway.

Backup, backup, backup.
Backup existing work. Especially if it was done by consultants or contract devs because they have no interest in business continuity, their goal is to provide the cheapest quote possible to win the business then keep overhead expense down to increase profit on their work.

Use a bare minimum of dev best practices.
If you're building a no-code MVP or hiring a contractor to build the MVP at a bare minimum have user accounts so you can revoke access and run a development server and a production server. I had another call recently where contract devs were logging in (via FTP) to the production AWS server and doing development on the production web app. Even no-code it's easy enough to have a development copy, make changes there, confirm working, then make the same changes on production. If you don't have a bare minimum of best practices then accept that the new CTO will have to take time in the early days to get set up and build business continuity.

Use a bare minimum of project management best practices.
A good CTO will want to see your backlog, if you don't have one, if it's in your head, it's in 100 emails, or whatever else it's going to take up-front work to transfer that knowledge to the CTO and, again, build business continuity by documenting it. Trello and Google Docs are free, use them.

Have an elevator pitch.
Be able to clearly/succinctly communicate the problem you are solving and how you plan to solve it. Better yet, have some insight into market size, existing competition, price points, etc. A good CTO will only join viable businesses.

At least start working on a functional spec.
There's a great 4-part series on it here: https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-bother/
This is something you can start on without any technical expertise but it'll help you define the problem/solution, bring on technical people, and potentially win investors.

I'm sure there's more but that's all I can think of for now.