A software consultancy firm can help you launch your product by supplying what a new venture usually lacks: people who have designed, built and released software before, a settled way of getting from an idea to a working system, and a team that exists on the first day. It cannot supply customers, decide what the product should be, or care about it after launch as much as you do. Used for the first and not relied on for the second, a consultancy is often the quickest route to a first version in customers’ hands.
This applies equally to a start-up and to an established business launching a software product alongside what it already does.
What a software consultancy firm does
The word covers two kinds of company. Some only advise: they review plans, recommend technology and write reports. Others advise and then build. For a product launch you almost always want the second kind, or the advice ends in a document nobody is there to act on.
A firm that builds will usually work through these stages.
- Discovery. A short, paid piece of work to establish who the product is for, what the first version must do, what it will connect to and whether anything in the plan is technically uncertain. The output is a written scope that can be priced.
- Prototype. Screens or a rough working model that you can put in front of likely customers before the expensive part begins.
- Build. The first version, developed in stages, with working software for you to review at regular points.
- Launch. Hosting, security basics, monitoring, backups and the release itself.
- After launch. Fixes, changes prompted by what real users do, and routine upkeep.
Not every firm does all five, so ask which stages are covered and which are left to you.
When a consultancy is worth using
A consultancy earns its fee in these situations.
- There is no technical team yet. Recruiting one usually takes months. A consultancy can start once a scope is agreed, and you find out whether the product has a market before committing to permanent salaries.
- The product uses well-understood technology. Booking, ordering, payments, portals and reporting have been built many times. An experienced firm has made the common mistakes already, on someone else’s project.
- The budget is fixed. A defined first version can be built for a fixed price, which a newly hired team cannot offer.
- Software is not the main business. A manufacturer or a professional practice launching a digital product has no reason to become a software employer to do it.
It is a poor fit in other cases, and it is better to know that at the start.
- The technology is the product. If the value of the business lies in something technically new, that knowledge needs to sit inside the company. Our guide to hiring a CTO for a start-up covers that route.
- Nobody can yet say what the product does. A consultancy can sharpen an idea. It cannot find one for you, and time spent searching will be billed.
- You expect full-time development for years. At that point employing developers usually costs less. A consultancy can still build the first version and hand it to the team you hire later, provided the handover is planned for.
What stays with you
Three things should not be handed over, however capable the firm.
Knowledge of the customer. The consultancy knows software. You know the market, or you are the one who has to find out. Conversations with likely customers before and during the build are your job. A first version shaped by those conversations is called a minimum viable product, and our article on what a minimum viable product is explains how to decide what goes into it.
Decisions about priorities. The firm will advise on what is cheap, what is expensive and what is risky. Choosing what is built first is the product owner’s decision, and the product owner should be someone in your business with the authority to say no.
Ownership. The contract should assign the source code to you, and the code repository, hosting and domain names should be registered to your company from the first day, with the consultancy given access. Our answer on who owns the source code of bespoke software sets out what to check. This is a point on which to take legal advice before signing, because without a written assignment the code may not be yours.
How to choose a firm
Location, size and price are the things most buyers compare first. The following tell you more.
- Products that are still running. Ask to see something the firm launched a year or more ago, and speak to that client. A product that survived its first year says more than a portfolio of launch-day screenshots.
- The people. Ask who will do the work and whether you will speak to them directly.
- The questions they ask you. A firm that quotes quickly from a one-page description has not understood the product. A firm that asks awkward questions about users, data and what happens when things go wrong is doing its job.
- How the price is set. A fixed price suits a defined first version and puts the risk of an overrun on the supplier. Paying for time suits exploratory work. Our article on fixed price and time and materials compares the two.
- Fit with the technology. Firms specialise. CodeFirst, for example, builds new systems at a fixed price to an agreed scope, mostly on Microsoft technology, so a product planned around a very different technology would be better served elsewhere.
- The exit. Ask what you receive if you part company: code, documentation, credentials and a handover. A good firm answers this without discomfort.
Our list of questions to ask a software supplier covers these in more detail.
Plan for the months after launch
Launch day is the point at which you start learning what the product should have been. The first months with real users produce a list of changes that nobody could have predicted, and a budget spent entirely on the build leaves nothing to act on it.
Before the build starts, settle three things:
- A reserve for changes. Hold back part of the budget for the period straight after launch. How much depends on the product, but nothing is the wrong amount.
- Who looks after it. Software in use needs security updates, monitoring and someone to call when it fails. Agree whether the consultancy will provide this, on what terms, and for how long.
- The route to your own team. If the product succeeds you may want to bring development in-house. That is far easier when the code has been kept in a state another team could pick up: documented, with automated tests and a release process that does not depend on one person.
A first step
Write a one-page description of the product: who it is for, the handful of things the first version must do, what it must connect to, and your budget and date. Our project planning worksheet gives a structure for this. Send the same page to two or three firms and compare what comes back. The firm that replies with the best questions is usually a safer choice than the one that replies with the lowest price.