When a customer hires a software development company, they usually sign a billing contract. The pricing model is not always the same from one software development company to another which can make it difficult to compare quotes and decide which technology partner to go with. Some models include fixed-price, time & materials, and milestones. The essence of writing this article is to explain our pricing strategy and make it clear how we come about prices for our services.
Delivering Quality
Here at Azul Arc, we’re known for delivering top quality service and products. Price is a reflection of everything we do in our business, because we live in a world of value. It’s important to let buyers know the service they are getting is worth their time and investment. No matter what your product is, pricing decisions remain to be one of the determining key factors when selecting a technology partner.
At Azul Arc, we strive to use a pricing method that creates a level of understanding and transparency for one of the more complex aspects of your design and development engagement. Our goal is to create a mutually viable and fair approach to how we price and manage your projects. We call this our FlexPrice model.
Pricing Methodology
This section of the article explains how we go about pricing. Before you get a quote, here are some of the important factors we consider.
- Our Experience and Expertise – past projects provide us a strong frame of reference, particularly for more standard components and functions.
- Proprietary Pricing Product Database – We have created a proprietary pricing database that outlines benchmark pricing for functions and features which is used as a reference when pricing your project.
- Module Based Estimation Profile – We use a spreadsheet where we breakdown your backlog/requirements into the modules or objects that make up your application. These components roll up to the initial price range estimates we share with you.
- Allocations – For certain functions like test/fix iterations and product management, we use industry-standard allocations (percentages) for your project.
- For Product Management, this varies between 10% and 20% based on the complexity, client requirements and the size of the project.
- For testing, it is typically 20% of the development time and includes unit testing as well as a basic allocation for system testing. It is likely at the time of system testing that there will be changes to the estimates required to complete testing (please plan for that).
- Reserve – This is an explicit addition (or buffer) that we define upfront for you to budget with the intent of covering initial additions and changes that are the inevitable part of development. If it is not used, it will not be billed.
- Discovery – This is our primary and preferred approach that uses some of the above methods in a more thoughtful and detailed manner. The next point covers this process in more detail.
Discovery Driven Pricing
It is generally difficult to know enough about your project upfront to provide an accurate estimate. Even when the requirements seem fairly defined, there are many unknowns that need to be reviewed and uncovered.
How we go about it: We employ a series of thoughtfully designed workshops to quickly pull these details to the surface. We combine your business knowledge with our expertise in product design to develop the initial application architecture, product backlog and estimates. We define and break down the objects/modules of the application in order to understand the structure, relationships, and actions that need to be taken by different user types. We call this — our Discovery Phase.
The work here that occurs over a few weeks, gives our design and development team (and you), a deeper understanding of your project requirements and allows our team to provide more accurate estimates for the application.
We don’t recommend skipping this phase as it results in inaccurate timelines, potential increases in costs (which you may not have budgeted for), and rework during the more costly development phase when unknowns are uncovered.
Factors to Consider for Your Project Pricing
It is important to note that any pricing shared with you are initial estimates based on the information available at the time. These are more than likely to change as the project progresses and our collective knowledge and understanding of the details and edge cases increases.
What we do: An agile approach is much more effective here as the goal is to estimate more defined, near term tasks with clear scope, resource and time commitments. It provides for the flexibility to adjust as needed.
Ineffective pricing strategies to avoid: It is nearly impossible to look into the future and forecast accurately the time and requirements for a custom project engagement. Study after study has proven this (yet this method exists in the industry).
- Waterfall / fixed estimates have been proven to be ineffective and a failed form of pricing. Industry research highlights the total lack of getting even reasonably accurate estimates with this method.
- A quick search on the web will also highlight the fact that developers are not the best estimators and that waterfall-based fixed estimate projects have seen actual costs end up many times over what was initially presumed. Industry thought leaders like Jason Fried (of Basecamp and the book Rewired) have spoken out against these estimating/pricing methods.
For this reason, our pricing is dynamic and in keeping with the agile principles of pricing. We do everything to be fair and work in your interest. This includes managing and minimizing costs as best we can. We are here for the long haul and our goal is to cultivate long-term, trusted relationships with you. We strive to bring you the most value for your investment.
A Few Additional Project-Related Pricing Considerations
Pricing estimates typically cover ranges for design and development with an allocation for the System Testing and UAT phase (user acceptance testing). During this period, there may be additional test and fix cycles and it is difficult to forecast the time needed for this phase. Please know that there may be a need to allocate more testing and development/fix iteration time at this stage.. We are committed to working with you to manage this time.
Beta launch and onwards are typically not estimated in our initial agreements. It is part of ongoing support and future version development and management.
Basic deployment is factored in and any added requirements and complexities can be reviewed and estimated during this phase.
Data migration is not estimated in the initial project proposal. If required, it is addressed and estimated during the final phases of the project as there are unknown elements during the initial phase of development that makes it hard to determine the time needed here.
Outside support and expertise can be considered for additional testing, deployment and migration. There are firms that specialize and have expertise in these domains that can potentially augment our resources in the successful delivery of your project. These services are typically estimated separately on a cost basis. Please ask your product manager for more information on this should you be interested in options here.
Automated testing can be implemented for your core project functions and we typically estimate and plan for this after beta launch. At this point, we have worked out optimal test cases.
As we approach the beta phase, our team will work with you to build or refine your future roadmap, plan resources/timelines and provide range estimates for versions/releases. This is a critical step and we strongly recommend that it is done in a timely manner to allow for collective planning purposes and ensuring resource availability.
For more information about our FlexPricing, or if you are interested in getting a quote on a project idea, please email us at Austin.Beverage@azularc.com. Also, feel free to check out some of our recent projects by clicking here.