Table of Contents
– “It depends” is not the answer
– The real answer is not simple
– Why do we need a software brief?
– Details matter
- Here’s what we need to know to estimate and plan your software development
– The aim of the project
– The users and the problem your software is solving
– Current state, own resources, and needs
– To get honest answers, ask honest questions
- App description – main functions and features
– User story
– Examples of user stories
– Components and scope of works
– The timeframe and deadlines
– The money question
– Choosing the developer
– How our clients choose
– Updating your brief
If you’re thinking about having your first (or second, or 31st) mobile app development, you will obviously need to know how much it’s going to cost. Unfortunately, “it depends” is the most common and at the same time the stupidest answer you will receive when trying to talk to developers about costs and estimates.
Common – because mobile app development actually does depend on so many different factors, that the word itself is just the easiest way to answer shortly. Stupid, because it leaves you with no real information at all.
“It depends” is not the answer
And once they say it, you ask “Depends on what?”. What follows is usually a mix of sales techniques and trying to find out what your requirements are.
The process of proper estimation and preparing for it is crucial for your project’s success. It’s important for you as much as for the developer to do it right.
The real answer is not simple
I will try to make this process a little more substantial, and less of a sales pitch. Yes, we still want your business, but what we want most – is for you to be able to make an informed decision, whether you pick itCraft or another developer to work with.
The below article is attempting to explain the “mobile application brief” as thoroughly and reader-friendly as possible, but if you have any comments or need more info, please let me know. Especially if anything is not clear enough. I want this to be a help for anyone considering software development.
Why do we need a software brief?
It’s simple, like our simple app 🙂 The more we know about your idea, the better. Not because we want to steal it (no time to follow up on this stuff- we’re way too busy to do things for free) but because we want to help you succeed. To the best of our knowledge and ability. The knowledge bit, at least the major part of it, will come from you.
Actually, they are what matters most. If there’s anything that you should put the most effort into when preparing the brief, it’s the details. When we assess your requirements, meticulously gathered information will prove invaluable.
So without further ado, let’s talk about your next mobile app brief. It’s a bit of a read, but for one – I will try to make it as painless and brief 🙂 as I can. Secondly, if you manage to go through the whole thing I can guarantee you will have what’s needed to start looking for the right developer.
Here’s what we need to know to estimate and plan your software development
The aim of the project
Why are you thinking of developing a mobile app? Understanding your idea and the reasoning behind it will help us choose the right technologies, adjust to your short- and/or long-term strategy and advise on the most efficient approach.
The users and the problem your software is solving
To provide adequate service software developers need to know the value you are giving to your users. Whether they are customers, the general public, or your own employees, the introduction of a new system aims at solving a problem, satisfying a need or bringing benefit to the end user. Understanding your value proposition and target audience of your app will help us design the right solution and use the technologies appropriate to your needs.
Current state, own resources, and needs
Define the current state of your project. Is it just an idea needing analysis and evaluation? Or maybe you are well past that and your project is already in the design phase? Do you have your own team already working on the project?
Once we know the answers to these, we can use the information to better assess the range of services you will require. Basically, we would like to know:
- If you have a team of people responsible for the project? What roles are covered? Are you providing a dedicated Product Owner, or planning on overseeing the development yourself?
Are there specific guidelines for your proposed system regarding the vendor’s capacity, technologies, standards or processes the service provider (developer) should follow?
Having the above info, your future vendor will be able to quickly tell if they possess the required qualities, assets and resources to work on your project.
To get honest answers, ask honest questions
When providing the above information, or any other details in a brief, I recommend not to withhold any information/requirements you may have. If you miss an important detail, whether on purpose or accidentally, it can have significant consequences. Simply because something that may seem small and insignificant to you, may actually turn out to be a serious and complex issue for the developer. This kind of misunderstanding, more often than not, leads to complications and conflict. Better to avoid that from the start.
App description – main functions and features
In this crucial part of the brief, you will be describing tasks and processes the end user will fulfill using your app. In other words – what is your app supposed to do? First, you need to define the types of users your app will have – admin, client, provider (in the Uber system it’s the admin, passenger, driver). Then for each of them, you need to outline the functionalities they will be able to access.
The standard way of describing an app’s feature is with a User Story. Usually in the following form: As a < type of user >, I want < some goal > so that < some reason >, the Stories tell us who (user), how (the goal) and why (reason) will utilize a particular function. This information is the base for both the UX designers and developers to plan and estimate the time and technologies required to develop a feature.
Examples of user stories
As a <general user> I want to <log in to the app> so that <I can use its main features>
As an <system admin> I want to <manage user accounts> so that <I can modify, adjust, delete and create new user accounts>
Components and scope of works
Every app/system can be broken down into 2 parts:
1. Components that need to be developed,
2. Work to be done.
The main components of a system/application are as follows:
- Android mobile app – app dedicated for Android devices only,
- iOS mobile app – iPhone app,
- Backend application – the server solution containing a database and/or a Programming Interface (API),
- Web admin panel – admin app for system administrators,
- A web app for end users – a browser-based application,
- Integration with 3rd party services – external systems, APIs,
- A landing page – website with information about the project.
Depending on the complexity and your preference, your project will require all or only some of these components. Most up-to-date developers suggest starting with an MVP of your system.
Additionally, the project can be defined by outlining the scope of required work and the effecting deliverables.
- UX/UI design – preparing the backlog of requirements, hi-fi and lo-fi mockups, prototype,
- App implementation (development of Android, iOS, web, backend, API etc…),
- QA – testing process including acceptance, security, efficiency, performance, automatic, unit, alfa and beta testing (and user tests for good measure),
- Preparing project documentation (specification, technical, functional, test scenarios, API, integration),
- Transfer of Intellectual Property (IP) – source code or a licensing solution,
- Google Play and App Store implementation,
- Project management – client provided when hiring the development team only or supplied by the developer when covering the project as a whole,
- After service – maintenance and further development once the project is completed.
The timeframe and deadlines
The time is always of the essence. If you need your app launched by a certain date, then your developer must know that as early as possible. Knowing how much time we have will let us adjust the size of the team to your requirements, but also let you know if the timeframe is feasible. There’s only so much a developer can do, and some crazies out there still claim you can actually get 9 ladies to deliver a baby 1 month from conception. Down here on earth we still work on “doing best we can” basis.
If you’re not on a tight schedule, this will also prove valuable information. Being able to take our time will bring down the price of your project.
The money question
The purpose of your investment in a new IT solution (or an existing one) is to reach the goal(s) outlined in your application’s brief. Investment can’t succeed without a budget.
As software development is a largely creative process with many variables in terms of solutions, technologies, time, etc.. knowing the budget will allow the developers to adjust their proposition to your budgetary requirements.
Once they know how much you are planning to invest in the project, mobile app developers can offer the most suitable solution. Without this knowledge, they will be forced to estimate “blind” which usually means offering the cheapest and lowest quality options in order to be competitive with other providers. The resulting estimates are usually largely inadequate and inaccurate. Worst case scenario, you will end up actually paying for a botched service or receive a piece of software that will require months of bug fixing and cleaning up by a different provider. Most app development companies usually refuse this type of assignment, as experience has taught us that fixing someone else’s mistakes is both painful and expensive. Besides, our technical analysts usually tell us that “it will be cheaper to make a new one than fix this bag of …”.
Clearly stating your budgetary requirements is the best way to finding the right app development company. The best way to disclose it is by telling us “We are thinking to spend X amount on this project, and we definitely don’t want to go over the Y amount”. This will let us propose a solution to satisfy the X requirement and an expanded one that will come closer to the Y sum.
Choosing the developer
When looking for a good app developer, you should have set criteria that will determine your choice. This will give you a clear picture of the company you will be most likely to partner with. Stating this openly and honestly in the initial stages of your search will also save you the time on negotiating with vendors that cannot meet your needs.
How our clients choose
Below you will find three most common vendor characteristics our clients look at when making their decision. All these are valid and equally important, although we can tell from experience that no one vendor is capable of providing services that will satisfy all of them. Take this as a tip – If a developer tells you they can “do it all”, they are most likely not worth your trust, or should at least be thoroughly checked.
- The price – if you’re a startup or have a very limited budget (the two go together quite often) you will obviously be looking for the cheapest possible option. Established businesses usually look for long-term partnerships and the price is a secondary issue. Mutual trust, experience, and support play a more significant part,
- Deadlines – some solutions require adhering to strict timeframes. If you require a development team ASAP then developers offering service at short notice are the way to go,
- Quality – vendors offering high quality are currently most sought for in the market. Whether it’s the perfect UX/UI design to please the users, clean code, reliability, efficiency or all these put together – finding a mobile developer by this measure seems to be the most popular, and yielding best results in terms of ROI.
Which of the above will drive your decision depends on your business’ needs, capabilities and requirements. It’s also a good idea to inform the developers about your priorities so they can better adjust their offer and estimate.
Updating your brief
When contacting various developers you will find that they answer with requests for additional details, clarifications, etc… It is good to include answers to these in your brief, so the next developer you ask has an even clearer and more detailed picture of your idea. All the more important is to update any changes to your requirements that you come up with while looking for a suitable vendor.
Here you can find itCraft’s brief!
Learn more about developing your own app – contact us!