Software Procurement Playbook 

Most procurement processes fail before a single vendor is contacted: the requirements were never written down precisely enough for any vendor to price accurately, so every quote that comes back is really a quote for a different, unstated version of the project. This is the sequence we'd recommend to any organization about to run a procurement process for custom software, a dedicated team, or an ERP platform, whether or not RNDSOL ends up being the vendor you choose.

1. Define Requirements Before You Talk to Anyone

• Write down the business problem in one paragraph, not the solution: what's broken, not what you think should replace it.
• List every stakeholder whose workflow the software touches, and get each one to describe their part of the process in their own words.
• Separate must-haves from nice-to-haves explicitly, as a numbered list; vendors price must-haves and treat nice-to-haves as negotiable scope.
• Note every existing system the new software has to integrate with, including the ones nobody likes talking about.

2. Set a Realistic Budget Range, Not a Single Number

• Research comparable project costs for your category before writing an RFP, not after receiving quotes.
• Set a range, not a fixed number: a spread wide enough to accommodate genuine scope differences between vendors' approaches.
• Budget separately for post-launch support and iteration; a launch date is not a finish line.
• Decide your walk-away price before negotiations start, not during them.

3. Structure the RFP So Answers Are Comparable

• Ask every vendor the same specific questions, in the same order, so answers can be compared side by side.
• Request a breakdown by phase or sprint, not a single lump-sum figure.
• Ask how requirement changes are priced mid-engagement. This reveals more about a vendor than their initial quote does.
• Ask directly who owns the code and IP after delivery, and get it in writing before you get to contract stage.

4. Evaluate Beyond the Price Line

• Ask for two to three reference conversations with past clients in a similar industry or project size.
• Ask how the vendor handles a sprint that reveals the original estimate was wrong: the answer tells you what a real engagement will feel like.
• Check for timezone overlap that actually supports daily collaboration, not asynchronous handoffs across a wide gap.
• Confirm what 'done' means contractually, a specific set of deliverables, not an open-ended relationship.

5. Run a Trial Before You Commit Long-Term

Wherever possible, structure the first phase as a paid discovery engagement or a short trial sprint rather than committing to the full build up front. A two-week discovery phase that documents requirements, personas, and technical constraints before a proposal is written costs a fraction of the full engagement and tells you more about how a vendor actually works than any reference call can. If a vendor resists starting small, that's information too.