Comparing software estimations in a nutshell

Assessing the value of software development services is much different from assessing the value of a car, for example. If you buy a car of a certain make and model, you agree on a set of features and equipment.

Even though a great deal of mechanical factors come into play, the manufacturer will have all of them listed in their specification. The hundreds of cars that leave their production lines are all exactly the same. The moment you even start thinking about buying your car, the vendor will know exactly how much it will cost.

Software development and software products are uncertain by nature. The scope is often difficult to predict when you’re only discussing your project idea.

Each web or mobile app uses some standard screens; the login or settings views both work as good examples here. But let’s consider something as seemingly simple as a list of records, like items in your virtual storage box or a catalog of potential business partners in a given area.

On the surface, they seem quite alike. However, the mechanics of each—how they are stored, what you can do with each item, how the application collects logs, etc.—can differ significantly.

The representatives of the vendors whose services you’re considering need to be able to catch those differences and uncertainties, and clear up as many of them as possible. Your involvement in the process will make it easier or harder for them. Yes, the quality of the estimation depends on you, as well.

Team extension services: What to consider in software estimates?

Let’s start with an arguably less complex service: team extension. Team extension is when you already have a development team, but need to scale it up. From our experience, you might want to extend your in-house team with outsourced developers the most when you’re:

                     
1. chasing fast-approaching deadlines,
                     
2. struggling to hire specialists in-house,
                     
3. looking to gain a competitive advantage quickly.
                   

In team extension, it’s important that your new team members work side by side with your in-house developers to support them with their hands-on experience. They also need to be able to use your infrastructure and processes right away, without requiring long onboarding or extensive mentoring.

Team extension services are usually based on hourly or daily rates, which is why they’re relatively easy to compare. With a set monthly budget, you can clearly see how many months of cooperation you’ll be able to afford.

But, wait… does that mean a lower price per month equals longer collaboration?

Not necessarily. There’s more to it than that.

The following eight additional factors make all the difference here.

1. Developer seniority

Find out whether your potential vendor is offering senior, regular, or junior developers. Ask for their experience based on:

                     
• the years of professional experience, since the pace of promoting developers varies in different countries and organizations;
                     
• the descriptions of projects they took part in and the responsibilities they had in each of them.
                     

A regular developer with experience in projects similar to yours might pale in comparison to a senior. However, because they've dealt with problems in your specific business vertical, they could actually outperform their more senior counterparts.

In addition, seniors come in different shapes and sizes. Your potential development partner should not only be able to recommend the best developer for the job, but also compose a balanced team with an appropriate ratio of experience and domain knowledge.

A balanced team is usually more reliable and motivated than a so-called “dream team” composed of randomly picked seniors with the greatest total experience.

2. Exclusivity

Make sure that every developer working for you is assigned to only one project—yours. This way, they have a higher chance of focusing on solving your problems rather than jumping from one task to another.

Context switching may seem innocent, but it is a productivity killer. People who need to be re-onboarded every time they switch between projects tend to lose 20% of their time. At the end of the day, these additional hours will be popping up on your bill.

3. Location

The cost of living and therefore salaries can vary two or even threefold between neighboring countries. Although development rates don’t differ wildly across Europe compared to other industries, it’s still more affordable to outsource to the CEE region than, say, Germany or the Netherlands.

As you compare hourly rates, consider the average rate for given countries and the cost-to-quality ratio. Location also plays a role when you want the team to be able to meet in person every once in a while.

But the opportunity to have an actual, face-to-face sit-down together is not the only advantage. Choosing a nearshoring option—e.g. choosing a European vendor if you’re a European company—also means a better culture fit and easier time difference management.

4. Average daily rate

There is a saying that a day is equally long for everyone—but not for every software house. When comparing software development offers, note the number of billable hours per day, since this can vary from 6 to 8 hours.

Some software companies tend to bill the entire daily availability of their developers, while others exclude internal meetings—like sessions with a supervisor—from the timesheet.

5. Command of English

If you choose to outsource, you’ll be communicating with your vendor remotely on a daily basis.

In order to avoid miscommunication, make sure the team speaks English on at least an upper intermediate level (a.k.a. B2).

6. Managing people

With a part of your team working in a different country, you’ll be faced with some personnel management challenges. A solid partner will take those off your shoulders.

Check if your potential vendor wants to bill you for their employees’ development. Remember that although outsourced developers work on your project, they remain your vendor’s employees.

Activities such as one-on-one review meetings, feedback sessions with the Service Delivery Manager, or training should remain your vendor’s investment.

7. Technical skills

When you have your existing development team in place, the odds are in your favor. You may be tempted to involve your developers in talking to their potential future colleagues. Even running technical interviews yourself might seem like a good idea.

It’s not. In reality, a technical interview is not a silver bullet.

Assessing a developer’s technical skills in a single interview is a backbreaking, if not impossible, challenge. A vendor–client interview takes 30 minutes—an unrealistically short time window to claim anything meaningful about someone’s abilities.

Whenever we hire new developers—and we do it all the time—technical interviews and sessions can last up to several hours. It’s our responsibility to assign the best possible people to your project. The blame also falls on us should anything go wrong.

We’ve found that one-month test runs work much better than interviews. After that time, it’s far easier to evaluate the skill set, attitude, and culture fit of your outsourced team.

8. Hourly rate structure

Once you have your strategy in place, make sure you understand how the software outsourcing company structures their hourly rate. They may be doing it by:

                     
• developer seniority,
                     
• time pressure,
                     
• team size,
                     
• time commitment,
                     
• multiple other factors.
                     

It is absolutely your right to know the pricing and the way it could change while the project is ongoing. A trustworthy and transparent software partner will be confident enough to explain all the nuances to you.

End-to-end development services: How much should your software cost?

Now that we’ve tackled the less complex scenario of team extension, it’s time to move on to the more complex case: outsourcing the end-to-end development of your entire project. How do you compare various estimations then?

What you can expect from an outsourced development partner before you start working together is a ballpark (or rough) estimate. If you receive a ballpark from an experienced team with many completed projects, there’s a good chance you won’t go over budget. For instance, we have delivered 350+ software products, at which point the estimations get a little easier.

Usually, a ballpark estimate includes:

                     
• a feature (or at least module) breakdown of the project,
                     
• predicted timeline for each feature (or module),
                     
• team composition,
                     
• budget range,
                     
• additional costs (e.g. configuration- or process-related),
                     
• the list of assumptions made during the estimation.
                   

We won’t be focusing on the feature breakdown, but rather on the less obvious factors that show when an estimate is coming from a team you can trust. And trust in software development projects is built through honest communication.

An honest software development team will make sure you’re aware that an estimation is never an exact number. Your budget may (and probably will) exceed it at some point. In order to keep the risk to a minimum, an experienced team should insist on discussing your project limitations.

They will also let you know whether your project is ready for an estimation and what exactly is included in the estimation (including non-coding work, for example).

1. What input should you provide to receive a ballpark estimate?

To deliver a software development estimation, vendors need to take into account pretty much everything that can affect the application architecture, infrastructure, and behavior. Therefore, you can expect to be asked about the following:

a) Non-functional requirements

These are all the limitations and goals not related directly to your feature list, such as:

                     
• the load your app needs to handle,
                     
• the peaks it needs to sustain,
                     
• the estimated cost of cloud infrastructure,
                     
• responsiveness (mobile-friendliness),
                     
• regulation compliance.
                     

If your app is just an MVP made for a quick round of testing, it shouldn’t take that many resources to complete. But if your aim is to build a solid and scalable architecture from the start, the amount of time and effort required to lay the foundations will increase several times.

b) Deadlines

Your timeline is one thing, but if you also have deadlines to meet, the team will need to be flexible enough to come up with solutions to overcome that limitation. Temporary workarounds are sometimes advisable.

c) Budget

There is an infinite number of variations of the same app, depending on the development language, architecture, infrastructure, and even the team.

In order to choose your outsourcing partner wisely, don’t keep your budget figure from the vendors you’re considering. Sharing it with them is the only way to get a fair and reasonable estimation of how much they’ll be able to do with what you can pay.

2. What should you avoid when looking for an honest estimation?

a) Receiving a ballpark from a vendor before they talk to you

This is a major red flag. A respected vendor will insist on having their Sales Representative and Business Analyst or Product Owner talk to you first.

Then, if they have additional technical questions, they might ask one of their Service Delivery Managers to discuss any remaining details with you.

b) Asking a vendor to estimate building a clone of an existing software product

Doing so would be like asking the vendor to go through the screens of the Uber app, list all the features, figure out how they work on the backend, and make them fit your business idea. That’s not how this works.

Those simply aren’t reasonable expectations. If you feel an existing application serves as a good reference point, by all means mark it as such, but don’t stop there; get familiar with product discovery workshops, as well.

Discovery workshops will help you translate your business priorities to a relevant set of functionalities, instead of copying someone else’s solutions.

3. What non-coding work should you expect to be included in an estimation?

Apart from the obvious estimation by feature or module, you can expect a software development company to want to charge you extra for certain activities. It’s not surprising when you take into account that building a successful digital product is much more complicated than passing a list of features to a group of developers.

Established vendors will have the right skill set and process to keep both you and the team motivated, focused, and results-driven. They will also take precautions to avoid any hiccups made by low coding or processing standards.

a) Environment setup and application deployment

The time for setting up the project on all platforms, like the web and mobile, or pushing applications to stores is decidedly a part of development work. You should not be surprised if a vendor includes it in their estimation.

The good news is that experienced teams should have some of those processes automated, although it can take up to several days for existing applications with a non-standard setup.

b) Team meetings

Most software companies work closely and actively with their clients. Every session spent on discussing requirements, creating test cases, and figuring out ways to improve the team’s efficiency is in fact a step toward reaching the right solution.

It might sound counterintuitive to some, but bear in mind that the most wasteful sprints usually originate in mismanaged communication, not poor coding.

c) Testing and code reviews

Myths and misconceptions surrounding software development are a dime a dozen.

Among the most common ones is, “If the code is written flawlessly, there’s no need for testing.” Another one would be, “Developers should write code, not edit each other’s code during billed hours.”

These statements aren’t just far from the truth—they are dangerous and detrimental to your project’s quality and budget.

Code reviews and testing routines can actually save you many hours, if not days, wasted on fruitless debugging when an unexpected error pops up at the worst possible time.

d) Product Owner engagement

Product Owners translate your product vision and requirements to the development team, making sure the right features are built at the right time. As such, the PO is a proxy who keeps all the plates spinning and balls rolling.

A project without a PO working closely with the development team is much more likely to misalign the end product with the business objectives, and thus make your entire development a lot more expensive.

e) Research tasks (spikes)

As much as modern programming languages make it possible to achieve more with almost every update, some features or integrations become deprecated once in a while.

Therefore, even if you work with a really skilled team—or perhaps especially if you work with one—chances are they will be doing additional research as part of your project.

Prepare yourself to treat research as an investment in making bulletproof decisions, not an unnecessary cost.

f) Production monitoring

Setting up all the development tools and practices only to repeat it all for the production environment may seem frustrating. However, if you’d rather not deal with bugs on production, you’d better invest in good protection.

A monitoring tool will send warning and error signals to the development team. They can react to those quickly and avoid application downtime or spending long hours on debugging. The latter is particularly important in the case of mobile applications.

Final thoughts on estimating software development costs

Whether you’re looking for a robust, project-based estimation or a solid, long-term cooperation between your team and your nearshoring partner, there are many moving parts you need to consider.

                     
1. The rate of each software house is a function of several factors—economical, educational, and process-related. The cheaper option isn’t necessarily the one that brings the best value.
                     
2. Non-functional requirements are just as important as their functional counterparts.
                     
3. If you expect a quality estimation, make room in your budget for additional factors, such as code reviews, deployment and configuration, the Product Owner, team meetings, etc.
                     
4. Have a plan for when your project goes live. Are you going to hand it over to your in-house team or use a post-development service like maintenance, application monitoring, or part-time support? No matter what you choose, the development team should help you move smoothly through both scenarios.
                   

Don’t rush unless you absolutely have to. Take the time to get to know the team and their capabilities. Ask how they work and what kind of engagement they need from you. Talk with the vendor’s other clients and ask about their experiences.

But at the very least—if you are pressed for time and can’t afford such luxuries—study the vendor’s portfolio. Do whatever you need to do to make sure it’s a good match, even if it isn’t the cheapest one. In software development, as in life, money isn’t everything.

That’s it from us. Now, it’s time for your move. How about we send you a non-binding estimation, so you can apply your newfound knowledge and have one more outsourcing option to choose from? Let us know!