Bespoke Software in Cardiff Is Bought Under Two Different Rulebooks
Buyers here fall into two camps that barely resemble each other. One camp is public: councils, health boards, universities, arms length bodies, and the organisations funded by them. The other is private: insurers and financial back office operations, media producers, manufacturers, and a steady stream of owner managed businesses replacing a system that has outgrown a spreadsheet. The same handful of software development firms serve both, which is why a proposal written for one camp so often lands badly in the other.
Work out which rulebook applies to you before you write a requirement. Public and publicly funded work carries procurement process, language duties, accessibility duties, audit rights and publication expectations, and those obligations shape the architecture rather than merely the paperwork. Private work carries none of them by default, and paying for that governance when nobody requires it is a straightforward waste. The local term for what both camps are buying is bespoke software, and the firms that use that phrase are usually the ones that build to order rather than reselling a platform with a skin on it.
Welsh Language Duties Reach Into the Data Model
If the software will be used by the public and your organisation is subject to the language standards, bilingual provision is not a translation task bolted on at the end. Treating it that way is the single most common and most expensive mistake in this market. Equal treatment means the Welsh interface cannot be a degraded version of the English one: same functionality, same prominence, same launch date.
That has concrete engineering consequences. Text expands, so fixed width components and character limits designed against English copy break. Content needs to be stored per language rather than flattened into a single field, which affects the schema, the search index, sorting, and any report that groups by a text value. Notifications, receipts, error messages, and letters generated by the system all need a language preference attached to the record rather than to the browser session. User generated content needs a policy for what happens when only one language version exists. Ask candidates how they have handled bilingual delivery before, ask to see a system running in both languages, and put the translation workflow in the plan with a named owner, because unowned translation is what turns a launch date into a slip.
Accessibility Is a Duty, Not a Quality Score
Public sector websites and applications must meet the accessibility regulations, which means conformance with WCAG 2.1 at the AA level and a published accessibility statement that is honest about anything not yet compliant. Retrofitting that into a finished product costs far more than designing to it, because the failures are usually structural: components that cannot be operated by keyboard, forms whose errors are invisible to a screen reader, colour choices baked into a design system, content authored as images.
Make it a contractual acceptance criterion rather than an aspiration. Ask who on the supplier's team is responsible for accessibility, whether they test with assistive technology or only with an automated scanner, and whether they will fund remediation of anything found in an independent audit before final payment. Ask how the content editors will be prevented from breaking compliance after launch, since most regressions come from the authoring side rather than the build. Private buyers should note that customers and staff with access needs exist regardless of duty, and that the same discipline improves the product for everyone using it on a poor connection or a small screen.
Public Funding Follows the Code Into the Repository
Where a project is grant funded or supported by a public programme, read the funding conditions before the technical requirement. They frequently carry obligations that suppliers do not expect: rights for the funder to reuse outputs, preferences or requirements for open source licensing, record retention for audit, restrictions on how outputs may be commercialised, and reporting against stated outcomes rather than delivered features.
These conditions change what you can agree with a development firm. A supplier that intends to retain its framework and license it back to you may be incompatible with a requirement to publish outputs. Settle intellectual property in the first conversation: assignment of the code written for you, binding on individual developers and subcontractors, plus a perpetual transferable licence to anything the supplier brings with it. Ask for an inventory of open source components with their licences before final payment, because reciprocal licences create obligations that a funder condition can turn into a genuine conflict.
Regulated Back Office Work Has Its Own Checklist
The financial services operations clustered around Cardiff buy software under outsourcing rules that most suppliers meet for the first time when they meet you. If the system touches regulated activity, your firm remains accountable for it, which means the contract needs audit rights, defined service levels, incident reporting timelines, restrictions on subcontracting, notification of any change of control at the supplier, and a documented exit plan that could actually be executed.
Operational resilience thinking helps here even outside regulated work. Ask what happens if the supplier fails: who holds the deployment credentials, how long would it take a successor to stand the software up from the repository alone, and has anyone ever tested that. Ask about data location, retention and deletion, about how support staff access production, and about recognised information security certification such as ISO 27001, reading the scope on the certificate rather than the claim in the deck.
Questions That Separate a Cardiff Shortlist
Send every candidate the same document: the business problem in plain language, the systems that must integrate, whether language and accessibility duties apply, the funding or regulatory conditions attached, the commercial model you want, and what support after launch should look like. Then ask three things that are hard to answer from a template. Who specifically will write this, and what else are they committed to. What would you build first, and why that. What part of this brief do you think we have got wrong.
If the work is mainly a public facing site rather than a software system, compare against interface and site specialists and web engineering firms, whose pricing for that shape of work is lower. Verified profiles for software companies sit on Edvido alongside search teams and communications agencies working in the same city, and buyers willing to look further along the corridor can also review suppliers across the estuary. When the brief is ready, send it to several firms in one pass so the answers come back comparable.