The 7 Questions to Ask Before You Commission Custom Software

The 7 Questions to Ask Before You Commission Custom Software

Commissioning custom software is a significant investment. The outcomes range from transformative to disastrous, and the difference is rarely about the quality of the code. It is about whether the right questions were asked and answered before the build began.

These seven questions are not a formality. They are the work that determines whether your project succeeds. A development partner who cannot answer them clearly is a development partner you should not hire.

Question 1: Have We Validated Demand Before Building?

Custom software built for a problem that does not exist in the way you think it does is the most expensive possible validation strategy. And yet, it is remarkably common.

Before commissioning a build, you should be able to answer:

• Who has this problem? Have we spoken with them directly?
• How are they currently solving it? What workarounds exist?
• Have we tested whether they would use (and pay for) a solution like this?
• What is the evidence of demand that is not based on our own assumptions?

What a bad answer looks like: "We know there is demand because we have the idea and it makes sense." This is not validation. This is confidence.

What a good answer looks like: "We ran a landing page test and got 180 waitlist signups from our target segment. We interviewed 12 of them in depth and four agreed to pay in advance. Here is the evidence."

If you cannot answer this question with data, commission validation work before development work. It costs a fraction of the development cost and eliminates the risk of building the wrong thing.

The MVP Planner and AI Feasibility Checker can help you structure this validation before you commit to a full build.

Question 2: Have We Scoped What "Done" Looks Like?

"Done" in software development is one of the most dangerous words in the English language. Without a definition, it means different things to every person involved.

Done for the founder might mean: the product works perfectly for every use case. Done for the developer might mean: the features specified in the brief are implemented. Done for the QA team might mean: the product passes all written test cases. Done for the user might mean: the product solves their specific problem without friction.

Before you commission any build, you need a written definition of done that covers:

• The user stories that will be delivered
• The acceptance criteria for each story
• The non-functional requirements (performance, security, browser support)
• The explicit list of what is out of scope

This document - essentially a Product Requirements Document - is the contract between your business expectation and the development team's delivery. Without it, disputes about whether the product is "done" are resolved through negotiation and assumption, which always favours whoever has more leverage.

What a bad answer looks like: "We will know it when we see it." What a good answer looks like: "Here is the PRD. Section 3 defines the acceptance criteria for every Must Have feature. The out-of-scope list is in Section 5."

Question 3: Who Owns the IP?

Intellectual property ownership is the question that founders forget most often and regret most deeply.

Custom software that you commission should be owned by you - not by the agency or development team that built it. But this is not automatic. In many jurisdictions, the default is that the creator owns the IP unless there is a written agreement transferring ownership.

Before you commission any build, confirm in writing:

• Who owns the source code on delivery?
• Who owns any algorithms, models, or databases created during the build?
• Are there any open-source components with licensing restrictions that affect your ability to sell or distribute the product?
• What happens to the IP if the project is cancelled before completion?
• Does the development company have the right to reuse components of your build in future client projects?

What a bad answer looks like: "We usually just figure these things out." Any ambiguity about IP ownership is a risk you should refuse to take. What a good answer looks like: "Our contract includes a full IP assignment clause. On final payment, all code, assets, and related IP are assigned to you. Here is the relevant clause."

Question 4: What Does Post-Launch Support Look Like?

Launch is not the end of the project. It is the beginning of the product's life - and products require ongoing care. Bugs appear. Users find edge cases. Infrastructure needs monitoring. Integrations with third-party services break when those services update.

Before you commission a build, understand:

• What happens when bugs are found after launch?
• Who is responsible for fixing them, and at what cost?
• Is there a warranty period (typically 30-90 days) during which the development team fixes bugs at no additional cost?
• What does ongoing maintenance look like? Is there a support contract?
• Who handles infrastructure monitoring and incident response?

What a bad answer looks like: "We will deal with that after launch." This means you have no budget for post-launch issues, no plan for fixing them, and a vendor who may be unavailable when you need them. What a good answer looks like: "We offer a 60-day warranty period covering bug fixes at no additional cost. After that, we offer a monthly maintenance retainer that covers up to X hours of support and any critical bug fixes within 24 hours."

Question 5: How Will We Test Before Launch?

Testing is not a phase that happens at the end of development. It is a continuous activity that should be integrated throughout the build. But many founders do not know what testing they should expect - or whether they are getting it.

Before commissioning, ask:

• What types of testing does the development team do? (Unit testing, integration testing, user acceptance testing, load testing?)
• At what point in the process does testing happen?
• Will there be a dedicated QA phase before launch?
• Will you (the founder) have access to a staging environment for user acceptance testing?
• What is the process for reporting and resolving bugs found during testing?

What a bad answer looks like: "We test as we go." This often means no structured testing at all. What a good answer looks like: "Developers write unit tests for core business logic. We maintain a staging environment that mirrors production. Before launch, we conduct a two-week QA cycle covering all Must Have features against the acceptance criteria. You will have access to staging throughout to conduct your own user acceptance testing."

Question 6: What Is the Handoff Plan?

The relationship between you and your development agency will eventually end - whether through the project completing, the agency relationship changing, or your decision to build an in-house team. When that happens, you need to be able to operate and evolve the product independently.

A proper handoff includes:

• Complete source code in a version control repository that you own
• Documentation covering the architecture, key decisions, and how to run the development environment
• Database documentation including the schema and any non-obvious design decisions
• Credentials for all services and infrastructure (transferred to your accounts, not held by the agency)
• A handoff session where the development team walks through the codebase with you or your incoming team

What a bad answer looks like: "We will send you a zip file of the code." A zip file of undocumented code is nearly useless to any developer who did not write it. What a good answer looks like: "On project completion, we provide access to the Git repository, a technical handoff document, and a two-hour handoff session with the lead developer to walk through the architecture and answer questions."

If you are commissioning custom software development, insist on a clear handoff plan before you sign the contract.

Question 7: How Is Change Management Handled?

Change is inevitable in software projects. Your understanding of the problem will evolve. Users will give feedback that changes priorities. Technical constraints will surface that require alternatives. The question is not whether changes will happen - it is how they will be handled.

Before commissioning, understand:

• What is the process for requesting changes during development?
• How are changes assessed for impact on timeline and budget?
• Who has authority to approve change requests?
• Is there a change order process? What does it look like?
• How are changes documented to prevent scope disputes?

What a bad answer looks like: "Just message us when you want to change something." Informal change management leads to uncontrolled scope expansion, developer frustration, and budget surprises. What a good answer looks like: "Changes during development are handled through a formal change request process. We assess each change for impact on timeline and budget, document the assessment, and get your written approval before implementing. This means no surprises for either party."

Putting It Together

These seven questions serve two purposes. First, they protect you as a founder by ensuring you understand what you are buying. Second, they evaluate your development partner - a team that cannot answer them clearly is a team that will cause you problems during the project.

A development company that welcomes these questions, answers them in detail, and has processes to support each answer is a company that has delivered software successfully before and knows what prevents projects from going wrong.

At Codalyst, we have written answers to all seven of these questions baked into how we run projects. If you want to see how we handle IP ownership, post-launch support, testing, or handoffs specifically, get a free quote and we will walk through our approach on your first call.

The time to ask these questions is before you sign the contract. Ask them at the proposal stage. A development partner who bristles at being asked is a development partner to walk away from.