OneSheep OneSheep

How to choose a tech partner

Undoubtedly there is a growing sense that ministries should harness technology to venture deeper into the cyber-connected-media-social world of today’s unreached. There is also a sense of urgency created by the big perceived lead that the secular world has over the church in this area. The gap can be narrowed by valuing technology properly, planning carefully and choosing the right technology partner. Here are a few guidelines to help avoid big disappointments.

Building the right thing

Apps are expensive. At least the ones with quality that can compete on the internet and app stores for people’s attention are. It is therefore almost always prudent to first spend effort and money to make sure the right thing is built. To pay $1,000 for professional consultation on the aims of the project can often save five to ten times that amount during implementation. Or it could be the difference between a disaster and a great ministry tool.

Before you go looking for someone to build your dream app, first look for someone who can assess whether your venture makes Kingdom sense. You also need advice on the appropriate technology to invest in.

A good consultancy will try to find out a lot about your ministry and goals before they start recommending solutions. They will have knowledge of off-the-shelf solutions that can be adapted. They will also be able to recognise the situations where building a bespoke solution is the best.

Building the thing right

Once you have some clear and tested goals and an informed chosen technology, you are ready to look for a tech partner to build your tool. If the folk who advised you are the same ones you are hiring to implement, look out for some common pitfalls. They might have vested interests in recommending a sub-optimal solution that fit their skill set. People who have delivered solutions on a wide range of platforms are more objective.

You are looking for people:

  • that you can afford
  • with the right skill set
  • with good references and a proven track record
  • who are enthusiastic (or at least sympathetic) to your cause
  • with a development approach that minimises risk

We’ll expand on this in a minute, but price is probably the least important factor. The things that should carry the most weight are good references and a risk-limiting development method.

So, risk can be controlled by these factors

Agile approach

If a potential tech partner does not follow an agile approach you should move on. The opposite approach that is still followed widely is called a waterfall” approach. This is where the developers very carefully specify every detail of the application before they start building. They then go away and build the solution to exactly match the contracted specification until they pull the covers off a polished end product.

With agile you start with a list of features. Each item is price tagged with points that indicate how much effort it will take to implement. You as the client are free to prioritise the list during the development process. In this way you can dictate that the more crucial parts are built first. You are very involved in the development which is done in short sprint cycles of prioritise, build and test. The continual usage and feedback as well as the points tagging, gives you full freedom to make changes to the feature list. At any point in the process you have a useful product that can be deployed or further refined as funding and time allows. So if your money runs out you still have a useful tool.

Code repositories and versioning

Developers who don’t properly manage source code with modern version control repositories like Mercurial or Git, should not be considered. You should make sure you have access and rights to the code repositories which is your intellectual property.


For most projects, having a set of automated tests that verify the correct behaviour of your application makes the long-term maintenance of the code a lot easier. Ask if they use any of these things:

  • TDD (test driven development)
  • unit tests
  • BDD (behaviour driven development)
  • integration or acceptance tests
  • CI (continuous integration)

For mobile apps, do they systematically test not only on emulators but on a range of real devices that they own or remotely via services like Xamarin Test Cloud and AWS Device Farm? Do they use services like Apple’s TestFlight, Test Fairy or Google Apps Beta and let you participate?

Open stack

Does your solution depend on other proprietary software and formats? Will it be developed in a coding language that is widely adopted and therefore cheaper to maintain? Examples of more accessible languages/​technologies include HTML5, Javascript, Python, PHP, Ruby, C# and Java.

Working together

Even if you live in the same building, you will have to use tools to manage and collaborate on your project. If your email inbox is that collaboration space, you are heading for a disaster. A good tech partner will use good collaboration tools like Trello, Basecamp, Hipchat, Slack, repositories and issue trackers. They will also use group video conferencing via Skype or Hangouts as well as a common file share like Drive or Dropbox. If most of your initial interaction is only via email – that will be your first warning sign. If they don’t insist on your full participation in every step of the design and development process – that would be another.

Posted on Nov 26, 2016 by Jannie Theunissen

Back to all posts