Workstations and a service desk for everyone else
Hardware, setup, requests and onboarding, mainly for people outside the technical team. Developers usually keep their own machines and that is exactly right.
In every other company the argument is "you have nobody to handle this". Here it does not hold, because you have twenty people who can set up a server better than many an administrator. So the question is a different one, and it is the only one this page answers: which tasks are worth handing over, given what an hour of your engineer costs.
The scope is deliberately narrow. We do not write code, we do not run your CI/CD and we do not touch product infrastructure or client environments, because that belongs to your team and nobody from outside will do it better. We take the company's own IT: workstations, accounts, licences, backups and the hardware standing in the office.
A senior spending Friday afternoon setting up a laptop for a new recruiter costs the company more than a whole month of having that area handled from outside. And usually does it worse, because he does it once a quarter.
Hardware, accounts, access and the whole first-day ritual, then the same in reverse when someone leaves. In a company with contractor turnover this comes round every few weeks and is the first thing forgotten when the team is chasing a release.
Sales, recruitment, accounts and the board. These people will not ask a developer about a stalling spreadsheet, because they can see they are interrupting, so they live with the problem for weeks. An outside service desk works better here than a colleague across the room, because that is what it is for.
Tools bought on a card by individual teams, subscriptions left behind by people who have gone, and renewals nobody remembers. In a software house this mess grows faster than anywhere else, because every team adds its own set of tools.
What we do not touch and do not want to: repositories, deployment pipelines, the product cloud and the environments you maintain for clients. That is your competence and your advantage. The boundary goes into the contract so there is no doubt who answers for what during an outage, much as with server administration.
The question comes back every time the bill for a longer training run arrives. Before you cost out your own hardware, it is worth checking the thing most teams skip.
At a large provider an H100 works out at around twelve dollars per GPU-hour, at providers specialising in GPUs between two and four, and an A100 can drop below a dollar and a half. That is a several-fold difference for the same chip, so the first optimisation costs an afternoon of comparison rather than an investment.
A one-year reservation takes off roughly a third, a three-year one more than half, and interruptible instances can be half the price or better. If your training writes checkpoints and survives being pre-empted, that is the cheapest cloud option and it requires buying nothing.
A datacentre-class card draws between three hundred and seven hundred watts, and all of it has to leave as heat. Add backup power, floor space and noise nobody can stand in an open-plan office. A machine with four cards is not a computer under a desk but a small server room.
We will not give you a payback period until we see how many hours a month the cards actually compute, because that is the only variable that decides it. With steady high load your own hardware wins; with bursty work the cloud almost always does. We select and run the hardware, while the models stay on your side, because you are the ones who know them. More on choosing machines under servers for business.
Increasingly it is not the proposal or the rate that decides a contract, but a sheet of questions about your safeguards arriving from the client's procurement team. For a software house selling to large companies this is now a real barrier to entry.
Companies covered by the cybersecurity act must account for the risk of their suppliers, so the requirements flow down the chain. The questionnaire will reach you even if the act itself does not cover you, because it is the client who answers for whom it lets into its systems and data.
Who has access to the client's code and data, whether sign-in has a second factor, what happens to access when someone leaves, how often you test restoring a backup, who your subcontractors are and how quickly you report an incident. The questions repeat and come back in one tender after another.
Not a certificate, but consistent answers and evidence behind them: named accounts instead of shared ones, a second factor at sign-in, a written leaver procedure, backups with a recorded restore test and a list of subcontractors. Any gap between the questionnaire and reality surfaces at the client's first audit.
We do not sell ISO 27001 certification and we do not claim it ourselves. We prepare the technical part and the supporting evidence, meaning what you can attach to the questionnaire instead of a declaration: configuration exports, restore test reports and an access list. We record the starting point in an IT audit, and the organisational layer is covered by IT security.
Six areas we lift off the engineering team. Under each one is a link to the page with the detail.
Hardware, setup, requests and onboarding, mainly for people outside the technical team. Developers usually keep their own machines and that is exactly right.
A second factor at sign-in, named accounts, permission reviews and a procedure for withdrawing access when a contractor finishes. This is the first question in every client questionnaire.
Selecting, commissioning and maintaining servers with GPU cards, along with the power, cooling and a place where they can stand without disturbing people.
The code is usually safe because it exists in several places at once. Less so documents, mail, datasets and model checkpoints, which exist in a single copy.
Administration, permissions and order in the places teams work, including keeping track of how many seats are genuinely in use.
A list of tools, owners and renewal dates. The quickest saving in this industry is usually seats still being paid for people who left months ago.
What it does not cover: the code, deployment pipelines, product infrastructure and environments maintained for clients. We also do not carry out research work on models, because that is not our competence and we will not pretend otherwise.
Talking to a technical team is a different conversation, because the questions are specific and well aimed. That is why we hold the first meeting with your CTO rather than with the office manager.
Thirty minutes on what stays with you and what makes sense on our side. We come back with a list of risks and a proposed split. No NDA and no commitment; the list stays with you whatever you decide.
Who has access to what, including people who no longer work here and accounts created for a single project. In a software house this exercise almost always ends in surprise and is the best argument for tidying up.
We open the request channel, take over workstations outside the engineering team and tidy the licences. The technical team notices no change other than questions about the printer no longer reaching them.
Requests, updates, restore tests and a report once a month. Along the way a body of evidence builds up that you then use in client security questionnaires, instead of gathering it from scratch for every tender.
Pages that come up in conversations with software companies.
Pick your industry and see how comprehensive IT support and IT outsourcing for SMEs can help your company.
So that they stop doing things you are not paying them for. A DevOps engineer maintaining the product and client environments is in the right place; the same person configuring the accountant's laptop is the most expensive hour in the company. We split it so your team stays with the product and we take the company's own IT.
No, and we do not want it. The scope excludes repositories, deployment pipelines and production environments, and our accounts in company systems carry only the permissions the work requires. That clause goes into the contract, because it is also the answer to a question in your client's questionnaire.
One number decides it: how many hours a month the cards actually compute. With bursty work the cloud almost always wins; with steady high load your own hardware starts to make sense. Before you cost anything out, though, compare cloud providers, because the difference for the same chip can be several-fold.
Not in the open-plan office, because four cards at several hundred watts each mean noise and heat the team will not tolerate. In practice three routes remain: a separate room with cooling, colocation in an operator's facility, or renting a machine from a GPU provider. For each of them we will work out power and cooling with you before you sign.
Yes, with the technical part. We answer the questions on configuration, access, backups and incidents, and supply evidence you can attach. We do not take the legal and contractual part, which belongs to a law firm, and we do not sell certification. We also say honestly where the answer is no and what changing that would cost.
There is, only the scope looks different. The network and office hardware fall away, and what remains exists anyway: accounts, sign-in, licences, backups and hardware scattered across flats, including the question of what happens to it when someone leaves. With full remote work that last point is usually the most neglected.
Less than in a company of the same size in another industry, because half the team looks after itself and raises no requests. We price from the number of workstations covered and the scope rather than headcount, so a thirty-person software house with ten non-technical people pays for ten, not thirty.
The infrastructure underneath it, yes: servers, cards, drivers, power, network and backups. The models themselves, no, and we will not pretend otherwise, because it would show in the first five minutes of a conversation with your team. The split is simple: we keep the machine running, you decide what it computes.
The first meeting takes 30 minutes and commits you to nothing. We will tell you straight whether we can help and what we would propose.
2019 - 2024 Interactive Workspace Ltd. - All rights reserved.