Two very different software buying processes run side by side in Glasgow
The software supplier market here serves two customer types with almost nothing in common. One is a private business that can decide on a Tuesday and sign on a Friday. The other is a public body, a health board, a university or a charity funded through grant cycles, where the decision is governed by procurement rules, a scored evaluation and a documented audit trail.
Software firms adapt to whichever they see most. A studio built around commercial product work will find a formal tender process slow and will sometimes decline to bid. A studio built around public work will produce polished framework responses and may struggle with a client who changes direction mid sprint. Neither is better. Buying from the wrong one produces friction for a year.
So the first filter is not technology. It is whether the supplier's normal customer resembles you, and the quickest way to find out is to ask how their last three engagements were awarded.
If you are buying under procurement rules
Where competition is regulated, the specification you publish is the contract you will get. Suppliers price what is written, scored against criteria they can see, and cannot rescue a poorly framed requirement later without a change control conversation that may not be permitted at all.
Three practical consequences follow. Write outcomes rather than solutions, or you will receive exactly the architecture you guessed at rather than the one that fits. Weight the quality criteria heavily enough that price does not decide by default, and publish how the weighting works. And make the response format constrain length, because a scoring panel reading long documents rewards writing quality rather than delivery capability.
Run a supplier engagement session before publishing. It is permitted in most regimes, it costs a morning, and it routinely surfaces a requirement that would have made the whole exercise unbuildable as written.
If you are buying commercially, keep the discipline anyway
Private buyers often treat the absence of rules as an absence of process, then find themselves comparing three proposals written to three different structures. Borrow the useful half of the formal approach: a single brief, a fixed response template, a scoring sheet completed independently by each person on your side before you discuss, and a written record of why the winner won.
That last document is unglamorous and matters more than it sounds. When the engagement hits trouble in month five, the record of what you actually valued keeps the conversation focused on the original objective instead of on personalities.
Mobile briefs deserve their own conversation
A large share of the demand reaching Glasgow software suppliers is for applications people carry, driven by field workforces, patient and student facing services, ticketing and transport, and consumer products. These briefs carry obligations that a browser based system does not, and they are routinely missed at proposal stage.
- Store accounts must belong to your organisation. Developer programme enrolment, the legal entity on the listing, the signing certificates and the analytics all need to sit with you, not with a supplier who registered them for convenience during the first build.
- Review policies change and rejections happen. Ask who handles the appeal, how quickly, and whether that work is inside the quoted price.
- Devices and operating systems move on a schedule you do not control. An application without a maintenance arrangement will break, and the cost of restoring it later usually exceeds the cost of keeping it current.
- Offline behaviour, background location and push notifications sound like features and behave like architecture. If your workers operate underground, in rural areas or inside steel framed buildings, say so in the brief.
Where a project is genuinely mobile first, weigh mobile specialists against full stack studios rather than assuming a single team is equally strong at both, and compare that against the broader field in our software development company directory.
Accessibility is a requirement, not a refinement
For public bodies and anyone serving them, digital accessibility carries a legal obligation and a published statement that must be accurate. Even outside that scope, a large employer procuring a system will increasingly ask for evidence.
Put it in the specification rather than the wish list. Name the conformance target, WCAG 2.1 at the level your policy requires, require an audit by someone who did not build the product, and require remediation of the findings to be inside the delivery price rather than a follow on quote. Ask whether the supplier has run testing with assistive technology users rather than only automated checks, since automated tooling catches a minority of real barriers.
The same discipline applies to language and content design. A form that passes a technical audit and still cannot be completed by the people it was built for has failed at greater expense.
Commercial models and the questions that reveal the truth
Lump sum pricing suits a bounded replacement where behaviour is known and documented. Periodic billing against an agreed team suits discovery led product work, provided you hold a genuine stopping point at the end of each cycle. A ceiling price with shared savings works well where trust exists but budget approval does not flex.
Whichever shape you choose, the useful questions are the same. Which named people will be on this, what else are they committed to, and what is the notice period if one of them leaves? How much of the delivery is subcontracted, and to whom? What has gone wrong on a recent project, and what changed afterwards? A supplier who answers the last question with a genuine failure and a specific process change is worth more than one with an unblemished record.
Contract points to settle before the kickoff meeting
Assign ownership of the work product outright, including designs, content and configuration, not only compiled software. Require infrastructure, repositories and store listings to be registered to you from the outset. Define the handover package and price transition support in advance so that ending the relationship is an administrative act rather than a negotiation.
For anything holding personal records, agree where processing occurs, who holds production access, how that access is logged and reviewed, and what happens to copies of live data used for testing. Ask whether the supplier can evidence an information security regime, whether that is ISO 27001 certification or a documented equivalent your own auditors will accept. Sub processors should be listed and changes notified, not discovered.
Turning a Glasgow shortlist into a decision
Ask for references you choose rather than references offered, ideally a client whose engagement ended. Ask that client one question: what would you do differently if you were buying this again? The answers are consistently more useful than a reference call about how pleasant everyone was.
Keep neighbouring disciplines in separate briefs so they receive proper attention. Interface and content work can be compared against dedicated design studios, and discoverability belongs with search specialists rather than being appended to an engineering scope where it will be dropped first. Once the brief is stable, ask several suppliers to respond to the same document and hold every one of them to the same structure.