Example IT scenarios, not past client work

A 10-person SaaS startup

Imagine a software team that has grown from one founder’s laptop. Accounts were opened by whoever needed them first, passwords are shared in chat, nobody is sure who has admin rights, and a customer has started asking how company data is protected.

How we would approach it

• List every account, who owns it and who can administer it, then make sure each has two admins
• Move email to the company domain with multi-factor authentication
• Replace shared passwords with a team password manager
• Encrypt laptops and switch on updates and screen lock
• Back up source code and cloud data, and test a restore
• Write a one-page note of how everything is set up, so customer questions have a ready answer

What the team would have afterwards

Every account has an ownerNo shared passwordsA restore that has been tested

A small clinic

Imagine a clinic with a handful of staff, one shared front-desk login, appointment and billing software, and patient files on a single office PC with no backup.

How we would approach it

• Give each person their own login instead of one shared front-desk account
• Encrypt devices and keep them updated
• Back up records away from the clinic, and test a restore
• Put guests and staff on separate Wi-Fi, behind a properly configured firewall
• Turn on multi-factor sign-in for email and cloud software
• Write a short checklist for staff joining and leaving

What the clinic would have afterwards

Individual loginsBackups kept off-siteA written leaver checklist

Rules on patient records are for the clinic and its advisers to decide. We make no healthcare-specific certification claims, and we would not say a setup makes a clinic compliant.

A D2C brand with a remote team

Imagine a direct-to-consumer brand with a dozen people in different cities, plus freelancers and an agency. Work is spread across many online tools, logins live in a spreadsheet, and most people use their own laptops.

How we would approach it

• List every tool with its owner, its cost and its renewal date
• Replace the spreadsheet of logins with a password manager and multi-factor sign-in
• Give freelancers and agencies only the access they need, and remove it when the work ends
• Set a baseline for personal laptops: encryption, updates and screen lock
• Check subscriptions for seats nobody uses
• Back up the files and exports the business cannot afford to lose

What the team would have afterwards

One list of tools and ownersAccess that ends when the work doesA review of unused subscriptions

An office with an ageing firewall

Imagine a 25-person office whose firewall was set up years ago. Nobody has the rules written down, guests share the staff network, and remote staff connect in a way nobody is sure is still safe.

How we would approach it

• Review the current rules, open ports and exposed services, and list what to fix first
• Write the rules and settings down, so the setup no longer lives in one person’s head
• Put guests and devices on their own networks, away from staff computers
• Replace ad hoc remote access with a VPN and two-step sign-in
• Plan the cut-over outside business hours, with a way back if something does not work

What the office would have afterwards

Rules written downGuests kept separateRemote access with sign-in checks

A business with two sites

Imagine a business with two small offices on separate internet lines. Files are emailed between them, each site has its own Wi-Fi set up differently, and staff cannot reach the same systems from both.

How we would approach it

• Map both sites: devices, internet lines and what each team needs to reach
• Plan one addressing scheme and one way of managing Wi-Fi across both
• Connect the sites with an encrypted VPN and limit access to what each person needs
• Add basic monitoring, so outages show up as alerts that are reviewed during support hours
• Write the plan down and hand it over

What the business would have afterwards

One network planBoth sites connectedUptime alerts

Replacing spreadsheets with an internal tool

Imagine a distribution business that tracks orders and deliveries in several shared spreadsheets. Versions drift, nobody is sure which file is current, and a new hire needs weeks to learn the system.

How we would approach it

• Sit down with the people who use the spreadsheets and write down what the tool must do
• Agree the scope, the platform and the price in writing before any building starts
• Build it in stages, with the team testing each stage
• Move the existing data across and run old and new side by side for a short time
• Deploy it, hand over the documentation, and agree how support will work

What the business would have afterwards

A written scope firstBuilt and tested in stagesDocumented handover