First of all, it’s important to build a good foundation before you start hiring people. Decide on coding standards, and the basic tech stack, and make sure you have a nice project management system and process in mind. Nothing worse than hiring people only to discover they aren’t capable of working in the environment you’re giving them.
The biggest question is do you want to recruit top-tier talent, or do you want to recruit locals and train them up? This sets your salary ranges and it tees off what kind of internal culture you want for your people. Like with anything, it’s best to establish the tone and culture of your company early and shepard it along as you bring in new people. If you don’t think about these things, you’ll pretty soon find you built a company with a lot of discontentment inside of it. Literally, if you don’t explain to people your values and that they should take a day off every once in a while, people will assume the worst and hate you for it. Everyone wants to work for a CEO who acts like a decent person. It’s the biggest draw there is.
On top of all that, things are competitive out there, and any programmer worth a damn will want a great benefits package with 401K, medical, the ability to have agency over their lives (shouldn’t have to check in with six people to schedule an appointment or take a day off), etc etc. I actually bring this stuff up during interviews, if the applicant isn’t asking about this stuff they should be thinking about it. Treat employees the way you want to be treated, if you want to take a half-day every once in a while assume the team does too. Don’t just assume they’ll take it upon themselves to make it happen, either.
Typically, experienced people want to feel stability and the hope that they won’t be over-burdened with work like earlier in their career. You need people with experience. You may hire a fleet of developers, and discover not one of them understands how to deploy your application or host it. These people tend to have past experience with pushing against their management, and one draw for them might be control over things as they wanted in the past.
In my experience, you typically hire a few experienced people to ensure you can hit every note, and then you pack them in juniors to toe the line. Everything from above will look pretty lucrative to a junior, and one thing about a good developer early in their career is they almost always want to learn how to move up the ladder. Being able to tell them in an interview that there is talent above their station, and they can learn from them and get promoted to their position someday, is a pretty good starting point for luring them over. Just keep in mind that if they become that senior, you need to do something to keep them satisfied or they’ll just dump you.
So again, work out where you want to be in the market. If you want to build great software, make sure you understand what that means technically and you maintain that standard like it means something. Build a decent employment package, hire experienced engineers and attract them with the employment package and methodology. Then find juniors who can learn something from that, and you’re off to the races. Don’t forget project managers!