Commissioning custom software is one of the largest financial decisions a founder or business owner makes. The right questions asked before you sign a contract determine whether the project succeeds or becomes an expensive lesson.
These seven questions are not about vetting the technical skills of the team you are hiring. They are about validating that you have thought clearly enough about what you are building to give that team a chance to succeed.
Question 1: Can I describe who the user is and what they need to accomplish?
If you cannot describe your primary user in one specific sentence and their core goal in one more sentence, you are not ready to commission software.
"Users" and "small businesses" are not specific enough. "Freelance copywriters who invoice more than 10 clients per month and need to track which invoices are overdue without switching between tools" is specific enough.
The development team will make hundreds of design decisions during the build. Every one of them will be made better if they understand the user precisely. Vague requirements produce software that does vague things poorly.
Question 2: What is the smallest version of this that is still worth building?
Before you commission the full vision, identify the minimum version. Not as a cost-saving exercise, but as a learning exercise.
The smallest viable version tests your core hypothesis: that this product solves this problem well enough that people will pay for it. Everything else is risk. Risk that the market does not want the feature you spent $40,000 building. Risk that users behave differently than you expected.
Write down the full vision. Then ask: what can I remove and still have something worth putting in front of users? Keep removing until you cannot remove any more without breaking the core value proposition. What remains is your first build.
Use our MVP planner to work through this exercise systematically.
Question 3: How will I measure whether this is working?
Before any code is written, define what success looks like. Not in broad strokes. In specific, measurable terms.
"The project is successful when 30% of users who sign up send their first invoice within 72 hours of creating their account." That is a measurable success criterion.
"The project is successful when the product works and users are happy" is not.
Success criteria serve two purposes: they tell you whether the product is working after launch, and they tell the development team what behaviour they are actually trying to enable. These two things are related.
Question 4: What happens when things go wrong?
Software breaks. Servers go down. Integrations fail. Users encounter errors. The question is not whether these things will happen but what happens when they do.
Before commissioning a build, define your support model:
- Who is responsible for monitoring the production system?
- What is the process when a user reports a critical bug?
- Who owns the codebase and the server infrastructure?
- What is the plan when the development team is unavailable?
A development team that has not thought about these questions is a red flag. A professional team will have standard answers: monitoring on all production systems, a defined response time for critical issues, full ownership of documentation and code handover.
Question 5: Who owns the code and data?
This seems obvious but is frequently not addressed clearly in contracts. You should own the code. You should own the data. The development team should have no ongoing leverage over your business because of intellectual property ambiguity.
Your contract should explicitly state:
- All code written for this project is owned by you
- All data generated by the application is your property
- The development team has no license to reuse the code in other projects without explicit written permission
A reputable development team will agree to this without hesitation. Any team that wants to retain ownership of code you paid to build is not a team worth working with.
Question 6: What is the plan for after launch?
Software is never done. After launch, you will encounter bugs, edge cases the testing did not cover, user behaviour you did not anticipate, and a backlog of features that accumulate from day one.
Before commissioning the initial build, understand:
- What does the retainer or maintenance arrangement look like post-launch?
- How are post-launch bug fixes handled and priced?
- What documentation will be provided to allow future developers to work on the codebase?
If the development team has not thought about post-launch, the project will stall the moment it goes live. Good teams build with maintenance in mind and deliver documented, clean code that another engineer can pick up and continue.
Question 7: Have you talked to customers who have the problem you are solving?
This is the most important question, and the one most founders have not answered when they commission their first software project.
Before spending money to build a solution, you should have evidence that the problem is real, that people experience it consistently, and that they would pay to have it solved. Not hypothetically. Actually.
If the answer is "we believe there is a problem" rather than "we have talked to 20 people who have this problem and three of them have pre-paid for our solution," you should do the customer research before the build, not after.
The cost of customer research is coffee and time. The cost of building the wrong thing is $50,000 and three months.
Starting the commissioning process
If you can answer these seven questions clearly, you are ready to commission software. Get an estimate from our team and we will tell you what the build scope looks like in time and money.
If you cannot answer all of them yet, that is useful information. We can help you work through the scoping process as part of a discovery phase before any development begins. This is not extra overhead. It is what makes the development phase go well.
And if you want to understand what the whole project is likely to cost before talking to anyone, start with our MVP cost calculator.