Technology
Build or buy: the questions that actually decide it
Off-the-shelf software wins more often than vendors of custom software like to admit. Buy when your process is ordinary and the product is mature — accounting, payroll, email. Build when the process is the thing that differentiates you, when no product fits without changing how you work, or when per-seat licensing has quietly become your third largest cost. The mistake is treating it as one decision. Most organisations should buy the commodity layer and build only the thin slice that is genuinely theirs, with clean integration between the two.
AI and automation
Why most AI pilots never reach production
The demo works because someone curated the inputs. Production fails because real documents are scanned at an angle, real customers ask two questions at once, and nobody defined what the system should do when it is unsure. Before building anything, settle three things: what the assistant may act on versus only draft, what happens on low confidence, and how a human takes over mid-conversation without the customer repeating themselves. Then measure containment and escalation, not novelty. An assistant that handles forty per cent of enquiries cleanly is worth far more than one that attempts everything badly.
Integration
The integration layer decides whether your systems help
Buying good software does not give you a good operation. If the CRM, the accounting package and the storefront each hold their own version of a customer, staff spend the day reconciling instead of selling. Decide which system is the source of truth for each entity — customer, product, order, invoice — and write it down. Then connect through documented, versioned APIs with retry and failure handling, rather than nightly exports nobody monitors. The test is simple: when a record changes in one place, how long until every other system agrees, and who finds out if it never does?
Cybersecurity
The security work that actually prevents incidents
Most breaches we are called in after involved nothing sophisticated: an unpatched plugin, a shared admin password, a database reachable from the open internet, or a backup nobody had ever restored. Before anyone sells you monitoring, do the unglamorous work. Enforce multi-factor authentication. Remove accounts belonging to people who left. Patch on a schedule. Restrict access to what each role actually needs. Restore a backup this quarter to prove it works. Penetration testing is valuable, but it is worth far more once the basics are in place than before.
Delivery
A scope document is a risk document
The purpose of a written scope is not to describe the happy path. It is to record the decisions that will be expensive to change later, and to name the assumptions that would break the programme if they turn out to be wrong. A good scope says what is excluded as clearly as what is included, names who supplies what and by when, and states what happens to the price and the date if a dependency slips. If your contractor's scope reads like marketing copy, you do not have a scope yet.
Technology
Owning what you paid to have built
Ask three questions before signing any software contract. Whose account is the code repository under? Whose account is the hosting, the domain and the database under? And what, in writing, transfers to you at the end? If the answer to the first two is 'the vendor's', you have not bought software, you have rented it — and the price of leaving is a rebuild. Ownership costs nothing to arrange at the start and is close to impossible to retrofit once a relationship has soured.
