Search behaviour in this market is unusually specific. People are not looking for a technology partner in the abstract; they are looking for bespoke software for a small business, for a workforce scheduling problem, or for a product a founder intends to sell as a subscription. Those are three separate purchases, made by buyers who mostly have no in-house engineering team and no previous supplier to compare against.
That inexperience is the risk, not the budget. The notes below are written for a first-time buyer of custom software, alongside the verified supplier profiles on our software development directory.
Most bespoke software briefs in Nottingham are really process briefs
The typical request describes a system, but the actual problem is a process held together by spreadsheets, shared inboxes and one long-serving employee who remembers the exceptions. Automating that process as it currently stands produces expensive software that encodes the mess.
Before commissioning anything, write down the process as it truly runs, including the workarounds. Then mark which steps exist because a customer needs them, which exist because a regulator or an insurer requires them, and which exist because a system could not do something years ago. The third group is where the savings are, and a good supplier will push you toward that list rather than quoting the workflow you described.
A supplier who accepts your specification without challenge is not being accommodating. They are pricing what you asked for so that changes become chargeable later.
When a packaged product is the right answer
Honest suppliers will tell you that much of what small firms commission already exists as a subscription product. Accounting, customer records, ticketing, stock control, basic scheduling and document management are crowded categories where building from scratch is rarely justified.
Custom work earns its cost in three situations: when the process is genuinely how you compete, when several packaged systems must exchange data and none of them will, or when licensing per user has become more expensive than ownership at your scale. If none of those applies, ask the supplier to configure and connect products you can buy rather than write something new, and expect that engagement to be smaller and shorter.
Ask every candidate directly what they would recommend you not build. The answer tells you whether you are talking to an adviser or a shop.
Scheduling, field work and the systems people actually use
A large share of local demand involves rotas, shift patterns, engineers in vans, agency staff, site attendance and compliance records. These projects fail for a predictable reason: the people who specify them sit in an office and the people who use them are standing in a car park with one hand free.
Insist that the supplier spends time with the end users before design, and that the first release is tested by the least enthusiastic member of staff rather than the most cooperative one. Ask how the system behaves with no signal, whether data entered offline reconciles cleanly, and what happens when someone's shift is changed after they have already started it. Payroll and working time obligations sit underneath all of this, so agree who is accountable for the rules being right, and get that in the contract.
Buying from a small supplier without creating a single point of failure
The supplier pool here is mostly small firms and owner-managed studios. That is an advantage: you get the attention of experienced people rather than a junior team supervised from a distance. It also means the business you are hiring may depend on two or three individuals who are being recruited by larger employers every month.
Price that risk rather than avoiding it. Ask how many people could maintain your system if the lead developer left tomorrow, and ask the supplier to demonstrate it by having a second engineer walk you through a deployment. Require that the repository is mirrored into an account your business owns, that hosting and domain registrations are in your name, and that documentation is committed as work proceeds rather than promised at the end.
Check the supplier's filed accounts and how long they have traded. It is a five minute exercise and it occasionally changes a decision.
Founders building a product rather than a tool
Building software you intend to sell is a different commercial relationship from building a tool you intend to use. Investors and acquirers will inspect the ownership chain, so intellectual property assignment must cover employees, contractors and any subcontractor the supplier engages, and any reuse of the supplier's own framework needs a perpetual, transferable licence in writing.
Keep the first release deliberately small. A narrow product with real users beats a broad one with none, and it preserves the budget for the changes those users will demand. Agree from the outset how you will eventually bring development in-house, because a product company that permanently rents its engineering has a valuation problem as well as a technical one.
What the quote should separate
Ask for four figures rather than one: discovery, build, the cost of running the system for a year, and the cost of support and small changes. The last two are what persist, and they are missing from most comparisons.
Fixed price is reasonable where the scope is written and stable, which is common for integrations and replacements of a known process. For anything discovery-led, a capped time and materials arrangement with weekly reporting of spend against the cap is more honest and usually cheaper than a fixed price defended through change control. Either way, insist on a transition clause with paid handover hours, so that leaving is possible without a rebuild.
Comparing suppliers without burning a quarter
Three or four suppliers is the right number. Give each the same written brief describing the business outcome and the constraints, the same deadline, and the same access to the staff who do the work today. Score the responses on assumptions made visible and risks named, not on the polish of the document, and meet the developer who would be assigned rather than only the person who sells.
Take one reference from a finished project and ask that client what handover was like. Then commission a small paid piece of real work before the main award, delivered into a working environment with documentation your own staff can follow.
When you are ready to collect comparable quotes, request proposals on one brief. If the requirement is a customer application rather than an internal system, start from the mobile app development listings, and if it is a website or online store, compare web development companies instead. Buyers widening the search often review suppliers in Leicester, Sheffield or Birmingham.
Questions to ask before hiring a software company in Nottingham
How much detail do I need before asking for a price?
Enough to describe the problem, the people affected, the systems already in use and the outcome you want. You do not need a specification. A supplier who requires one before quoting is telling you they will not help you write it, which for a first-time buyer is the part that matters most.
Is a fixed price safer for a small business?
It is predictable, not safe. Fixed prices include a risk premium and are defended through change control, so they suit stable scope. For a first system, a capped arrangement with a small first release gives you a working thing sooner and an exit if the relationship is wrong.
What happens if my supplier stops trading?
If the repository is mirrored into your account, hosting is in your name and the documentation is current, you hire someone else and lose weeks. If none of that is true, you lose the system. Arrange it at the start, when it costs nothing.
Should I hire a developer instead?
One developer alone carries the same key-person risk you were trying to avoid, plus recruitment and management overhead. Hiring makes sense once the software is central to how the business earns money and there is enough work to keep two or more people productive.