13

I know that there are other similar topics but I want to ask differently and I hope you answer differently too. I developed some apps and I have some experience. I created some apps as freelancer for customers too and I have calculated my hour rate for now (it's okay for now, when I learn more and more things it would grown).

My main problem is that I can't estimate right cost for app. So I want to ask if there is some general solution for estimating price. I know that easiest way is to multiply hours for developing app by my hour rate but how can I exactly find out exact hours need to spend for app? I have all pages/activities/views/... and functions needed for app written in contract but how can I figure out that this application with 4pages took 80hours and this app with 3pages took 130hours (because second is complicated). Should I use some program for this (like Excel, ...)? Is there a tutorial to estimate price? Or a book?

I can imagine that I would use Excel and I have in one column list of functions and other things and in second column list of hours needed to solve/create that things in first column and my price would be sum of that hours*my hour rate. But I am not sure if it is good solution. Ofcourse it could work for some project. But I think there could be much better solution (more accurately estimate and other things). And in this solution I can estimate time for functions I know how much it take to develop but what if it would be new thing? Right now I should estimate price for OCR iOS app. How can I estimate OCR function which I don't do yet?

For every tip/answer/solution and other things I would be very glad :) I want to create some complex method from start to finish which gives me at start some early price. After full app description to have maximize precise price. And after work is done maybe some new experiences in next estimates.

0

6 Answers 6

10

There is no formula for magically determining the number of hours a task will take based on complexity. Rather than agreeing to a fixed price, you might want to break your project into milestones and give an estimate of the number of hours between milestones, and charge hourly.

This is most important especially when you consider the fact that as you finish your milestones, your client is probably going to be asking for changes. If you do fixed price, you can't recover for such changes. If ultimately the client is in charge of requirements then you want to avoid the client having the ability to make the work take much longer without you having any ability to receive reasonable compensation for your work.

1
  • 1
    It's good idea with milestones but I must client argue into that. Most of the clients want to have price set in contract. It isn't problem to charge changes which aren't in contract (I have pay-rate in contract for changes) but almost all clients want to have some basic price for their app right now and later it could be more with new functions and changes but for description in contract it must be solid. Commented Apr 16, 2014 at 9:06
8

I'm freelancing with mobile apps now. Estimating prices has been far more difficult than the coding itself!

Time estimation

It is possible to estimate time required. Break it into a to do list. Nothing on your list should take more than 4 hours to build. Break it down further. Something like Upload data (?? hours) can be broken down into Prototype sending binary data (1 hour) + Upload data from activity 1 (2 hours) + Process upload confirmation (2 hours) + Display upload success in activity 2 and so on. The smaller the tasks, the more accurate your estimates. It might take time to plan all this, but it will speed up your productivity and your client's confidence in the long run.

If you haven't done something before, dedicate about half an hour to researching whether it exists and how hard it would be. Something like QR codes are very easy because there are plenty of libraries out there, yet PDF is near impossible. But it takes research to realize this.

Do your best estimate. Break things down if it's tough - time needed to prototype and test are important. Then multiply your target by 3. So if you think you can do something in 1 week, set a target of 3 weeks to cater for the unexpected, including redoing things from scratch if it fails.

The best estimates are the ones you have experience with. I track down every task I do and use them for estimates in future tasks. My favorite tool for this is Sublime Text with the PlainTasks plugin.

Clients will want things their way

Think a job will take 3 months? Your client will add a lot of time to it. In my experience:

  • Polish adds 2 weeks to a job. More for Android. This includes cleaning code and comments, if you're giving them your source code.

  • Allocate another 1-3 months to polish if you're dealing with a job where polish is vital, like clients in the field of event management and hotels. They'll complain about your corners not being rounded enough and ask why the fancy buttons they demanded look weird on large screens, even though you told them earlier that it wouldn't scale.

  • If it relies on a webservice or API, prepare for development hell. Be prepared to demand that they finish their API first before you take on the job. I've seen 2 month jobs delay to almost a year because of waiting for their API.

  • If your client is actually contracting out a job for another bigger client, be careful. Since apps are usually the front end, you'll be responsible for delays on the back end. They'll use you in order to buy time and appear like they're making progress. This week they'll want blue buttons this week and switch the color scheme to beige next week to appease their client.

  • Many clients think changing the layout of an app is like making a powerpoint presentation. I have had arguments with almost every client about this. Make it very clear that it's not trivial to change their minds.

This may not always happen, but take it into consideration. There is no such thing as a 3 day job, unless they don't want polish. You'll have to be firm on what is and isn't included as a part of your contract.

Have charges for changes outside what is agreed upon. Almost every freelancer has fallen into the trap of being nice and doing small changes for free, only to have a client eventually take advantage of that goodwill.

Apps based on special events are generally good, like those for elections or sports events. There's a 'hard deadline' after which they won't be demanding more work from you.

Check out outsourcing components

What I normally do is outsource small components out to people online. This gives a good feel of worldwide rates for the competition as well as the market prices for certain components. Outsourcing is a useful skill to have for times if you have multiple projects running in parallel.

Actually getting your price

The reality is that you shouldn't be charging based on how much work you have to do. Market rate for an employee and market rate for an app are very different things!

App development is a specialized field. iPhone has only been out a few years so there's nobody out there with 10 years experience. Larger companies can do better, but some will charge $100k for a job that takes 3 months to do. Freelancers are rare, especially those with experience. Learn who your biggest competitors are - this varies a lot within countries. The higher the education level, the lower your costs... something like Indonesia might probably have the highest rates for freelancers, because of the high mobile usage and less competitors per capita.

Many app developers can name their prices as high as they like because of the lack of competition. But be reasonable.

Think of it from the perspective of the person you're negotiating with. They need to convince their bosses as well. Don't explain how many hours you put into it. A fresh graduate in your town will do it for fast food wages. Some guy in India with a good degree and a year of experience is willing to work for $5 for 3 days. Explain how you're more reliable than that guy.

You should be charging based on how much your app is contributing to your client's finances. I've done multiple apps that digitize paperwork. These are the best because you're saving a company hundreds of thousands of dollars a year because of improved productivity, improved workflow, not having to lug as much paper around. You can charge hundreds of thousands for those. If you think that's too much money for an individual, let them negotiate it down.

I've done apps for small events like marathons. These don't pay well, but the benefit is that they can be used for every similar event. If you're looking for freelancing, that's not so great. But if you're looking at product development, building your own company, and financial independence, these can be good in the long run.

If your app is part of a company's core business model, charge more. If it's just a fancy nice thing to have on the side, charge less but go for quantity.

2
  • 1
    Thanks very much for this. Great for thought. And that idea with breaking features to todo list and items shouldn't be more then 4 hours long is approach I will try. Have you some blog or website? I would like to read more articles from you :) Commented Apr 18, 2014 at 11:52
  • No blog, sorry. Maybe I should put one in my profile should I get one :)
    – Muz
    Commented Apr 18, 2014 at 14:22
1

No one can answer this because each estimation is based on someone's experience. If you've paid me to calculate it for you, I would also make a mistake cause you and I don't code at the same speed. Get it?!

I would clearly state the client parts of the project which you are 100% sure of how long it will take. And then mark those which you are unsure. If you have split features to simple tasks, then you probably know how long it will take. And for all those unclear situations don't be afraid to say "it may take 4 to 20 work hours".

Then on some project management tool or Excel sheet (when you get the job), make a list of all tasks and then estimate all those individually as the project advances.

This all is true in case you have hourly-based project. In case of a fixed-price project, just give your best estimation if your really want the job. Yes, you will probably make a mistake and calculate less work hours, but you will gain great experience from that. We all started that way. Projects I coded for $500 when I started, I can now charge $5000 just because I am able to better calculate costs and cause I have knowledge and strong portfolio.

So, give it a try. If you carefully detected all basic features and calculated the work behind them, you're on a good path.

1

It is totally depends upon the modules,language,time period,features, How much modules are you creating on that mobile app, which language are you using to develop, what time it will take to build it, and what are the features should be available on that app. these are the things should be there while estimating a cost.

1

Estimating cost for an app is a tricky task as it has multiple factors attributing to its cost. The design, development, testing, security, updates, support these all aspects add price to it. Again you want to get it developed in-house or outsourced or freelance, it will have impact on pricing. However, in all cases, the effort or time required to develop the app will be roughly the same assuming it is being done by experienced and competent engineers.

Requirement Planning

Mature apps like Facebook, Whatsapp, Skype, Tinder etc have numerous features that you probably do not need on day one. Features that take hundreds of engineers to develop and maintain. It is important to figure out what features and actions your app will allow users to do on day one, and focus on making the best possible user experience for that set of features. Example of features you may not use on day 1 could be:

For a social app – Extensive privacy controls in a social app, For an e-commerce app – several types of coupons – discount, 2-for-1, freebie, discount on bundles, user-specific code, general code, product specific codes .. the list is endless. For a messaging app – delivery reports, export archive For all the above – building for scale too early. It is tempting to build your app for several million users on day 1 so you are ready when you hit that scale. However, a lot of that investment will sit idle for a while and, in any case, the market will compel you to make numerous changes to your product very soon. The second or third pass at the architecture is probably a better time to make the big investments in scale.

Be ruthless about cutting down the features that you need in your app until you can’t reduce anymore.

To this, you will need to add back a few items.

Analytics – to track how users are using the app Marketing Automation – to keep engaging users with relevant push notifications Referral System – to maximise referrals of the app to other users and reward users for doing so Once you have done this, you have a working list of what you need to get built. This list is bound to evolve even as you develop your app, and unfortunately, in most cases it will expand! We have written a detailed article explaining the same. You may check here on how to estimate the cost of a mobile app development.

0

I see two cases:

  • the project is big and risky: only propose a charged preliminary study, which will allow you to validate your technical choices and get better insight on the costs, or phase the project;

  • the project is small or not risky: only you know how long you will take for the requested tasks, using the requested technology. You will rely on previous projects and on intuition. If the kind of project is recurring, you can establish estimates based on the volume of work.

As regards myself, I always start an offer by a Work Breakdown Structure and assign man-hours to every item. During the course of the project, I confront those figures to reality. In general many of the estimates are wrong, but fortunately, the errors can compensate.

https://en.wikipedia.org/wiki/Work_breakdown_structure

Not the answer you're looking for? Browse other questions tagged or ask your own question.