How to Commission Custom Software: A Buyer's Guide From First Idea to Launch

A step-by-step guide to commissioning custom software: defining the problem, budget, choosing a team, discovery, contracts, the build, launch and what comes after.

Key Takeaways

  • Start with the problem and the people who have it, not a feature list. The features follow from the problem; the reverse rarely works.
  • Check whether an existing product solves most of it. Custom software is worth it when the process is specific to you or gives you an advantage.
  • Set a budget range early. Scope, integrations and compliance drive the cost far more than the number of screens.
  • Choose a team by what you can verify: who will actually do the work, comparable past projects, references and contract terms.
  • Begin with a short paid discovery phase, then build in milestones, each with written acceptance criteria.
  • Plan for after launch from the start: maintenance, security updates and a clear handover if the team ever changes.

Commissioning custom software means paying a team to design and build an application for your specific needs, instead of buying an existing product. Done well, it gives you a system that fits how your business works and that you own. Done badly, it is one of the easier ways to spend a large budget without getting what you needed. This guide walks through the whole process in order, and links to our detailed guides for each step.

1. Define the problem, not the solution

The most useful document you can bring to a first meeting is not a specification. It is a clear description of:

  • who has the problem (customers, staff, partners) and how many of them;
  • what they do today, including the spreadsheets, emails and manual steps;
  • what goes wrong: lost time, errors, missed revenue, compliance risk;
  • what success looks like in a year, in terms you could measure.

Feature lists written before this work tend to describe the current process with a new interface. A good team will help turn the problem into a scope, and will push back when a requested feature doesn't serve it.

2. Decide between building and buying

Before commissioning anything, check honestly whether an existing product (a SaaS tool, an ERP or CRM module, a no-code platform) covers most of the need. Buying is usually cheaper and faster when your process is standard.

Custom software makes sense when:

  • the process is specific to your business, or is what sets you apart;
  • you need to integrate several systems that no single product connects well;
  • you have regulatory, security or data-location requirements that off-the-shelf tools don't meet;
  • licence costs for the products you would need are growing faster than your business.

A middle path is common: buy for the standard parts, build the piece that is specific to you.

3. Set a budget range

You don't need an exact figure, but you need a range, because it shapes every later decision. The cost of a custom application depends mainly on the complexity of the business rules, the number of integrations, the user roles and permissions, and any compliance requirements, much more than on the number of screens. Our guide on how much a custom web application costs breaks down what drives the price, with published market ranges.

Remember the costs after launch too: hosting, maintenance and security updates continue for as long as the software is in use.

4. Choose who will build it

The main options are an agency or studio, a freelancer, or your own in-house team. Each fits different situations; our comparison of agency, freelancer and in-house teams covers the trade-offs in cost, continuity and control.

Whoever you consider, judge them on what you can check:

  • Who will actually do the work, and how senior they are.
  • Comparable projects, with details you can verify, and a conversation with a past client.
  • Contract terms: code ownership, accounts in your name, milestones and handover.

Our list of questions to ask before you sign turns this into a practical checklist.

5. Start with discovery

A paid discovery phase comes before the main build. In a few weeks, the team studies the users and workflows, the integrations and data, and the technical risks, then produces a written plan: scope for a first release, architecture, estimate and timeline. Public-sector digital teams work the same way; the UK government's service manual describes a discovery phase to understand the problem before deciding whether to build at all.

Discovery protects you in two ways. The estimate for the build is based on facts rather than a first conversation, and, if you own the written plan, you can take it to any team.

6. Agree a contract that protects you

The contract model decides how the price is set and who carries the risk of change. For most custom applications, a milestone-based contract is the best balance; our guide on fixed price, time and materials or milestones compares the three.

Whatever the model, check that the contract covers:

  • a written assignment of IP rights to you (under the French Code de la propriété intellectuelle, paying is not enough: see who owns the code);
  • repositories and hosting in your accounts from the first day;
  • acceptance criteria for each milestone and a written change-request process;
  • a data processing agreement under GDPR Article 28 if personal data is involved;
  • termination and handover: what you receive, and the help owed to a new team.

7. During the build: stay close to the work

Good projects are visible. Expect:

  • regular demos of working software, every one or two weeks, not slide decks;
  • access to the repository and the task tracker, so you can see progress between demos;
  • a named person accountable for delivery on the supplier's side, and a decision-maker on yours who can answer questions quickly;
  • automated tests on the critical paths, so that new work doesn't break what already works.

The most common cause of delay is not technical. It is decisions that wait days for an answer. Make sure someone on your side has the time and authority to make them.

8. Launch, then plan for the long run

A launch is the start of the product's life, not the end of the project. Before going live, agree:

  • monitoring and alerts, and who responds to an incident and how fast;
  • backups, and a tested restore;
  • who maintains the system: framework and dependency updates, security patches and small improvements. Vulnerabilities are published every week, and a production application needs someone watching for them (the OWASP Top 10 lists the most common risks);
  • documentation good enough for another team to take over.

That last point is your insurance. If the relationship ever ends, a clean handover is what keeps your product running; our handover checklist lists what it should include.

When something has already gone wrong

Many buyers arrive at this guide part-way through a difficult project. If the application is unstable, the supplier has disappeared or nobody is sure what state the code is in, start with an independent view: our guides on what a technical audit includes and whether to rescue or rewrite explain how to get an objective picture before deciding what to do.

Frequently asked questions

How long does it take to commission custom software? It depends on the size of the product. Discovery typically takes a few weeks, and a first release of a business application usually takes several months. Be wary of firm timelines given before anyone has studied the problem.

Do I need a technical person on my side? It helps, but it is not essential. You need someone who understands the business problem and can make decisions. A good supplier explains technical choices in plain language and puts the important ones in writing.

Should I write a detailed specification first? Write down the problem, the users and what success looks like. A detailed specification is better produced with the team during discovery, when it can be tested against technical reality.

What if I want to change supplier later? That should be possible at any time without losing anything, provided the code and accounts are in your name and the IP has been assigned to you. Check this in the contract before you sign, not when you need it.

At FNB Solutions, we work this way: an optional paid discovery phase whose written plan you own, delivery by milestone with written acceptance criteria, code and IP owned by the client from day one, and maintenance or a structured handover after launch. Our process and contract terms are public. If you are planning a project, tell us about it.

Sources

All insights →