You've decided your business needs custom software. Maybe you've outgrown your current tools. Maybe off-the-shelf isn't cutting it. You've shortlisted a few consultancies. Now what?
The engagement process at most software consultancies is surprisingly opaque. You get a sales call, a proposal full of jargon, and a timeline that feels made up. Three months later you're wondering why the budget doubled and the project is half-finished.
It doesn't have to work that way. Here's what a well-run software engagement actually looks like — from the first conversation to final handoff — so you can spot the good firms and avoid the bad ones.
</div>
The Discovery Call: What They Should Be Asking You
The first call should feel more like a doctor's appointment than a sales pitch. A good consultancy spends 80% of this call listening, not presenting.
They should ask about your business problem, not your technical requirements. "What's breaking?" matters more than "What tech stack do you want?" If the firm leads with technology choices before understanding the problem, that's a red flag.
Expect questions like: What does your current process look like? Where does it break down? What have you tried? What does success look like in six months? How many people are affected?
A competent firm will also ask about your timeline and budget constraints upfront. Not to anchor pricing — but because a $50K budget and a $500K budget require fundamentally different approaches. Firms that avoid this conversation early waste everyone's time.
What to watch for: If the call feels like a demo of their capabilities rather than an exploration of your problem, keep looking. The best consultancies are more interested in whether the project is a good fit than in closing the deal.
The Discovery Phase: Where Most Projects Succeed or Fail
After the initial call, serious consultancies run a discovery phase before writing a single line of code. This typically takes 2-4 weeks and costs $10K-$30K depending on complexity.
During discovery, the team maps your current workflows, interviews key stakeholders, audits existing systems, and identifies the real constraints. The output is a document that describes exactly what will be built, why, and how — with enough detail that you could hand it to any competent engineering team and get the same result.
This is the phase where good requirements documentation separates successful projects from disasters. McKinsey's research shows that 45% of software project failures trace back to poor requirements — not bad engineering, not wrong technology, but building the wrong thing.
Discovery should produce three deliverables. First, a problem statement that your team agrees accurately describes the situation. Second, a solution architecture with clear trade-offs documented. Third, a phased implementation plan with realistic timelines and costs for each phase.
What to watch for: Firms that skip discovery and jump straight to a proposal are guessing. They'll pad the estimate to cover their uncertainty — or worse, lowball it and hit you with change orders later.
The Proposal: Reading Between the Lines
A good proposal is specific. It names the problems discovered, describes the proposed solution, explains why alternatives were rejected, and breaks the work into phases with clear deliverables per phase.
Watch for these elements:
Fixed scope vs. time-and-materials. Neither is inherently better. Fixed-price works when the scope is well-defined and unlikely to change. Time-and-materials works when you need flexibility. The worst arrangement is a vague scope with a fixed price — that's where disputes happen.
Phase gates. Smart engagements include decision points where you review progress and decide whether to continue. After Phase 1, you should have working software that proves the approach works. If Phase 1 fails, you've lost $50K instead of $500K. This is the same principle behind scaling AI pilots — validate before you invest.
Team composition. Who's actually doing the work? If the discovery call featured senior architects but the proposal staffs junior developers, ask questions. The best firms are principal-led — the people who design the system are the people who build it.
What to watch for: Proposals that promise everything without trade-offs. Every project has constraints. A firm that doesn't acknowledge them is either inexperienced or dishonest.
The Build: What Good Execution Looks Like
Once the engagement starts, you should see working software within the first 2-4 weeks. Not a finished product — but something you can click through and react to. Modern development practices make this possible and expected.
A well-run project has a predictable rhythm. Weekly demos show progress. You see the software evolving and can course-correct early. The cost of changing direction in week 3 is negligible. The cost of changing direction in month 6 is catastrophic.
Communication cadence matters. You should receive weekly progress updates at minimum. These should include: what was completed, what's planned next, any blockers or risks, and whether the project is on track against the timeline and budget.
The biggest predictor of project success isn't technical skill — it's communication. A Standish Group analysis found that projects with active executive sponsorship and regular stakeholder communication succeed at 3x the rate of those without. Your consultancy should make communication effortless, not something you have to chase.
Expect the team to push back on scope creep. Good consultancies don't just say yes to everything — they help you evaluate whether a new request is worth the timeline impact. "We can add that feature, but it will push delivery by two weeks and add $15K. Here's what we'd recommend instead." That's the conversation you want.
What to watch for: Radio silence between demos. If you only hear from the team during scheduled presentations, problems are being hidden. Also watch for technical debt accumulating — ask about code quality practices, testing, and documentation.
Testing and QA: More Than Bug Fixing
Testing isn't a phase at the end. It should happen continuously throughout the build. But there's a formal testing phase before launch where the software is put through its paces.
A good consultancy runs three types of testing. Functional testing confirms the software does what it's supposed to. Performance testing confirms it works under real-world load — not just with 5 users, but with 500 or 5,000. User acceptance testing (UAT) puts the software in front of actual users to catch the issues that only surface when real people with real workflows interact with the system.
UAT is where you'll discover that the workflow that looked perfect in a demo breaks when an accounts receivable clerk processes a return on a split invoice. These edge cases are normal and expected. Budget time for them.
What to watch for: Firms that treat testing as optional or rush through it to hit a deadline. The cost of fixing a bug in production is 6-10x the cost of fixing it during development (IBM Systems Sciences Institute). Testing is where that savings happens.
The Handoff: What You Should Walk Away With
The engagement ends. What should you have?
Working software that does what was agreed. This seems obvious, but scope often drifts. Compare the final product against the original discovery document.
Documentation that lets your team (or a different consultancy) maintain and extend the system. This includes architecture documentation, deployment procedures, and code documentation. If the firm is the only team that can maintain the software, you have a vendor lock-in problem. Good consultancies build systems that transfer cleanly.
Training for your team. The people who use the system daily should be comfortable with it before the consultancy walks away. This isn't a one-hour walkthrough — it's hands-on training with the actual workflows.
A support period. Most firms include 30-90 days of post-launch support. Things will break. Users will find edge cases. Having the team that built the system available to fix issues quickly is essential.
What to watch for: Firms that disappear after delivery. The first 90 days of production use are when the real problems surface. A firm that structures its engagement to include this support period is planning for reality, not just the demo.
How to Evaluate Consultancies Before You Commit
Before signing anything, do three things.
Ask for references from similar projects. Not just "happy clients" — clients who had a similar problem, at a similar scale, in a similar industry. Call them. Ask what went wrong, not just what went right. Every project has friction; what matters is how the firm handled it.
Evaluate the team, not the firm. The consultancy's website might showcase impressive case studies, but the team assigned to your project is what matters. Meet the actual developers and architects. Ask about their experience with your type of problem.
Start small. If possible, begin with a contained project — a single workflow, a proof of concept, a focused first use case. This lets you evaluate the firm's communication, quality, and reliability before committing to a larger engagement. The best firms welcome this because they know their work speaks for itself.
The Bottom Line
Hiring a software consultancy isn't buying a product — it's entering a partnership. The engagement process tells you everything you need to know about how the firm operates. Firms that rush past discovery, dodge budget conversations, or promise everything without trade-offs will deliver the same way they sell: fast, loose, and expensive.
The right consultancy makes the process transparent, involves you at every decision point, and builds something that works after they leave — not just while they're billing.
If you're evaluating consultancies for an upcoming project, book a discovery call and see what a transparent engagement process looks like from the inside.
