Every developer one way or another estimates their tasks. Over time and with experience, you often have to estimate not only your own tasks, but projects as a whole. From ordinary task estimation, the final project budget is already planned. Clients reasonably want to estimate the cost of your company's services and this is the only way to somehow satisfy their desire.
I'm an Android developer who by fate's will started to understand iOS due to the need to manage and direct an iOS team. I picked up experience both there and here, became a one-man orchestra with management functions. One of my responsibilities was precisely estimation, forecasting deadlines and the ability to manage several projects on different platforms simultaneously. In a small company you're always much closer to the business and all these questions one way or another pass through you too. All this gave good experience in estimating native mobile apps, even in such a small company there's simply an indecent number of factors that are worth thinking about when estimating and compiling a quote for a client.
What to consider?
- How much is currently known about requirements (verbally / requirements document / mockups);
- On the quality of these requirements;
- On the current state of those components with which you need to integrate the application, for example backend or some client library. Are they ready, or will they be developed in parallel?
- Who develops the backend, database and raises all this infrastructure? How easy will it be to interact with them?
- How competent is the team in this business;
- On technical complexity;
- How competent is the team in such technical solutions;
- How many people we want to allocate to the project;
- How busy these people will be at the moment when they need to work on the project;
- What are the risks for each participating worker? Maybe they're burned out, maybe they want to quit, or maybe someone is on the contrary on an incredible rise;
- How important it is for us to connect with the client for further cooperation;
- How much our life as a company in general depends on this project;
- How adequate the client is in general and how much you trust each other;
- The cost of maintaining one person in the company, office costs, equipment, salaries of employees necessary for the company's functioning but not clearly participating in development; ...and everything in this vein.
General principles
- Draw conclusions from your previous experience, learn from mistakes;
- The less is clear and implemented at the time of estimation - the more risks to lay in. Naturally most factors are almost impossible to calculate, so any estimation will have some part in the form of risks;
- If the client doesn't want to pay for risks in such volume, then move with them step by step. This way it will be clearer for them, each of the steps is separately estimated and paid for, agree on mockups, API specification for the application, develop MVP first, then complicate with new requirements.
- The more important and promising the client - the lower the cost, in the long term such connections pay off through support and constant flow of projects, maybe we want to undercut prices now to invest in the future;
- If the client doesn't pay for estimation separately, then the time spent on estimation is smeared evenly across all items;
- One man team is always easier to calculate, interaction between people and management requires adding a certain percentage on top;
- There are people of different competence levels - we average the estimation for them.
- Break down requirements into sub-items so much that each estimation can be calculated with some assumption. For example: separately pushes, authorization through social networks, and all such typical tasks that are roughly clear how to do - write separately, the easiest to calculate the estimation for them. All sorts of business-specific requirements are often the hardest to calculate, and clients often insert their wishes on the go. With certain risks we include them too, sum up - we get the final estimation.
- Give an estimation with some spread;
- Convey this estimation in human language, be able to explain why drawing such a component is 1 day, but this other similar one is 101 days.
- How to calculate the final estimation everyone has their own approaches due to the fact that people tend to underestimate it. Someone just multiplies by 3, someone by pi + two weeks. I'm used to calculating min and max, and giving the client avg..max for approval.
How much does it cost?
As for how much it can generally cost - any amount. Roughly speaking, you need to multiply this estimation by the average salary of involved persons and their number + some percentage on top for company development + overhead costs for office functioning, for example. All this can vary greatly. From country and city, from office, from perks in the company, and so on.
Android vs iOS
In my experience, Android and iOS estimation if averaged across features - doesn't differ almost at all. In Android there are peculiarities, in iOS there are peculiarities, for some tasks the estimation will differ significantly, but if you smear across the whole project, then approximately the same comes out. It depends, again, on the availability of needed personnel and on requirements.
If it's first made for Android, and then planned to be made for iOS, this is already a guarantee that at least some mockups were there, the backend is implemented, requirements are settled, the result of work is accepted, and the Android team did a bunch of work on coming up with architecture, has some ready models, described database, for example. If they can transfer knowledge to the iOS team, this significantly cuts costs for the second. The same in the reverse direction.
Cross-platform in my reasoning, most likely, I don't cover very well, but there too everything depends on the application and how much work with the platform happens, if you're making an application for viewing news, for example, and besides text with pictures from the internet you don't need anything else, then cross-platform is good, will transfer almost entirely. But if you need some full-fledged camera, some hardware sensors, then it's hardly not simpler to write two different native applications.