In Bath, an IT company and a software company are two different purchases
Search behaviour here is revealing. People looking for software suppliers in this city search for managed IT, IT support and app development in roughly the same breath, and the firms that appear are not interchangeable. A managed service provider keeps your laptops, networks, mailboxes and backups running. A development firm writes something that did not exist before. A few outfits do both, usually with one side much stronger than the other.
Getting this wrong wastes a month. If you ask a support-led provider to build a bespoke booking system, you may get a configured off-the-shelf tool and a licence bill. If you ask a small product studio to take over your helpdesk, they will either decline or subcontract it. Before you contact anyone, write one sentence describing whether you need something kept running or something created, and use that sentence to filter.
Thin local supply is a fact, not a problem
This is a small city with a strong professional services base, two universities feeding graduates into the local economy, and a technology scene that is real but compact. You will not find dozens of independent software firms inside the city boundary. That changes how a sensible shortlist is built.
Treat location as a preference with a price, not a requirement. Ask yourself what proximity actually buys: workshops in a room rather than on a call, someone who can sit with your operations staff for a day, a supplier your finance director can visit. Those are legitimate reasons to pay a premium for someone nearby. If none of them apply to your project, restricting the search to one postcode simply shrinks the pool of people who have solved your problem before.
How deep is the bench behind the person selling to you
Small firms are often excellent and occasionally fragile. The question that matters is what happens when the one senior engineer who knows your system takes a long holiday, gets ill, or resigns.
Ask directly how many permanent software engineers the firm employs, how many of them are on your project, and whether any of the proposed team are contractors brought in for this engagement. There is nothing wrong with contractors, but you should know, because their notice period and their loyalty are different. Ask whether a second person will review every change before it reaches production. A firm that cannot answer yes is running on trust rather than process, and trust does not survive an absence.
Discovery is where a small supplier proves itself
Buyers often try to skip the paid discovery phase to save money, then spend triple that amount on rework. A short, chargeable discovery engagement gives you a specification, a technical approach, a risk list and a realistic estimate. Crucially, it gives you all of that while you are still free to walk away.
Structure it so the output belongs to you. If the discovery produces documents you can hand to a different supplier, you have bought genuine optionality and the incumbent knows it. Suppliers who refuse to separate discovery from delivery are protecting a commercial position, not your project.
Commercial models, and why the cheapest hour is rarely the cheapest project
You will be offered three shapes. A fixed price for a defined scope, which suits replacements of something you already run. Time and materials, which suits anything genuinely new. A monthly retainer for ongoing improvement, which suits a product that is now part of how the business operates.
Comparing hourly figures across firms is close to meaningless, because the unit of work differs. An experienced team may bill more per hour and spend a quarter of the hours. What you should compare instead is the estimate for the same defined outcome, the assumptions each supplier attached to it, and how each one proposes to handle the assumptions that turn out to be wrong. Ask every candidate what they would do if the estimate were exceeded by a third, and take the honest answer over the confident one.
Owning the result when the team is small
Insist on three things in writing. The code lives in a repository your organisation owns, from the first commit, not handed over at the end. Intellectual property is assigned to you explicitly, covering design assets and infrastructure configuration as well as source code. Deployment is documented well enough that a competent third party could rebuild the environment without a conversation.
These clauses cost nothing to agree at the start and are almost impossible to obtain once a relationship has broken down. They also make it far easier to bring a second supplier alongside the first when the workload grows, which is a common outcome for a project that succeeds.
What to ask before the second meeting
- Show me something you built that is still running, and tell me who maintains it now.
- Which parts of this project would you not do yourselves, and who would you use?
- What is your process when we disagree about whether something is a defect or a change?
- How do you handle support outside office hours, and is that included or extra?
- If we wanted to take the work in-house in a year, what would that transition look like?
The last question is the most useful one. A supplier who has clearly thought about a graceful exit is a supplier who expects to earn the renewal rather than rely on lock-in.
Comparing software companies in Bath and shortlisting sensibly
Pick three firms, give them the same one-page brief, and ask for the same response structure: approach, assumptions, team, timeline shape and commercial model. Read the assumptions first. That section tells you who actually understood the problem, and it is the part nobody polishes.
You can review verified software companies in Bath, compare them against the wider list of software development firms, and ask for matched proposals through our offer request form. If the brief also involves a public-facing site, search visibility or interface work, look at web design agencies, SEO agencies and UX and UI design agencies covering the same area.