App Journal: Starting development with scope control while maintaining the big picture

Jon Henshaw shares his experience of making an app for Coywolf. In the second entry of an ongoing series, Jon describes the need to control the project scope while also communicating the full vision from the outset.

I just had the kickoff meeting with the sole developer that will be coding the new Coywolf App. The meeting went well and I attribute that to my experience working with developers for almost two decades.

While it rarely goes perfectly, I always try to learn from past mistakes and focus on what’s most important. For me, that includes keeping the project scope reasonable for the developer. That way it can be built correctly from the outset and in an iterative fashion.

Scope control from the outset

All software creators have a vision for what they want their app to be but it’s a mistake to try and build everything at once. Getting the fundamentals right, like choosing the best technology stack that can scale and grow with the product, is what you should be focused on first. Then you should build the services, on an as-needed basis, that will support the features.

The Coywolf App is going to be a CRM that utilizes open standards like CardDAV, CalDAV, WebDAV, and IMAP, but I’m not going to build all of those things now. Instead, I’m going to start by creating my own CardDAV server. Then I’m going to focus on making that server do all of the things that I need it to do in conjunction with a custom-built API.

Since the CardDAV server is at the heart of the CRM, I expect to build and iterate its functionality over several months. That means it’s unlikely that I will even consider doing anything with CalDAV or any other service until I’m satisfied with how the frontend and backend work with the CardDAV server. As part of the App Journal series, I will be sharing that experience along the way.

Communicating the big picture to avoid costly recoding

Maintaining control over the scope of a project is important, but it doesn’t mean you should ignore talking about the overall vision for the software. It’s important to communicate to a developer how you ultimately see certain features working. It shouldn’t be pie-under-the-sky ideas. Instead, it should be a description of how you want certain features to work within the grand vision of the product. Here are a couple of examples of what I’m talking about.

Decoupling account dependency on a single service

It is highly likely that in the future I will make the CRM available for a subscription without someone needing a Coywolf Pro membership. I communicated this with the developer to make sure he would make the account system flexible enough to support that. It doesn’t mean it will support it at first, but it does mean it will be configured in a way that will allow support for that in the future.

Support for third-party services

Even though I will be running my own CardDAV server, I know for sure that I would like to support third-party CardDAV servers, like the kind FastMail, Google, and iCloud support. While my service will be easy to use out-of-the-box and will take every precaution for privacy and encryption, I expect that many people will prefer to use their own servers. Having the developer know that has a direct influence on how he creates the custom API.

In summary, start small with the intention to iterate little-by-little. Don’t make a complete product. Instead, build it from the ground up piece-by-piece so you have a solid foundation from the outset.

Related Articles