You have a burning idea in your head and you can’t wait every morning to roll out of bed to work on it. But you live in a jungle with hungry developers beadily eyeing your wallet. How do you navigate the development jungle and hold onto your shirt (and your wallet)?

We put together some insider tips for getting software off the drawing board and into the market without breaking the bank or wasting your time.

What is a good software development process?

A good software development process starts with choosing a couple of good development teams to talk to. It’s best if they are referred to you by someone who previously worked with them and who knows what they’re like to work with.

You could ask your professional circles for a referral, or run a Google search. Ideally you want to work with an in-house development team as it’s much easier to maintain consistent quality. Freelancers tend to have multiple jobs on the go and will swap in and out of projects as time allows, leaving you in the lurch occasionally for updates, changes or fixes.

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:

✦ What is the purpose of your app?

✦ What problems will it solve?

✦ Who are your target users?

✦ Who are current competitors?

✦ What makes your idea better?

✦ What features would you like to include?

They’ll also want to know your budget, while you’ll want to know when the app will be delivered and how much it will cost.

Minimum Viable Product (MVP)

Initially all you’ll 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 from customers which will appeal to investors. If it proves viable in the market you can scale it.

Sometimes the ‘M’ in MVP is used to imply Maximum instead of Minimum which is grand if you have the budget to afford to build maximum functionality into the first version of your product. Absent the budget, realistically your dev team will be building in the minimum amount of functionality required to prove viability.

But 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.

Software usually gets built in a series of incremental steps, or iterations. While it may be tempting to include lots of features from the starting gate, it makes sense to keep your MVP as lean as possible in order to get to market as quickly as possible, and keep costs to a minimum.

Blueprinting

Until detailed product specs are clear, the cost for building your product is at best a ballpark number. Since ballpark numbers are really just guesses, they can’t be relied on.

A good way to reliably discover how much your product will cost to build is to initially only commission the product specs part of the development.

Product specs involve:

✦ Creating the User Experience (UX) through graphical wireframes.

✦ Creating technical documents (the API, Data Layer and Architecture Maps).

Specs 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.

You don’t want to tie yourself into a long-term commitment yet. First, see how the agency performs on the blueprints. If they do a good job with them, it is a solid indication that they will also do a good job on your app.

With blueprints in hand you’ll 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.

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 the ways you want them to interact with your app.

When trying to imagine the experience your users might enjoy, it helps to put yourself in their shoes and see things from their perspective.

Dev studios in general employ a few methods to arrive at an understanding of your intended users and the experience they’ll enjoy:

a). 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 thought to be representative of your target market.

b). 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 dev team 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>.”

c). 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 creating and hosting the User Flow. You can download and install the User Flow onto your devices 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’s 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 out the best in 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.

What’s the difference between the frontend and backend?

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.

Creating Technical Documents

Once the UX has been crafted, the next step in the blueprinting process is to create the technical documents - the API and data schema, and the architecture maps - required to understand how your app will be built.

a). API Doc

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.

b). Data Layer

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.

c). Arc Maps

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’ll be working mostly with a Project Manager (PM) who will serve as your first point of contact, keeping you informed of progress via daily/weekly status reports and calls.

Your PM might ask you to open accounts with several third party services, for example AWS or Azure 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).

You’ll also need a repository, called a repo, on Github or Bitbucket, to host the codebase and control each version of the software.

For analyzing tasks, hosting User Stories, tracking QA (Quality Assurance) and managing sprints, we recommend Jira.

Slack is a very easy and efficient way to manage communications; at a minimum there’ll be a technical channel on Slack 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.

While the devs writing the code probably won’t have time to shoot the breeze with you, you should have easy access to their comms, including visibility into the QA testing process. 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.

Backend First

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’ll 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, or iterations. You could expect one test build per week, called sprints, depending on the Agile framework used. Your product comes together in step-by-step builds.

Scrum Framework

If you make changes to the Scope of Work during the development, you’ll 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 is intended to 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 before deployment, 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.

Along with each test build, you can expect your PM to provide 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 to distribute test builds which will 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 on 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.

Distributing web builds

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 before going live, while the production server is reserved for finished code that has been tested and approved for go live.

Code Handover

When your development is complete, your PM will hand over all of the assets and passwords used in your development. If there is an outstanding balance due, 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 dev 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 PM can upload your app to your Google Play account where it will become available for download, normally within hours.

Maintenance

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, but the fun is just beginning. Many challenges await - from scaling to ongoing financing.

But asking an entrepreneur if the risks they take are worth taking is like asking basketball star Michael Jordan if it's worth risking three-pointers from so far out.

The entrepreneur can't imagine doing anything else. They’re running their own show, and enjoying it.

And that’s why we enjoy working with entrepreneurs.

The Entrepreneur’s Guide to Developing Apps