You’re not going to watch your developer type every single line of code into this app. But you, the customer, still want to see regular progress in some form, or maybe you’re just thinking of a change. It’s reassuring for any customer to know the project is on track. Also, your developer wants regular feedback from you, to know they’re doing the right thing. The following actions are indispensable cornerstones of the building process.

1. Talk to your developer

As a rule of thumb, you and your developer should talk several times a week during the building process. Regularity, especially regular communication, makes everything easier. You should schedule meetings with your developer on specific times and days, every week. Even if neither of you have anything new to report, have the meeting anyway just to check in with them.

2. Schedule Sprints

You should agree with your developer on a cadence of deliverables from them to you. I’d suggest having a new deliverable every two weeks. For this article, we’ll call these two-week periods “sprints”. You both also need to decide what the deliverable is going to be for each two-week period. This way, you should always know what app feature or design is currently getting worked on. You should always inform your developer how each chunk of work relates back to how real users are going to use this deliverable. This kind of context is important for them to have while they’re coding.

Describe to the developer how you’ll test the deliverable and what the acceptance criteria are for declaring the deliverable as completed. Depending on you and your developer’s business model, you may need to specify the budget allocated for this chunk of work. A miscalculation here could cost you vital time and money.

3. Choose your Methodology

Good development shops have a development methodology that they prefer to use. There’s a ton of methodologies, each with their own pros and cons. Two common methodologies in the software development community are Agile and Waterfall.

If you and your developer are convinced that the requirements and design are thoroughly specified and unlikely to change, then the Waterfall methodology may be for you. On the other hand, if your app is more of an evolution and a journey – that may cause deliverables to be discovered or possibly changed – then the Agile methodology may be a better match. The important point is to agree on a methodology that you understand and that your developer can reliably adhere to.

Remember, Agile and Waterfall are just instruments to help you and your developer. If you don’t give yourself any wiggle room and you obsessively adhere to a methodology, this will almost certainly cause problems. These methodologies are there to serve you, not to enslave you. Treat them like you would any other tool in the development process.

4. Pick your Deliverable Format

When you receive each deliverable, you’re likely going to ask, “how do I run this thing?” The deliverables have to be in a form you can deal with. For example, if the app’s an iOS application, is it delivered via TestFlight? If it’s a web application, does the developer provide a test site to test it on, or are you expected to install this web application somewhere?

Testing is probably THE most important part of the development process. While the developer will certainly test what they wrote (you should ask them how they did their tests), you need to do plenty of your own testing.

5. What to do if you want a change

What happens if you want to change what goes on in one of these sprints? These are called scope changes. If you do a scope change, know that the developer might not be able to finish the sprint on time. While some methodologies are prescriptive regarding scope changes, the important thing is for both parties to communicate and agree on a course of action. Someone could add or remove items in the sprint, change its length, or even change some of its financial information. Any changes must be agreed to by both you and your developer, preferably in writing.

Throughout this whole process, you’ll be communicating non-stop with your developer. Even if you don’t understand the technical jargon of all the coding they’re doing, you should know the purpose of every deliverable. Though the road might seem long and hard, before you know it, you’ll have the first version of your app completed. Then it’ll be time to see just what this baby can do.

Next time: Getting Your Money’s Worth