Software engineering3 min read
The short answer
Judge them on how they explain things, not on the technology they name. A good team asks about your business before your features, puts the scope and price in writing, shows you working software every week, and makes sure you own the code, the accounts and the documentation. If you cannot understand their answers, keep looking.
Why is hiring engineers hard if you're not one?
Because you cannot check the work yourself. A website can look finished and still be held together with tape, and you will not find out until it breaks in front of customers. So you have to judge the people, not the code.
The good news is that the habits of a good team are easy to see from the outside, even if the code is not.
What should you ask before you hire anyone?
These questions tell you more than any portfolio.
- What would you build first, and what would you leave until later?
- How often will I see something working?
- Who will I actually talk to, and are they the people writing the code?
- What happens when something breaks after launch?
- Will I own the code, the domain, the hosting and the accounts?
- If I hire my own team in a year, how will they take this over?
What does a good answer sound like?
It is specific and it is plain. They ask about your customers and how the work gets done today. They tell you what they would not build yet. They give you a price for a defined first version, not an open-ended number that grows every week.
A good team will also tell you when an idea is a bad one, before you pay for it. That is uncomfortable to hear and it is worth a great deal.
What are the warning signs?
None of these mean a team is dishonest, but each one should make you slow down.
- They quote a price before they understand the business
- You will not see anything working until the end
- The accounts and code will sit in their name, not yours
- They cannot explain a decision without jargon
- Nobody mentions what happens after launch
What should you own at the end?
Everything. The code, in a repository in your name. The domain, the hosting, the email and every paid account, billed to you. And documentation that explains how it all fits together, written for the next engineer rather than for the one who built it.
If you own all of that, you can never be locked in. You stay with a team because they are good, not because leaving is impossible.
Questions people also ask
- Should I hire a freelancer, an agency or my own developer?
- A single freelancer suits a small, well defined job. A small studio suits a product that needs design, building and looking after. Your own developer makes sense once there is enough steady work to keep them busy and someone who can manage them.
- Do I need a technical co-founder?
- Not to get started. Many businesses run for years on software built and looked after by an outside team. A technical co-founder matters most when the software itself is the product you are selling.
- How do I know if the code is any good?
- Ask for a second opinion from an independent engineer before you sign off a large project. You can also judge by the results: it rarely breaks, changes are quick, and another developer can understand it.
