Hiring a software consultancy is a significant decision. You’re trusting an external team with your product, your timeline, and often a substantial portion of your budget. Get it right and you gain a genuine technology partner. Get it wrong and you’re left with missed deadlines, ballooning costs, and a codebase you can’t maintain.
I run a software consultancy. I’m going to tell you exactly what to look for - and what to avoid - when hiring one. Some of this will sound self-serving, and I’ll be honest about where our model aligns with the advice. But the principles hold regardless of whether you work with us or someone else.
The Red Flags
Let’s start with the warning signs. These aren’t edge cases. They’re patterns we see repeatedly in the projects we’re brought in to rescue.
You never speak to the people who’ll write the code. This is the single biggest red flag. If your only point of contact is an account manager or project manager, and you have no direct access to the engineers building your product, something is wrong. It usually means the people on the sales call are not the people doing the work. The senior architect who impressed you in the pitch is a sales prop. The actual development is handed to junior developers or an offshore team you’ll never meet.
Vague or suspiciously low estimates. If a consultancy quotes you a fixed price for a complex project after a single conversation, they’re either planning to cut scope aggressively or expecting to make it up in change requests. Software estimation is genuinely hard. Any honest consultancy will tell you that. What they should offer is a clear process for discovery, a realistic range, and transparency about assumptions. If it sounds too cheap, it is.
No discussion of IP ownership. Who owns the code when the engagement ends? This should be addressed upfront, clearly, and in writing. If a consultancy is vague about intellectual property, or if their standard contract retains ownership of what they build for you, walk away. You’re paying for bespoke software. It should be yours.
The body shop model. Some consultancies are really just staffing agencies with a website. They place individual contractors on your project with minimal oversight, no architectural guidance, and no accountability for outcomes. You get a warm body at a desk, not a team that takes ownership of delivery. If the consultancy can’t articulate their engineering standards, their review process, or their quality controls, you’re hiring headcount, not expertise.
No evidence of their own engineering practices. A good consultancy practises what it preaches. Ask about their CI/CD setup, their code review process, their approach to testing. If they can’t answer with specifics, the quality of what they deliver will be inconsistent at best.
The Green Flags
Now the positive signals. These are the characteristics that separate genuine technology partners from vendors who happen to write code.
Direct access to senior engineers. The people building your product should be available to you. Not filtered through a project manager, not hidden behind a ticketing system. Direct communication with senior engineers means faster decisions, fewer misunderstandings, and a team that genuinely understands your business context. At OLXR, every engagement is led by a senior engineer. There’s no bait-and-switch between the pitch and the project.
Transparent pricing. You should understand exactly what you’re paying for before any work begins. Whether it’s a day rate, a sprint-based model, or a fixed-scope engagement, the commercial terms should be clear, predictable, and free of hidden costs. If a consultancy won’t publish their pricing or give you a straight answer about rates, they’re optimising for their margin, not your trust.
They challenge your assumptions. A good consultancy doesn’t just build what you ask for. They push back when your approach has risks, suggest simpler alternatives when you’re over-engineering, and bring experience from other projects to improve your outcomes. If every conversation feels like agreement, you’re paying for order-takers, not advisors.
A clear handover plan. Every engagement should end with you fully capable of maintaining and extending what was built. That means clean documentation, knowledge transfer sessions, and a codebase that your internal team - or your next consultancy - can pick up without archaeology. If the consultancy’s business model depends on you being unable to leave, that’s not a partnership.
Evidence of real work. Case studies, technical blog posts, open-source contributions, or detailed portfolio entries that demonstrate genuine engineering depth. Not just logos on a website, but evidence of how they think, what they’ve built, and the problems they’ve solved.
The Questions You Should Ask
Before signing with any consultancy, get clear answers to the following. Who will write the code, and can I meet them before we start? What happens when the project scope changes - and how will that be communicated and priced? Who owns the intellectual property, and what does the handover process look like? What’s your approach to testing, code review, and deployment? Can you show me a recent project and walk me through the technical decisions?
The answers to these questions will tell you more than any sales presentation. A consultancy that answers them openly and specifically is one that’s confident in their process. One that deflects or generalises is one you should approach with caution.
A Note on Transparency
I’ll be upfront: OLXR’s model is built around the green flags described above. We publish our pricing. Every project is led by a senior engineer with direct client access. We transfer full IP ownership as standard. We maintain detailed documentation and a clear handover process.
That’s not because we’re uniquely virtuous. It’s because we’ve seen from the inside what happens when consultancies operate without these principles, and we built our business specifically to be the kind of partner we’d want to hire ourselves.
Whether you choose to work with us or not, the principles in this post will help you find the right fit. The software consultancy market is full of excellent firms and full of disappointing ones. The difference is usually visible before you sign the contract, if you know where to look.
