The question is very unclear, like ‘What is it worth to buy a house?’ or ‘What’s the price of a company? Let’s make the question clear so that we have understanding there.
To start with, let me describe the process of business mobile app development as it should be ideally. Suppose that there is a client that is you, you’ve got an idea and you need to find app developers for it. Or, you are our old and reliable customer, and, as an affiliate, you’ve brought a friend (who’s got an idea, too ? ) …
And now let me draw your attention to something REALLY IMPORTANT:
– We need to find a common language to get each other right. It is more important than the team, more important than anything else.
– We want to and must understand what your intentions are and why.
Here’s a simple example: you need a mobile chat application. What could be vaguer? But let us clarify that a little bit.
1) You need an enterprise chat app (you’re concerned about secure conversations between co-workers);
2) You need one for your multi-million-user super idea. That’s going to be another application that will take up a lot more resources;
3) You simply need your own chat app to show your friend (let’s call him Stephen) that you’ve got one, or the app is merely a part of your budget and that is why you need it. In such case your expenses will be far less than in the first case, even.
Finally, we have understood (or it seems we have) what exactly you need. To make it happen, you’ve talked to a manager and a BA or a few of them, if the problem is complex and specific enough.
Now it seems about time to launch the process, but, as usual, we need a plan. It will be better if it’s simple and clear, but the important thing is that it’s EQUALLY clear for both you and us.
We neither want to do same things over and over again nor change what already exists, if you can see right away that something might change and so it should be done in the end. What I’m driving at is, we need an optimal plan. So, we engage a manager, an analyst, some architects and, possibly, help from some field expert. Again, it’s a very non-trivial and complex project we’re dealing with and we are doing things as properly as possible.
Sad to say, we’ve got no fortunetellers on the staff. So, our accurate plan can only cover the near future. We will only take a small part of what we are planning to do. We split our work into short iterations; the list of what MUST be done is made for NO MORE than the nearest 2 or 3 weeks.
Why’s that?
All things change, and time and again, even in such a short period, you will think of something so absolutely necessary that you will want it badly to be included in the current iteration. But we turn down the thumb on the idea, we really do, because everything happens for a reason; some new things might affect some old ones and it will collapse. That will, at least, take up time and your mobile app release will be rescheduled. Your idea might cause many other terrible things.
Well then, first iteration plan is ready. Off we go. There goes a manager, an analyst, designers; they are then joined by mobile application developers and coders; test engineers appear on the scene by the end of the iteration. That’s a big team, a huge one, I would even say.
With two, maybe three people employed before the first iteration, there are many more as the programming starts, further on – even more. Here’s an important aspect: if we engage 150 people all at once, we’re sure to either ruin the project or slow it down. Everything works by its own laws… Certainly, you can always speed up the process, but only up to a point… Let’s say, there are 20 people working on the project.
After that, iterations follow one another. You can have intermediate iterations meant entirely for planning; it’s much worse when planning is done during the current iteration. By engaging another 20 people we will not speed the project up, as it might appear at first sight, but, on the contrary, will essentially slow it down (new team members need to find their way around what the old ones are doing) and after some time (depending on how specific and complex the project is) we’ll speed it up, but it will hardly be twofold, even though 40 people is twice as many as 20…
There are no distinct rules; we do things in a way that’s convenient for you and, which is no less important, for us.
Towards the end of the project the number of ‘artists’ (designers, stylists, and graphic designers) goes down, while the number of programmers and testers goes up.
By the end there is just a support team (the project is not for your friend Stephen, is it? The objective you pursue is more important). The project is living its life, it’s expanding and even growing. A support team usually includes a few mobile apps developers and testers, a manager, partially designers, coders, maybe architects and analysts. Their ratio in the team may vary.
The manager can be replaced even by an analyst or a team lead, if that’s more comfortable for you; all in all, what really matters is understanding and RESULT.
There is no typical all-purpose team; the most important thing is that the work is done and everybody’s satisfied.
What is it all about? It cannot cost a few thousand dollars to develop a significant application for Android or iPhone or a website. Customers who believe a Facebook or LinkedIn clone or ‘something very similar’ can cost $50,000, amaze me.
We can do ‘something very similar’, we can do it for $50,000, but what you’ll get as a result is a ‘project for your friend Stephen’. Impossible is nothing, you know. When somebody wants to do something, they do it, and those who don’t want to, look for reasons why they can’t.
We’ll be happy to help. There are lots of things we can do (I’m not saying we can do anything), but we’ll only work on it if it’s interesting both for you and for us.
Thanks for reading and bye for now.
