A Liverpool brief often carries somebody else's rules
An unusual share of development projects in this city are paid for with money that comes with conditions attached. Regional growth funding, university and health service budgets, port and freight sector grants, innovation programmes and charitable funds all sit behind briefs that would otherwise look like ordinary commercial work. When that is true, the constraints on the project are set before any supplier is chosen, and the buyer who discovers them late loses months.
Funded work typically requires a competitive quote process with an auditable trail, a defined outcome you will be measured against, spend within a fixed period that does not care about your delivery reality, and evidence that the asset created belongs to the funded organisation. None of that is unreasonable. All of it changes how you write a brief, how many suppliers you approach and what you must keep on file. If any part of your budget carries conditions, read them before you write the specification, not after you have chosen a partner.
Agency or software house, and why the distinction decides the outcome
The local supplier market grew substantially out of a creative and digital cluster, which means many firms presenting as software developers are excellent agencies whose core craft is brand, marketing sites and content driven builds. That is genuinely valuable work and it is not the same discipline as building a system that people use for eight hours a day to run an operation.
The difference is not talent, it is what each firm is organised to do. An agency is set up around campaigns and launches, with project teams that form and dissolve. A software house is set up around long lived systems, with version control discipline, automated testing, staging environments, release processes and people who expect to maintain what they wrote in three years. Ask a candidate what their oldest continuously maintained client system is and who maintains it now. That one question separates the two models faster than any portfolio review.
Evidence your funder and your finance team will ask for
If the money is conditional, build the evidence as you go rather than reconstructing it later. Keep the written brief that went to every supplier and the responses you received, including the ones you rejected and why. Keep the scoring rationale if you used one. Keep the signed contract showing ownership of the resulting asset, because a funder may treat software as a capital asset they have part financed and will want to see it belongs to you.
Keep milestone evidence that ties spend to delivery, and agree with the supplier upfront that invoices will be structured to match your reporting periods. This is a small administrative ask at the start and an expensive renegotiation in month six. Where outcomes have to be reported, such as users served or processes digitised, make sure the system itself captures the measure. Retrofitting reporting for a funder is one of the more avoidable change requests in this market.
Ownership, exit and the code you leave with
Intellectual property should transfer on payment and the clause should name source code, design assets, infrastructure configuration and documentation rather than just referring to deliverables. Confirm the position on reusable components, because most suppliers build on internal libraries and you need a perpetual right to use and modify anything embedded in your system.
Then plan for leaving. Not because you expect the relationship to fail, but because an exit clause negotiated calmly is worth more than any warranty. Specify a handover package: repository access, deployment instructions, environment configuration, credentials transfer, a data dictionary and a runbook. Specify a notice period and a day rate for transition support. If the supplier holds cloud accounts, domains or third party subscriptions on your behalf, write down how those move. Buyers who commissioned software through a grant and then could not access their own hosting are common enough in every market to be worth designing against.
Maintenance is the contract that actually matters
A build takes months and the support arrangement lasts for as long as the system does, yet buyers negotiate the first in detail and the second in a sentence. Agree what counts as a defect and what counts as a change, since the boundary is where most disputes live. Agree response expectations by severity, availability outside office hours, and whether the supplier monitors the system or waits for you to report a problem.
Agree who pays for dependency upgrades, security patches and platform changes forced by third parties. This work is unglamorous, continuous and unavoidable, and a contract silent on it produces an annual argument. If your organisation has internal technical capacity, consider whether you want the supplier to hand over maintenance entirely after a stabilisation period, and price that transition into the original agreement rather than negotiating it under pressure.
Comparing software companies in Liverpool without a spreadsheet full of noise
Three or four suppliers briefed identically in writing will give you a real comparison. More than that produces volume rather than insight and burns goodwill in a market small enough that suppliers talk to each other. Ask each for the same artefact: their understanding of the scope, explicit exclusions, named team, what they need from you, and the largest risk they see.
Weight two things heavily. First, whether they have built something operationally similar, because domain familiarity produces accurate estimates and its absence produces optimistic ones. Second, whether they are still supporting what they built for previous clients, which you verify by asking those clients rather than by reading a case study. Where the requirement spans public facing channels as well as internal systems, splitting the work is usually better value than stretching one firm, whether that means web development firms working in the city for the customer layer or mobile app developers for anything used away from a desk.
The full set of verified suppliers across markets is listed in the software development company directory, and where a specialised requirement outruns local capacity, neighbouring pools such as Manchester and Leeds are close enough for regular on site work. When your brief and your funding conditions are both written down, send the same document to several verified suppliers so that the quotes you compare answer one question rather than several.