Loading...
Answers
MenuIOS app - How to estimate and charge for new app functions
Answers
Hi Valentin,
Have you considered splitting the research phase and the development phase? You can quote a fixed amount for the research phase (I'm sure you can estimate this in weeks and take the hit if you go over). You can say to the client that you will quote the development once the research phase is over.
Plus, they can take the research phase output to other providers if you do not or cannot do the work or the quote is too much.
Call me to discuss further if it helps.
Kind regards
Stuart
Hi there!
Approaching the R&D for unknown tasks will always have that element of unknown to it, however, the approach I take, that works best for me is:
1. Have a developer estimate the number of hours they think it will take to implement that piece of functionality (then you can convert these hours into a rate)
2. Add a contingency budget into the fixed price, so that it is something you call fall into should the unknown work piece go over its estimated hours (a typical contingency budget is around 10% of the overall project budget)
3. Be clear on your communications with the client, that could be as simple as saying "We've not come across a request for this functionality before, as such, we aren't too clear on the amount of work thats fully involved"
4. The more unknowns/uncertainty around the project, the higher the contingency budget
I'm Shay by the way! I have run some major projects across the software industry, working with Team Visionary, I have had the privilege to lead major successful projects for Google, Atlassian and OnePlus.
I hope this helps you, if you do require further assistance, I would love to jump into a call and provide you with support.
Hello Valentin,
I appreciate the detailed context you've provided regarding your project. Based on my extensive experience as a Senior Solutions Consultant, particularly in API architecture and development, here's a structured approach to help you estimate and charge for new app functions effectively.
Step-by-Step Approach to Estimating and Charging for New App Functions:
1. Requirement Analysis
Gather Detailed Requirements: Before you can estimate, it's crucial to have a detailed understanding of the new features and functions required. Arrange a meeting with the client to gather as much information as possible about their needs and expectations.
Categorize Features: Break down the new functions into categories such as front-end, back-end, API integration, etc. This will help in organizing the work and assigning accurate time estimates.
2. Research & Development for Unknown Tasks
Conduct R&D Sessions: For special functions that are new or unknown, allocate specific R&D sessions. This involves researching potential solutions, prototyping, and validating the approach.
Time Boxing: Set a fixed amount of time for these R&D activities to avoid spending excessive time on uncertain tasks. Document the findings to provide transparency to the client.
3. Estimate Effort and Time
Use Historical Data: If you have previously completed similar tasks, use that data to inform your estimates. Look at how long similar features have taken and adjust for complexity.
4. Break Down Tasks
Task Breakdown: Divide each feature into smaller tasks. For example, a new feature might include designing, coding, testing, and deployment. Estimate the time required for each sub-task.
Use Estimation Techniques: Techniques like Planning Poker, T-shirt sizing, or the PERT method can help in getting a more accurate estimate. Involve your development team in the estimation process for better accuracy.
5. Risk Assessment
Identify Risks: Consider potential risks that might impact the development time, such as technical challenges, dependency on third-party services, or scope changes.
Add Buffer Time: Include a buffer in your estimates to account for unforeseen issues. Typically, adding a 10-20% buffer is standard practice.
6. Fixed Price vs. Time & Material
Fixed Price Model: This model is suitable when the project scope is well-defined. However, it requires accurate estimation and clear requirements. Any scope changes should be handled through change requests with additional charges.
Time & Material Model: This model offers flexibility for projects with uncertain or evolving scopes. It allows billing based on the actual time and resources spent.
7. Communication with Client
Transparent Communication: Keep the client informed about the estimation process and any assumptions made. Provide a detailed breakdown of the estimated time and cost.
Educate the Client: Explain the complexities involved and why certain tasks may take longer. This helps in setting realistic expectations and justifying the cost.
8. Documentation and Tools
Use Estimation Tools: Tools like JIRA, Trello, or Asana can help in documenting tasks, tracking time, and managing the project.
Detailed Proposal: Prepare a comprehensive proposal that outlines the scope, estimated time, cost, payment terms, and any assumptions or exclusions.
Example Breakdown:
Let's say the client wants to add a new feature for real-time data synchronization.
Requirement Analysis: Understand the data flow, frequency of synchronization, and security requirements.
Research & Development: Prototype the synchronization mechanism.
Task Breakdown:
Design: 8 hours
Development: 20 hours
Testing: 12 hours
Deployment: 4 hours
Risk Assessment: Identify potential latency issues or data conflicts.
Buffer Time: Add 10% buffer, resulting in 4.4 hours.
Total Estimate: 48.4 hours. If you charge $100/hour, the fixed price would be approximately $4840.
Conclusion
By following this structured approach, you can provide accurate estimates and justify your charges for new app functions. This method not only helps in setting realistic client expectations but also ensures that you cover all aspects of the development process.
If you need further assistance, feel free to schedule a call. I'm here to help you navigate these complexities and ensure the success of your project.
Best regards,
James
Related Questions
-
What is the generally agreed upon "good" DAU/MAU for mobile apps?
You are right that the range is wide. You need to figure what are good values to have for your category. Also, you can focus on the trend (is your DAU/MAU increasing vs decreasing after you make changes) even if benchmarking is tough. Unless your app is adding a huge number of users every day (which can skew DAU/MAU), you can trust the ratio as a good indication of how engaged your users are. For games, DAU/MAU of ~20-30% is considered to be pretty good. For social apps, like a messenger app, a successful one would have a DAU/MAU closer to 50%. In general most apps struggle to get to DAU/MAU of 20% or more. Make sure you have the right definition of who is an active user for your app, and get a good sense of what % of users are actually using your app every day. Happy to discuss what is a good benchmark for your specific app depending on what it does.SG
-
Where can I find programmers willing to join a growing mobile start up for equity only?
You won't find anyone worth adding to your team willing to work for equity only, no matter how compelling your product and business is. The realities of the talent market for mobile developers anywhere is such that a developer would be foolish to work only for equity unless they are a cofounder and have double digit equity. Happy to talk about hiring and alternatives to full-time hires.TW
-
What tools to use for mobile Prototyping ?
My 2 favourite are: - www.uxpin.com - www.flinto.com Flinto is by far my favorite for mobile. I also us www.balsamiq.com for anything wireframe. Sometimes I jump into Sketch http://www.bohemiancoding.com/sketch/ for more high fidelity mockups using their Mirror feature http://www.bohemiancoding.com/sketch/mirror/ Hope that helps. P.S. There's a tonne of Mobile UX experts on Clarity, many $1/min - call them, you'll learn so much. my2cents.DM
-
Whats are some ways to beta test an iOS app?
Apple will allow a developer to register 100 UDID devices per 12 month cycle to test via TestFlight or HockeyApp. Having started with TestFlight, I would really encourage you NOT to use it, and go directly to HockeyApp. HockeyApp is a much better product. There is also enterprise distribution which allows you far more UDID's but whether you qualify for enterprise distribution is difficult to say. As part of your testing, I'd encourage to explicitly ask your testers to only register one device. One of the things we experienced was some testers registering 3 devices but only used one, essentially wasting those UDID's where we could have given to other testers. Who you invite to be a tester should be selective as well. I think you should have no more than 10 non-user users. These people should be people who have either built successful mobile apps or who are just such huge consumers of similar mobile apps to what you're building, that they can give you great product feedback even though they aren't your user. Specifically, they can help point out non obvious UI problems and better ways to implement particular features. The rest of your users should be highly qualified as actually wanting what you're building. If they can't articulate why they should be the first to use what you're building, they are likely the wrong tester. The more you can do to make them "beg" to be a tester, the higher the sign that the feedback you're getting from them can be considered "high-signal." In a limited beta test, you're really looking to understand the biggest UX pain-points. For example, are people not registering and providing you the additional permissions you are requiring? Are they not completing an action that could trigger virality? How far are they getting in their first user session? How much time are they spending per user session? Obviously, you'll be doing your fair share of bug squashing, but the core of it is around improving the core flows to minimize friction as much as possible. Lastly, keep in mind that even with highly motivated users, their attention spans and patience for early builds is limited, so make sure that each of your builds really make significant improvements. Happy to talk through any of this and more about mobile app testing.TW
-
iOS App: Beta vs Launch Quietly?
I would suggest launching in a foreign app store only (ex: Canada). That will allow you to get more organic users to continue iterating without a big push. I got this idea from Matt Brezina (Founder of Sincerely, previously Xobni) https://clarity.fm/brezina - he's the man when it comes to testing & iterating mobile apps.DM
the startups.com platform
Copyright © 2025 Startups.com. All rights reserved.