Working on the premise that very few businesses today can hope to achieve success without having something digital in their mix, even if it is only a website, we put together some insider tips for developing software applications: what to look for in a team and what to expect from their workflow.
good software development process begins with choosing a couple of development agencies to talk to.
Professional development firms will look to understand the product/market fit for your idea from the beginning because if the product they build succeeds in the market, you’ll have every reason to sing their praises, which will bring them more customers.
The first time you meet, they’ll want to know:
They’ll also want to know your budget.
You’ll want to know when the app will be delivered and how much it will cost.
Something to keep in mind is that until detailed product specs are clear, the cost for building your product is at best a ballpark number.
So, a good way to discover how much your product will in reality cost to build is to ask for a formal quotation in writing, detailing the work and the estimated timeframe, and then commission only the product specs part of the development.
Product specs are graphical wireframes and technical documents that show exactly how your product will work and how it will be built. When someone talks about product specs, they’re talking about the blueprints.
With blueprints in hand you will have everything needed to go into development and can pick any agency you’d like to work with. You’ll also be very clear on how much the development should cost and how long it should take.
One thing to watch for is excessive consultation bills for ‘product strategy’ before a single wireframe has been drafted. The free consultation professional agencies offer should cover the time needed to understand the product you want to build. You should only be paying for turning your product idea into product specs so you can confidently move forward with development.
MVP (Minimum Viable Product)
When looking to turn an idea into an app, there is no harm taking things step by step. Initially all you need to prove you’re onto something with your idea is a Minimum Viable Product (MVP) to test in the market and validate with feedback.
While it may be tempting to add lots of features, it is a good idea to keep your MVP as lean as possible in order to get to market as quickly as possible.
People will surprise you by how they use your app and what they tell you about it. The sooner you can test your MVP with target users, the sooner you can learn what the market really wants.
Something to keep in mind about a Minimum Viable Product is that the word ‘minimum’ does not suggest a low standard of performance. The capability of your app to scale to handle an increased workload, e.g., a sudden spike in users consuming more memory and data, is always baked into the architecture from the beginning. If after release many more users suddenly want to access your app, they should be able to without negatively affecting your app’s performance.
While you will be asked to sign a contract to create the product specs, you don’t want to tie yourself into a long-term commitment yet. First, see how the agency performs on the specs. If they do a good job with them, it is a solid indication that they will also do a good job on your app.
Agreements don’t need to be verbose. They should be easy to understand and very clear about requirements. If you find any complicated legal terms or long passages of unreadable text, ask for clarifications as you don’t want to sign something that you might later regret. If you feel uncertain about the agreement you’re signing, you should ask your lawyer to look it over.
At this point the purpose of any contract you sign should be to protect the confidentiality of everything you share, specify your ownership over everything that is created, and make it clear that the scope of work is only for the product specs, specifically:
Creating the User Experience (UX)
Before writing any code, the first step in product development is to try to understand who your users will be and how they should interact with your app.
When trying to imagine the kind of experience your users might enjoy, it helps to put yourself in their shoes and try to see things from their perspective.
Development agencies in general employ a couple of methods to arrive at an understanding of your intended users and the kind of experience they’ll enjoy:
• User Personas
Until you can release, test and validate your app in the market, you are stuck with imagining what users will want in your app. It helps to create User Personas, which are imagined profiles of users who are representative of your target market.
• User Stories
User Stories are an extension of the User Personas. They are a kind of storyboard describing each part of the experience that you and your development agency believe users will want in your app and why they will want it.
User Stories are written for every user interaction in your app in a format such as:
“As a user, I want to <do something> for <some reason>”.
• User Flow
User Flows are often referred to as wireframes, however wireframes only qualify as a User Flow if they logically step through the entire experience your users will have, screen by screen. If the flow is not very well thought through, your app is likely to irritate your users rather than delight them.
InvisionApp is an effective tool for hosting the User Flow. You can download and install the User Flow onto your phone and navigate your way through the app as though you were the user.
When working with a well-crafted User Flow, product design can be done at low cost since you won’t have to worry about expensive code changes while you and your team refine the shape and feel of your product.
At this stage you don’t need to worry too much about polished graphics. A polished user interface can easily be added into a development after the UX (User Experience) has been decided. The UX should always precede the UI (User Interface).
When choosing a product designer to create the user experience, you might need to make a distinction between a creative designer and a technical designer, the former being good at UI, the latter at UX. It is possible to find both skills in one person, but it’s rare.
Many creative designers believe they understand UX as well as a technical designer. Creative designers do have an understanding for both UX and UI, but when working with creative designers who are non-technical, usually it is a facility for UI that is prominent.
To bring the best out of a creative non-technical designer, it’s a good idea to show them the UX before you ask for the UI. Freeing a creative designer up from having to worry about the UX reduces their workload, allowing them to focus solely on creating a smashing UI to match the UX.
Creating Technical Documents
You’ll often hear developers talking about a frontend and a backend. Here is a quick overview of the difference between them:
The frontend part of an app is the part that users interact with directly. e.g., when you visit a website or open an app, it is the frontend, or presentation layer, you are interacting with. All apps have a frontend.
If your app will make network requests, i.e., if user interactions need to be stored in a database for later use (e.g., user sign-up and login), or if you need to control your app from a website admin panel, your app will also need a backend.
The backend refers to everything the user can’t see in the app, such as databases and servers.
The API (Application Programming Interface) document acts as the framework for how the app should be put together and for how the backend and frontend should talk to each other, and is the first technical document that will be provided. Apiary is a good place to host the API.
A Data Layer doc will also be required for any app that needs a backend. The Data Layer serves as a quick reference for how data models work and why. For each column there should be a short description which justifies its purpose.
The last technical documents to be created are the Architecture Maps which describe the frameworks that are being used and how they work together. Architecture Maps are required for all apps whether they feature a backend or not.
Off to the Races
With clear product specs and a development contract with an agency, all that needs doing is to set the project up in a couple of channels before going into code.
You might be asked to open accounts with several third party services, for example AWS or Rackspace to host the backend servers, with the Apple and/or Google Play stores, and with various other 3rd party services that your product may integrate, such as payments (Stripe) and analytics (Mixpanel).
Logins to all services can be controlled by you via a password service such as LastPass. This will help ensure you always retain control of the codebase and designs you are paying for.
Using a communications tool such as Slack, there’ll be a technical channel for the development team to discuss the engineering and as many other channels as you like to share information with your team about the product and its market.
At all times, you should have access to everything your developers are seeing, including visibility into the QA testing process and conversations between the teams. You don't have to check on them, but access is there in case you would like to.
You can expect the first test build within the first week or two, but it will only be a basic shell with one or two screens making network requests to the very beginnings of a backend.
The API doc shows how the backend communicates with the frontends, however until the functionality specified in the API is built, the API is just a document. Nothing much can happen on the frontends until the backend is up and running. This is why the backend is always built first.
Developers consider the backend to be an application in itself. While there may be thousands of happy users on thousands of frontends, there will only ever be one backend. If things aren’t humming along there, every single frontend will be affected.
Mostly what you will be seeing in the beginning stages of your development is your engineering team sputtering to life around you, getting things set up properly while placing the engineering focus on the backend.
What to Expect from the Workflow
Good development agencies work according to an Agile process, building your product in a series of small steps. You could expect one test build per week, called sprints or iterations, depending on the Agile framework used. Your product comes together in step-by-step builds.
If you make changes during the development, you will need to approve a Work Order to cover the extra development time needed to implement the changes.
This is why it is advisable to work with an agency that uses a Scrum framework for their Agile process. Scrum works well for new products as it allows flexibility when faced with the many unknowns new products involve, including the experience your users receive and the business goals your product should achieve.
Using Scrum, your team can more easily adapt the product roadmap as the work proceeds. Applying this level of care and flexibility to your project helps the development agency build an app that everyone can be proud of.
Quality Assurance (QA) & Release Notes
QA is vital. Even when working with competent developers who test their own code, your product will still need extensive manual testing on every platform by a team of professional testers. QA professionals take pride in seeing things done well and genuinely strive to help developers produce bug-free work, rather than taking perverse pleasure in criticizing them endlessly.
Along with each test build, you can expect Release Notes showing what is included in the current build and what to expect in the next, along with any pending items that need to be fixed so you’re not surprised by what you receive.
Distributing test builds for iOS
As well as distributing test builds to your team, you might also like to send test builds to your friends and contacts. Apple’s TestFlight service is included with your developer account, but it has a two-step confirmation process to get test builds onto phones and can be buggy sometimes. It works well enough for development builds, but it’s not usually convenient.
In place of Testflight, you could use a third party service such as Buddybuild or HockeyApp to distribute test builds. Both let you easily email a link to a user’s phone to download and install the app in a one-step process, though the free tiers that both offer will only allow for a few testers. It can get expensive as you increase the number of testers.
If you are building an app for iOS aimed for distribution inside an enterprise, or would like to run a controlled beta test before releasing to a wider market, Apple’s Enterprise program offers the best value. It will allow you to install iOS test builds on 100 devices via a private link that can be emailed to users.
It can take a couple of weeks for Apple to approve an Enterprise account so it’s a good idea to open one at the start of the development if you’ve decided that you need it. It’s a fairly simple sign-up process, but you will need a DUNS number.
Distributing test builds for Android
If you are also building for Android, we recommend hosting the test APK file on Dropbox with an auto-download link for users to tap on from their phones to install and test. Alternatively, you could use the Google Play Private Channel to distribute Android apps internally, similar to the service an Apple Enterprise account offers for iOS apps.
If you’re building for web, there’ll be two web servers for your development, one for staging and one for production. The staging server is where new implementations are pushed so you can view and test them, while the production server is reserved for finished code that has been tested and approved.
When your development is complete, your agency will hand over all of the assets used in your development. If there is an outstanding balance due on the development, you will be asked to clear it prior to releasing the codebases and uploading to the app stores, or conducting a wider beta test via an Enterprise account.
If it is an iOS app intended for release in the Apple Marketplace, Apple can take a couple of weeks to approve your app. If for any reason it is rejected by Apple, your development team will work with Apple to resolve any concerns before re-uploading.
If it is an Android App, the approval process is more of a formality. Your agency can upload your app to your Google Play account where it will become available for download, normally within hours.
Block-of-time support contracts purchased in advance are a good way to handle ongoing maintenance so that if something crops up after release that requires an immediate response, you can get it without delay and roll the unused hours over from month to month.
To wrap things up, with a good codebase built for scale, well-documented and beta-tested, your product will have the best chance of quickly gaining traction in the market.