I think the "be your own CTO" advice for non-techies starting out with just an idea is always solid. I had a similar programming background to you and for over

I think the "be your own CTO" advice for non-techies starting out with just an idea is always solid. I had a similar programming background to you and for over a decade I was working on the business side of things, successfully launching product from sales, marketing and business development roles. However after having technical co-founder issues twice I recognized I needed to learn how to, at least in the early days of testing an idea, be my own technical co-founder. How to hack the initial stages of an MVP together in order to test things out. I learned Ruby on Rails back in 2010 and haven't looked back since. It's easy to pick up and there is so much good information out there on how to learn you can quite quickly, if you're smart and committed to doing so, build up from being an absolute beginner to a reasonable intermediate-level programmer able to put out a functioning minimal viable product. It won't be perfect, and you'll want to bring in the star programmers later. But it's not something you'll ever regret. A simple analogy which you may appreciate as an Algerian. As an English speaker if you go to Paris and only speak in English you won't find a Frenchman who understands a word you say. If you attempt your best French, however poor, you'll find people talking back to you in English and willing to help. Same with engineering talent. Every engineer is approached all the time by non-technical people with "an idea" who "just" need it implementing by a techie. Unsurprisingly these approaches don't get taken up often. However if you have a product that is viable and working and now needs making better, more scalable, more secure, you have something that you can engage other engineers in.