When I have a first conversation with a new client, they are always eager to get underway. Naturally, you want the shortest development timeline possible. When you sign a contract for software development, you want to get your idea first to market or you have internal company deadlines to meet; both of which are very real business pressures. How should you prepare to get your development team off to a fast start and not stalled in the starting blocks?
Project Purpose
What are we making? I’ve had many kickoff meetings with new clients who could not articulate what the software we are building should actually do. Don’t hire someone to develop software when you only have a vague concept for a product or market solution.
For example; “I think fans want to know more about the players on their favorite sports teams” is not a defined goal to build software around.
You’re ready to hire a team for design and development when you can say, “This app will aggregate the social media feeds from all players on a professional sports team into one timeline for their fans to follow”. That is a goal we can build towards.
Defining the project like this is critical. It’s an essential part of your sales pitch to potential investors, to your boss, or to other decision-makers in your company. It will also be helpful when crafting your marketing plan.
General Requirements
What is the Timeline?
Schedule is often largely decided by the budget because it is the most tangible constraint. You need a go-to market product before the money runs out. Even if budget were no object, you have to think about getting your solution to market before your competition.
How about a more pressured scenario? Maybe your app launch has to coincide with a live event like the Super Bowl, or it’s a key piece of the viewer experience for a televised awards show. The Super Bowl and the televised awards show can’t be rescheduled just because your app isn’t ready. Your developer may be able to meet a compressed timeline by working extra hours or adding additional designers or developers to the team. Additional resources will require additional budget. The need for these resources should be discussed before project kickoff and not two weeks before the shipping deadline.
Who needs to test and approve the software?
You don’t need to have a group of people assigned for UAT (user acceptance testing) when you start development, but you do need to know who will test the app before it launches. If you’re an entrepreneur, that may be you, your family and your closest friends. As a business, it’s probably the department heads who will train their staff to use the app. If you will need the development team to do QA, they’ll want to know up front. Some development teams have QA on staff and some will have to subcontract it out. Also, developers doing QA on their own code should never be considered. Good developers will unit test and ensure their code does what it is meant to do, but only a second set of eyes from the user perspective can catch errors that the developers have subconsciously missed because they’ve been looking at the app for several weeks already.
Technical Considerations
This category could include a wide variety of questions. These are the basics I cover on the first call with a new client:
- What devices are we building for - iOS or Android? Mac or Windows? Combination of these?
- What platforms are we building for - Mobile? Web? Desktop?
- What is the minimum supported Operating System - will your target customer be on the latest OS or do we need to support (and test on) older versions?
- Will you need a custom server and does it need to be HIPAA compliant or meet other such regulations?
- Will we integrate with third party systems like analytics, push services, social platforms?
- Do you feel strongly about use of 3rd party libraries?
- Do you have specific architecture considerations or constraints?
- Are there legacy systems or codebases we’ll need to integrate with?
Each of those points could be an article in itself so I won’t elaborate on them here. Just give them some thought before you talk to a developer to obtain an engineering estimate because each of those can dramatically impact the cost and timeline to deliver your project.
Functional Requirements
List the core features you need in the app. You don’t need to provide every last detail of behavior, just a guideline. Here’s an example using the previous idea of a social aggregation app for sports fans:
- User profiles for fans
- Team profiles for teams to feature content to fans
- Teams I’m following
- Players I’m following
- Main feed with all activity I’m following
- Manage my notifications
Just that much information is enough to start the conversation. If you’re ready to further define what the experience might be like for users, then move on to writing some user stories.
User Stories
Some examples; again using our theoretical social aggregation app for sports fans:
- Users should be able to set up a profile, login with their email or SSO (single sign on) using their Facebook or Twitter login, and enter their own personal info including their hometown and favorite sports.
- A new user should be shown a list of their hometown teams to follow, they can select several from this list and then they will see a “next” button to select popular players on that team to follow.
- If a player/athlete has chosen not to participate and their social feeds are not in the app, can we give users a way to send a Facebook message or tweet to the player requesting that they join the app.
User stories like this become a guideline for developers to work from as they write the code for the app. While you don’t absolutely need user stories before talking to a developer, they will help the developer to provide you with a better estimate of the effort and time it will take to write your custom software.
Hardware
If your idea relies on a peripheral and the breadboard is still in development then you are not ready to discuss front-end software development. There are software simulations for virtual breadboards but those will still leave you several steps removed from shipping even after the front-end application is mostly built because you need to fully test before shipping. When you have a production-ready prototype with a firmware in place to control it, then an application developer can estimate what it will take to interact with that peripheral.
Design Requirements
Most clients come to us with no more than “back of the envelope” design. A rough sketch of what the primary screens might look like, along with some primary colors or fonts you like, will be a great jumping off point. Don’t expect a professional designer to take those suggestions and execute them as is. Instead, she will give you suggestions and help you shape your ideas into a polished user experience. Shipping an app with “developer art” is rarely a good idea. The first call with a developer is when you should ask how they handle the design process and if they work with a designer.
“Back of the Envelope” design before we started ElderCheck Now
Final design focusing on priority actions and quick visual uptake.
If you’re not sure what the screens should look like, provide a “go-by” example. Reference an experience that you like in an app you use every day. For example: “I like the way that Instagram recommends other users for me to follow” is a “go-by” for a user experience you’d like to create for your app.
It is extremely uncommon to have design completely done before you talk with a development partner. If you do have specs or a wireframe generated ahead of time, be ready to share those. The developer can better estimate the coding effort required based on those designs (are you starting to sense a theme here?).
“Nice to Haves”
“Nice to haves” are different from the functional requirements. Functional requirements represent the essential things your app must do before it can ship. After that, everything else is a “nice to have”.
This list should include ideas that you would like to do to enhance the user experience and keep them coming back to the app every day. You will look at existing apps and covet their feature set and all of the nifty ways they integrate with other apps or peripheral devices or even their fancy transition animations between screens. You want to ship a 1.0 with some of that awe and delight factor for sure. Keep in mind that the majority of that slick look and feel came after the app had established itself as a must-have. They became a must-have app by solving a specific problem or meeting a specific need.
Developers want to know your “nice to haves” so they can consider server needs and mobile architectures to accommodate future development goals.
Funding
Almost without exception, software developers will not be able to work with you unless you are able to pay them. Asking for work in exchange for equity only works if you are already a publicly traded company. Even then we all have to cover our own expenses and working on spec for several months with no income is tough to do for anyone.
In Summary
If you can answer each of the questions here with a relatively well thought out answer then you are ready to approach a developer. You want to give a prospective development partner as clear a picture as possible about the market you hope to reach, and the problem that your application is intended to solve for that market.
