10 Things to Decide Before Ordering Custom Software Development — An Internal Readiness Checklist
A checklist of 10 things to decide internally before ordering custom software — from clarifying your goal to planning maintenance — plus what happens if each item is left undecided.
Why 'Internal Readiness' Determines Whether an Order Succeeds
Much of what determines whether a custom software project goes smoothly is decided before you even select a development company. No matter how experienced the vendor, if your own organization hasn't settled on its goals and internal structure, you're likely to run into scope creep, extra costs, and delayed launches. Here we lay out 10 things worth deciding internally before you begin the ordering process, in checklist form. For an overview of the entire ordering process, see the Guide to Ordering System Development.
Why It Matters to Decide Things Before Ordering
Many business owners assume they can figure things out once they start talking to a development company. But a development company isn't a mind reader — they can only build proposals and quotes based on the information you provide. If the process moves forward while your goals and internal structure remain vague, new requirements tend to surface mid-project ('actually, we also wanted this'), and decision-making stalls because it's unclear who inside the company has final say. This kind of approach tends to drift toward what's sometimes called fully outsourcing without oversight, which typically has significant consequences for cost and schedule.
Typical Trouble Caused by Insufficient Preparation
When a company orders development without adequate internal preparation, a few problems tend to recur. First, because the goal is unclear, different vendors' proposals end up pointing in different directions, making comparison difficult. Second, specifications get locked in without actually consulting the people who do the work day to day, leading to complaints after launch that 'this doesn't actually work for us.' Third, because no budget range was communicated, the resulting quote comes in far higher than expected, and the whole project gets shelved. These patterns are explored further in Common Failure Patterns in System Development.
10 Things to Decide Before Ordering
| Item | What to decide | What happens if it's left undecided |
|---|---|---|
| ① Clarifying the goal | Can you state, in one sentence, what problem this is meant to solve? | Without a shared goal, every feature discussion resets to square one |
| ② Auditing current operations | Have you mapped out current workflows, tools, and stakeholders? | Specifications drift from actual practice, and the system goes unused after launch |
| ③ Appointing an owner and a point of contact | Have you named who makes final decisions and who handles day-to-day communication? | Decision-making stalls, and the vendor doesn't know who to check with |
| ④ Budget range | Do you know roughly the ceiling you can invest? | An unexpectedly high quote arrives and the whole project gets shelved |
| ⑤ Priorities | Can you separate must-have features from nice-to-haves? | Trying to include everything inflates both budget and timeline |
| ⑥ Location of existing data | Do you know where data that needs migrating currently lives, and in what form? | Migration work surfaces mid-project, delaying the schedule |
| ⑦ Security requirements | Have you sorted out whether personal data is involved, and what authentication/permission levels are needed? | Security requirements surface right before launch, triggering extra costs |
| ⑧ Desired launch timing | Do you have a target date, worked backward into a realistic timeline? | You can't judge whether the vendor's team and schedule are realistic, leading to an unworkable plan |
| ⑨ Maintenance arrangements | Have you decided who will handle support requests and fixes after launch? | When issues arise post-launch, no one can respond, and operations stall |
| ⑩ How to measure success | Have you defined what "success" looks like, in measurable terms? | You can't evaluate the investment afterward, making the next investment decision harder |
Three Items That Are Often Overlooked
Among the 10 items, budget range, maintenance arrangements, and how to measure success are the ones most often overlooked at the ordering stage. For the budget range, you don't need an exact figure — simply having an internal sense of 'roughly this much as a ceiling' makes conversations with development companies far smoother. If you go in without sharing any budget, you end up judging whether a quote is reasonable only after receiving it, leaving little material for comparison or negotiation.
Maintenance arrangements also tend to get pushed aside as 'something to figure out after development is done,' but in practice this phase often lasts far longer than the development itself. Deciding roughly, before ordering, who will handle bug fixes and minor changes — whether through a maintenance contract with the vendor or handled internally — helps avoid confusion once the system is live.
Without deciding how to measure success in advance, you have no way to evaluate afterward whether the investment paid off. Settling on one or two metrics suited to your situation beforehand — reduced task time, fewer input errors, changes in inquiry volume, and so on — makes it much easier to review results after launch and inform your next investment decision.
How to Move Through the Preparation Process
- Hold an internal kickoff: Bring together the decision-maker and point of contact to align on goals and timeline
- Audit current operations: Even a simple workflow diagram or list of pain points is a good start
- Organize the 10 items into a sheet: Use this checklist as a starting point for an internal document
- Turn it into an RFP or request document: Use the Guide to RFPs and Requirements to compile it into one or two A4 pages
- Consult and request quotes from multiple companies: Compare proposals on equal footing using the information you've organized
Frequently Asked Questions
Do all 10 items need to be perfectly decided before I place an order?
No, they don't need to be perfect. Items like budget range and priorities can be refined through conversation with a development company. That said, information only your company can know — like your goal and current operations — is worth organizing as much as possible beforehand.
What if we don't have anyone in-house with IT expertise?
It's common for small and medium-sized businesses not to have a dedicated IT staff member. In that case, it's practical for the business owner or an operations lead to take the initiative, starting by organizing information using a general checklist like this one.
What should we do after completing this checklist?
The next step is to turn the organized information into a written RFP and consult multiple development companies for proposals and quotes. For guidance on writing an RFP, see An Executive's Guide to RFPs.
Summary
How smoothly a software development project proceeds is shaped less by which vendor you choose than by the quality of your internal preparation beforehand. Working through the 10 items covered here — clarifying the goal, auditing current operations, appointing an owner and point of contact, setting a budget range, defining priorities, locating existing data, sorting out security requirements, setting a desired launch timing, arranging maintenance, and deciding how to measure success — and putting them into words internally is the most direct path to a smooth ordering process. See the Guide to Ordering System Development for an overview of the process, and An Executive's Guide to RFPs for how to turn these decisions into a document.
Feel free to contact us
Contact Us