Mad Devs is an IT consulting company that has been engineering its partners’ growth since 2004. Our goal is to deliver value to our customers in the long run by solving end users’ problems.
This can be achieved only by transparent communication and development processes that are based on collaboration and co-creation.
One of the main obstacles is the lack of information as some vital questions will be omitted, unintentionally avoided, or forgotten about.
For years, we’ve seen new players in the IT industry struggle to find insights into custom software development. Mad Devs has summarized its expertise by introducing Customer University: a series of articles that bring light to questions that need to be asked during negotiation and proposal evaluation stages.
Pricing is naturally one of the main concerns the customers face. We prefer to explain the mechanism of project estimation transparently. We believe in starting the partnership with building trust from the very beginning. Technically, the process breaks down into 4 steps.
Step 1. Receiving the request
When we receive a request for partnership, first of all, we assess the proposed project to see if we are a proper contractor to take it on. Mad Devs believes that signing a contract is a long-term commitment. Customer’s business success depends on whether we have enough expertise and capacity to deliver the project.
Only after we ensure that we have enough expertise and capacity to deliver the product, we start evaluating the customer's product vision and check whether it has a proven record of market fit.
Unfortunately, it is unlikely to build a product that is valuable to end-users without precise product specifications and requirements. Such projects usually involve high risks and a lack of personal growth for our developers. Instead of developing features, the IT team will be trapped in a circle of re-developing one module repeatedly and waste the budget.
We prefer to avoid customers with the following characteristics:
- No vision for the project: there’s a list of requirements in the request but no explanation of how the project can survive in the market or otherwise make profits.
- Projects of small scope or short life span: our approaches (well-established processes, attention to detail, and emphasis on sustainability, e.g., architecture and CI/CD) are suitable for high-loaded projects.
- MVPs without market fit: we do not undertake projects without a defined target market.
Step 2. Researching & Estimating
Often when we receive a request to develop software, it is possible to solve the problem without actual coding. In such cases, it is essential to understand customer requirements and research third-party solutions.
At Mad Devs, we aim to build products that indeed bring value to both end-users and our customers. Although we love coding, developing a product just for the sake of developing it doesn’t align with our corporate values and mission. Only when we ensure that a product’s value proposition is clear, then we as software engineers can propose our solution. Such an approach allows us to build products without detailed requirements and strict deadlines.
Estimating a project's scope is the next step. Most of the time the estimation is based on the IT team’s seniority levels and its composition. Then we divide the overall scope into stages and later into modules. Together with the combined minds of the SWOT team and the customer, we build a high-level roadmap and define a tech stack.
The project's estimates are a sum of all module estimates combined. Although, in the beginning, it is almost impossible to predict the exact deadlines and scope of work, a high-level roadmap still brings some clarity and understanding of a project's financial feasibility.
Note that at Mad Devs, we include 15-20% risks to each module, and the percentage is distributed to every feature. Such risk management is necessary as the project scope is frequently adjusted and new black boxes appear. Since 2004, we’ve worked on dozens of highly-loaded IT projects and have come up with practical ways to mitigate risks and adequately plan project scopes. However, it is practically impossible to have a 100% accurate plan. Regardless, we do our best to clearly communicate our risk management policy.
We also include a so-called development tax and deal with technical debts, quality assurance tests, and writing up-to-date documentation. Such additional processes are necessary investments to ensure the product’s stability and scalability. The lack of tests and documentation will lead to more significant problems such as the big rewrite antipattern and technical archeology.
Step 3. Choosing the cooperation model
The experience we gained in 50+ large-scale projects has allowed us to develop 360-degree expertise and suggest solutions that fit customers’ business needs. In some instances, we incorporate a hybrid cooperation model.
- Staff augmentation: we assign individual specialists from our team to complete tasks for you.
- Project-based dedicated team: we provide you with a team (often featuring a project manager) to undertake your project as a whole.
- Temp to hire: we assign individual specialists to complete tasks for you so that they can be later transferred to your team as full-time employees.
- Technical assessment & Consulting: our technical experts with specific expertise perform analysis for you and provide recommendations.
- Team supervision: our managers and team leads supervise your current team and help manage it more effectively.
- Legacy software management & Project transfer: we take on projects that other teams have worked on but failed to deliver desirable results.
Although, to some customers, the required cooperation model is clear. Some require careful assessment of current and future needs. The description of each cooperation model is presented below:
Step 4. Proposal agreement and negotiation
The proposal agreement and negotiation process is a long cycle, where our goal as an IT consultant is to understand whether our plan reflects the short and long-term product vision. After a presentation of our plan together with a customer, we adjust it. Such changes in the final agreement can involve multiple interactions and re-estimation until the final result satisfies both parties.
Inside the document, we do our best to answer all possible questions and transparently show the pricing breakdown.
Our proposal includes the following sections:
- Project goals
- Project brief
- Detailed information on tasks breakdown
- Team composition
- High-level project roadmap
- Development plan and duration
- Cost procedure and quotation assumptions
Extra: Pricing model and formula
We work on a Time & Material basis, which means that you only pay for the actual time our specialists work on your project (this time is tracked in the typical project environment). The basic formula is:
The first essential element in the formula above is time. When calculating it, we include estimates of the whole product development process, including dealing with technical debt and real users’ feedback.
The second element in the formula is the team. It can consist of developers of different seniority levels (Junior, Middle, and Senior). Their rates are different, too. We make sure to explain our team composition* choices in the proposal.
We use the time & material model because it enables flexibility. Under this arrangement, a project will have a more or less stable monthly budget, while the scope and tasks can be reconsidered. The alternative—the fixed price model—is rigid: any changes in the initial plans require revising the contract. Click here to learn more about the differences in pricing models.
* When we compose the team, we make sure to match the members’ expertise with the project's needs. If the team is overqualified, the customer will be paying an unnecessarily high rate. If the team is underqualified, it will spend too much time on development, so the customer will end up overpaying. We want to avoid these scenarios.
Trusted IT partner
Our pricing, as well as our approach to developing software, is focused on delivering value. We aim to develop products that ultimately make our customers successful by delivering software that solves end-users needs and wants. Here are the reasons why our customers choose us over other contractors:
- Expertise in long-term, stable and scalable, high-loaded products.
- Transparency in organizational and development processes.
- Value-oriented development.
- Commitment and determination to achieve project results.
Mad Devs has the experience to rely on and smart approaches to development. Moreover, we do not hide our plans, processes, or calculations—instead, we share those enthusiastically. This is why, when you receive a proposal, you also receive a detailed explanation of why a particular approach will be the best option to implement in your project.
If you have questions or want to discover more details, get in touch with us.