You avoid lock-in by owning the process, and by routinely taking control of the project's artifacts and deliverables throughout the project life cycle. Especially in the software world, so long as you have the source code, you're never truly "locked in." You can always take your football (or source code) and go home, although that's not always your best business strategy.
In addition to actively participating in your own process and keeping control of your bespoke artifacts, you need to consider how you will work with your vendor. A collaborative, transparent approach is often your best bet for maintaining flexibility and reducing risk throughout the project life cycle.
Value Collaboration, Transparency, and Tight Feedback Loops
We have ruled out developing the software ourselves as leadership feels that may be expanding our mission too much at once.
Anytime you rely on goods or services outside your company, this represents project risk. The size of your vendor pool may change the size of your risk, but it doesn't really change the fundamentals of the type of risk you're facing.
As a rule of thumb, always avoid the mistake of "throwing work over the wall" to your vendors. You own the product or service that they're building for you, so it is in your best interests to collaborate with them as closely as you can.
From an agile perspective, your goal should be to have a very tight feedback loop. There should be ongoing transparency, and potentially-shippable increments of functionality should be reviewed together by your stakeholders and your vendor on a predictable cadence of 1-4 weeks. This review should be more than just a sign-off or a slide show; it should be a collaborative inspection of the increment of work. This inspection provides feedback to the vendor, so that any on-the-fly adjustments to scope and direction can be discussed together. It also provides visibility to stakeholders, so that business decisions and trade-offs about cost, budget, or schedule can be made in an informed way.
The very worst-case scenario is that you discover the project can't be delivered on time or on budget. By working more closely with the vendor than may be typical, you'll discover that sooner and can "fail faster." What you do then is also a business decision, but it's often better to discover that a project will deliver late, cost more than expected, or fail altogether sooner rather than later. No methodology will guarantee success, but "failing fast" is the best way to keep your options open and avoid the sunk cost fallacy.