The problem with software consultancies

Cover Image for The problem with software consultancies
Sam Cook
Sam Cook

It’s a tale as old as time — company meets consultancy, company falls in love, consultancy delivers on half of their promises in double the time, consultancy leaves for a shiny new company. Ouch.

How many times have you seen this happen? It definitely isn’t the case for all projects, but in our experience we have seen that this is a recurring theme with a lot of our high profile clients.

To win a big client, consultancies will send in their ‘heavy hitters’ — their most senior folk who know how to kick projects off and set out a decent technical roadmap. They will scaffold out a working MVP at an extremely fast rate. Forgoing proper documentation, testing, monitoring and reporting. It’s an MVP after all, right?

As time passes, the more senior members of the account will be rolled off of the project and onto their next big client, quickly being replaced with more junior consultants who haven’t worked on the project before. The consultancy will then usually continue to promise growth at the same rate at which they originally delivered, even though the team has changed and the project is no longer in the MVP stage.

Suddenly, we find ourselves in a bit of a conundrum. There is little chance that a less experienced team who aren’t familiar with the project are going to be able to keep up with the original deadlines set by their predecessors, especially now they are working on a mature system that needs to be resilient, tested and understandable. More often than not, this is the point at which the consultancy begins to either underdeliver on their promises or cut corners in order to make tight deadlines. In the engineering realm this usually leads to projects which are massively behind schedule or are:

  • Unreliable

  • Unscalable

  • Undocumented

  • Untested

The four dreaded ‘Un’s!

At some point, the agreed contract comes to an end, the client has hired a few engineers to come on full time to work on the project and the consultancy is happy to let them get on with it — they are already in search of their next project.

So! The new, dutiful engineers will slowly uncover how many corners were cut during development or be left scratching their heads at technical decisions made by the more junior consultants who didn’t know any better. They soldier through regardless, rightly using up lots of precious time and money to address the swathes of technical debt they have discovered, all the while asking “Who wrote this crap?!”.

Six months to a year after the end of the contract, the project has essentially been re-written by the permanent engineers, costing the company hundreds of thousands of pounds for the result they were looking for the first time around. Not great.

The solution 🤓

It’s all very well and good telling you that traditional consultancies suck and how we’re going to change that, but we need to tell you how. We’ll outline the Logicful way below.

Once the lightweight MVP has proved itself to be successful and the client is looking to mature the product, we will remain embedded within the team.

In depth discussions around the long term product roadmap will be supplemented by technical conversations around maintainability, scalability and testability. The outcome of these discussions will start being built into the roadmap and communicated to stakeholders. Doing this from the start will ensure that the product is resilient, reliable and easy to understand throughout its entire lifetime. This also means that no matter when we part ways with a client, they will always be left with something polished that they can work with.

We then continue to help build any new features, ensuring that we document and test them by default.

Throughout the engagement, we conduct regular project reviews and updates. When the time is right, we advise on the necessary hires the client needs to make in order to continue developing the project long term and guarantee its success.

We will then begin interviewing and hiring high calibre talent to fill our places at the company. As the new employees join, Logicful onboard them, amend any issues with ambiguous documentation / gaps in knowledge which may have slipped through the cracks and begin creating a healthy engineering culture within the company.

Towards the end of the engagement, we will perform a final review of the project to ensure all parties are happy. Once this is complete, the project is formally handed over, documentation, testing et al.

Permanent team members can then begin independently developing the product on a solid foundation, safe in the knowledge that they understand the system and can navigate it with ease.

Logicful and the client remain friends and sometimes meet up for a cuppa. ☕️

No grumbling, no re-writing huge portions of your application after the consultancy leave, no gaps in documentation, no unreliable systems, no messing around.

Summary

This is the basis of the Logicful origin story. The gang have seen this happen time and time again to many high profile clients in the industry, and have often been those engineers who are left to clean up the mess.

We believe, due to our experience in the industry and our total cognisance of this problem, that we are uniquely positioned to help our clients get the best value for their money the first time around — leaving them with systems that are reliable, easy to use, and simple for new engineers to navigate and change once we are gone.

Our passion for creating high quality results and our empathy for the people who will be maintaining and using them in the future sets us apart. There is a gap in the market for consultancies who actually give a shit. We are here to fill it.

If you’re interested in anything you’ve just read, have a project that you think we might be a good fit for, or if you would just like to argue with us, get in touch.


More Stories

Cover Image for Low-Code/No-Code Development: Democratising Software Development or Lowering Standards?

Low-Code/No-Code Development: Democratising Software Development or Lowering Standards?

Low code development tools are a great way to test out an idea or spin up a quick proof of concept internal tool for your company. They might not quite be the one size fits all solution that you are looking for though.

Aaron Kendall
Aaron Kendall
Cover Image for Strive to be boring: How to write better code

Strive to be boring: How to write better code

By embracing boring code, we’re not just writing software—we’re building a foundation for future success, one simple, predictable line at a time.

Sam Cook
Sam Cook