Choosing and managing your web development partner company
Many people believe that choosing (and managing) a web development company is comparable to navigating a minefield, and for good reason. It has happened time and time again that I sit in a meeting with a prospective client and they tell me how they previously contracted another development house but they just had problem after problem. After dealing with this dev house for months and desperately trying to fix a myriad of bugs and problems, eventually most people cut their losses and start again. Imagine being 6 months and a fortune of money down, just to write it all off and start again. This guide therefore is aimed to assist those who are in the market for a web development agency. Whether you’re looking towards Ninja or any other agency, here are a few tips to mitigate your risk.
Once you have briefed your developers, don’t just sit around and wait for them to present an app 3 months later. It pays to be involved

Ask questions

As you know, a salesman will always tell you what you want to hear. When you are meeting with development companies for quotes, ask them questions about the size of their team, ask to see some of the most recent projects they have worked with, and you can even go so far as to ask for client references that you can call to verify their work. As an HR policy, I personally believe that portfolio speaks louder than a CV, and that same principle applies here. They can rave about their skilled team all they want, but the proof will be in the quality of the work they have produced and the level of customer service they provided along the way.

Cover yourself legally

Do you have a service level agreement in place? Will you own the IP once the project is complete? No one wants to fight a legal battle, but if it comes to it you want to have the law on your side. Insist on an SLA with your developers, and if you’re unsure of the wording consider consulting an attorney before signing.

Be explicit

I’m not implying that bad development experiences are the fault of the client in any way (a good development house should know to ask the right questions and guide the client), but it certainly helps to be as explicit as possible when briefing a developer. Don’t assume that what is obvious to you will be obvious to them, remember that you know your industry infinitely better than they do. Write lists, draw diagrams if you can, walk your developers through each part of functionality you require. If you struggle to do this, then perhaps it is worthwhile giving more thought to your project before briefing a development house in the first place – after all, if you can’t describe your project in detail, how can you expect someone else to build it?

Put in the time

Once you have briefed your developers, don’t just sit around and wait for them to present an app 3 months later. It pays to be involved – you’re well within your rights to insist on a project plan and meticulously track that the project is going according to plan. Ask for regular status meetings and demos where you can see the functionality progress from milestone to milestone.

Keeping on-time is a 2 way street

As above, it’s vital to insist on a project plan with set deliverables and timeframes, but you have to realise that those timeframes are just as dependant on you as they are dependent on the developers. When you are reviewing designs or demos, it is important to give quick and concise feedback. Where changes are necessary, be explicit as to exactly what is incorrect on the current version and what it should be changed to. This keeps reverts down to a minimum, and speedy feedback ensures that no time is wasted by the developers waiting on you.

Test everything

When it comes to the testing phase, don’t take anything for granted. I would recommend getting colleagues and friends involved to test all of the functionality on a range of different devices and browsers. Be very specific when reporting bugs and include screenshots where possible. I would also avoid sending hundreds of emails every time you find another bug – this can be counter-productive as certain issues may slip through the cracks. Rather compile a meticulous list for your developers. Trello is your friend – create a board and start listing bugs and attaching screenshots to each. Watch your developers tick them off one by one. Your developers will appreciate this organisation and you will have the peace of mind that all your bugs are handled.


Developers are notoriously bad with documenting their code (we’re hard wired to build, not to author), but this is arguably the most important part of the project. It is vital to insist on technical documentation from your developers outlining the entire application, database, dependencies, etc. Even if it means paying extra for this, it is a worthwhile investment because if for any reason you ever need to move to another developer, this will be the difference between being able to work off existing code and having to start again from scratch.

In summary, web development is an exciting but tricky endeavour to undertake. My parting words of advice would be to select your prospective development partner based on trust, but verified by portfolio and references. Keep a high level of involvement at every step of the journey and identify any potential problems as early as possible. Be very clear and concise with your developers, and most importantly, never assume anything.

Article by
Danny Nochumsohn
Co-Chief Executive Ninja
Free Consultation