Pricing built for quality-focused projects

The average minimum cost of a two-week sprint from Bluefruit is £30,000.

Most of our clients have projects that last for five to eight sprints. For projects in their first year, Bluefruit is better value for money than an in-house team or contractors.

Value for money

But how does the cost of working with Bluefruit stack against contractors and in-house teams? (Aside from the quality of work and knowledge that we bring to a project.)

Contractors—with a UK average day rate of £600, and the complexity of navigating IR35, Bluefruit will always work out more cost effective.

You’ll only need to onboard us as part of your procurement process rather than recruitment and payroll. Bluefruit has complete teams, ensuring you’ll always have people available to work on your project, helping you keep the pace you need to stay on schedule. Meanwhile, a contractor will still need a team lead to keep them on track.

In-house teams—Bluefruit are better value for money in the first year and become less cost-effective as you build up your in-house team.

If you can find the right people and establish good processes, then an in-house team takes one to three years to become as productive as a pre-formed, high-performing team. But building an in-house team can take longer.

Once you’ve set up your team, they’ll be better value. To help you and your team move away from us, we ensure we code and build documentation with high conceptual integrity. Doing this ensures your in-house team can take it all on once they’re ready to be involved full-time without us.

Complexity affects price

The above depends on the complexity of your project.

Poor-quality existing code

For instance, existing code will not necessarily bring your costs down. If that codebase has no unit tests, has high complexity (“spaghetti code”) and is full of technical debt? That will take time and skill to work on and improve.

Highly-regulated spaces

Is your product for a highly regulated industry? Where each process, the choices made in code, and so on need to be recorded right from the get-go? If you’ve failed in documenting all that? That isn’t a refactoring project. That’s a rewrite.

Unknown unknowns

And finally, if we find “unknown unknowns”? (The things you didn’t know, you didn’t know at the start of a project.) Time spent dealing with those will affect project costs. Planning will only get you so far in knowing what to expect in a project.