How can a non-technical founder tell if their developer is doing a good job?

05.10.26 · Elastic Mint

As a non-technical founder building a piece of software, you need to rely on other people and their technical skills. But how can you be confident that they are doing the job you need? How can you be sure that they are laying down good foundations for the future? You cannot judge the code, but you can judge what they deliver and how they work with you.

What can you judge without looking at the code?

If you are not technical it is easy to feel out of your depth when talking to your developers. So what are some of the signs to look for as to how things are going?

A good place to start is with how often you see working software. Development teams often work in two-week intervals called sprints, and at the minimum you should see something new at the end of each one. When we built the first version of Benefits Buddy, a staff benefits platform, we demoed it every week after the first fortnight and talked through what we were doing next. Since then the work has come in smaller pieces often only a few weeks long, and so we have typically shown once part-way through and once when we think we are done. This has enabled us to respond to any feedback and ensure that what is delivered is right.

Another area to look at is how often you find bugs. It is normal to find a few, and your developers should fix them quickly. But if you keep finding lots of them, or fixing one problem regularly causes others, then something is not right.

It is not unusual for a project to have a couple of hiccups along the way. The important thing though, is how you hear about it. Does your developer quickly tell you about any problems, or do they try to hide them and hope you do not notice? No-one likes to hear bad news, but it is much better to know than not know, because you are the one who has to decide whether to cut scope or spend more money.

Finally, notice how your developer handles your ideas. In the end if you insist on something, your developers should build it. However a good developer sees their job as helping you make the right decisions as well as writing the code. When you suggest something they think is not a good idea they should explain their concerns and talk it through with you. They should also be able to explain what they have built, in terms you understand, and show that they understand the business problem it solves. A good developer will also work with you to turn ideas into good requirements and help you understand a realistic budget for any piece of work. Priorities will change along the way, which is normal in any software project.

There are a couple of warning signs you can spot without any technical knowledge. If releases can only be done by one person and make everyone nervous, the process is probably manual and fragile. Another warning sign is being told that something needs to be rewritten. A proof of concept can be thrown away once it has done its job, but a minimum viable product should be good enough to go live, so if it needs a rewrite at that point something has gone wrong.

If you are still choosing someone, should you hire a developer or an agency covers that decision.

Code ownership, hosting and accounts

A key question to work through with your developer is where the source code lives, and how the application is hosted. It is very often convenient for your developer to set up a private Git repository for the source code, and to host any web application themselves. We would certainly offer that, especially to people who do not already have this set up.

You do need to think though about what happens if your relationship ends with the developer. These resources should be transferred to you or someone you have chosen, without any downtime of your application. Remember, it is your application, and your intellectual property.

The one thing it is usually easier for you to set up and keep in your name is Apple and Google Play developer accounts if you are developing a mobile application.

Getting a second opinion

Sometimes it is worth paying someone else to review the work. You may have a feeling that something is wrong, or the person who built it may have gone. If an offshore team built it, a review gives you someone representing your interests, even if you carry on working with them.

When we do a review, we build and deploy the code ourselves and look at the architecture, database, hosting, backups and security, including things you cannot see from the outside, such as passwords written into the code. At the end you get a written report, presented on a call, with guidance on what to do next.

Be careful about when you ask for one, because a second opinion can easily be understood as a lack of confidence in your developer. It is most useful at natural moments, such as before raising money, before starting a large piece of work or when the team changes. Otherwise, the easiest way is to agree at the start that the work may be reviewed from time to time.

What to do next

Look back over the last few weeks and ask yourself whether you have seen working software, whether you are finding a lot of problems in it, and whether you heard early when something was going to be late. If you can answer those confidently, your developer is probably doing a good job, and that relationship is worth looking after.

If you cannot, tell us what you have and what is worrying you, and we will tell you whether a review is worth paying for. If it is not, we will say so.