Finding developers

Finding developers is hard, and a non-coder has almost no chance of landing great engineers. Even large businesses have trouble finding great developers and they know how to vet them and people want to work for them with their high salaries. Freelance sites make it easy to find developers, but are they great? You can take the company’s word for it or look at reviews, but in reality there is no way to vet them as a person that can’t code.

Below we’ll go through your options and some best practices when trying to find developers for your business or startup’s app.

Finding Developers

This is tough for a non-developer. There are plenty of sites that you can hire freelancers and there are a bunch of firms available, but how do you know you are going to get what you are asking for and see in your mind’s eye? Even then, how are you able to judge the code and its implementation?

Businesses with their own development department actually handle this with multiple people with specific attributes. You can see those broken down in this post. To do this on your own you are going to be behind the 8-ball. It is our suggestion that you look for a firm or freelancer that comes with the experts you need. There are a few (like our team) that are out there.

Another large investment is in an intangible asset, the trust factor. No one person is responsible for an app’s development, it is a concert and just one out of of tune piece can ruin the whole thing. The app you’re building will have issues, it is part of the software experience, this is when you’ll need to draw on that trust in the team and work through the issues. It is very common for teams to fall apart and that has disastrous (and in the case of start-ups, killer) consequences on your app.

Write the specs needed (backlog is ideal)

Yet again non-coders will struggle with this, especially getting it to development’s standards. We have developed a create-a-quote tool that will start the process of building your backlog (more on that here). We developed this because it is nearly impossible for someone new to the process to develop their app as the level of technical knowledge needed is normally lacking to break items down to “irreducible” pieces.

This specificity required in these items is what ends up getting lost in many “statement of work” documents or large specs. There is a point of diminishing returns where your app’s plans have become so dense that they are actually going to break the app from the get-go. In development, the process is more of a building block type of construction. You can’t really go in with a full-blown app you are needing and come out with it in a reasonable amount of time, being used in all facets (making development worth it for all of those features), and error free. Even Gartner agrees, you need agile, iterative, development, the cost is just too high in time and money to do things any other way.

Lead Developers

Since you can’t just give a huge set of specs to a team and come back in 3 months to see the results, you need to lead development. This is very difficult again for a non-coder. There are many technical decisions that are needed. Most technical people like to spend time with their computers and understand to a deep degree what they are doing, input from non-coders is very hard to illicit. You really need someone like a Team Lead that is responsible for all of the “translating” to make sure everyone has everything they need and understand everything.

Leading developers is still possible, the right teams will have a person that acts as a defacto team lead (or a literal team lead in our case). This person will make sure development is responding in the correct way (in conjunction with the dev. rep. in our system) and that you understanding everything happening at any given moment during a development sprint. By being this involved, you (with help) are leading development and therefore out in front of any misunderstandings or bugs that arise (and they will).

Once you’ve finished the sprint, you will need to check it on a few devices, then with a larger set, and then test it some more. Your app will break in some respect, at some point. You will always be on the lookout for bugs and new problems that arise from something as simple as an Android or iOS update. When a sprint is finished, you need to “break it” in as many ways as possible on as many devices as possible to cure all the bugs you can get to. In the end, though, you also need a great feedback mechanism in pace so you can find them all as your users report them, as well as a way to know how to improve your users’ experience, keeping them on the app longer.

Iterate with the same team

As mentioned earlier, you will have problems pop-up out of nowhere. This is the reason agile development is based around a backlog. This allows the important items to surface to the top and less urgent needs filter down to the bottom. This sorting is what makes agile so fast and efficient with time and money. Therefore, you’re always developing. You can pause your sprints, but it is inevitable that you will need to do another sprint and the best apps are constantly developing their users’ demands into the app and updating every other week or so. Our membership, for instance, is based on 1 week sprints that end up having 2 week update schedules by the time QA is finished.

This is why trust & a team member mindset is required for development and not a one-and-done relationship like most contract work. This is also where the waterfall method that most firms employ fail. The partnership is not over until the app is done being used by users. There can be changes in development, but replacing the whole infrastructure is tenuous. Even small changes create ripples that take weeks (or months) to correct. These range from getting to the same level of vision to actually understanding and getting to know the code base. It is best to keep a partnership mentality about your development partner.

Closing thoughts

It may seem daunting, and it is, but in the end you will end up with an app that is competitive with teams with coders on staff and ahead of your peers that aren’t following these agile principles, instead relying on one-and-done, waterfall, development. Your app will be ahead of theirs by definition and the constant updates will be keeping users engaged to give you feedback, which makes the app develop into a better experience, and the cycle continues.