Access and confidentiality
The real question is not the price.
It is whether you are willing to give an outsider access to an unannounced title. That decision is usually harder than the fee, it is often not yours alone to make, and most consultancy sites treat it as paperwork. Here is the whole answer.
Access levels
Start at the lowest level that can answer the question.
Access is a ladder, not a switch. Each rung answers more, and each rung is a separate decision you can make at a separate time. Most engagements sit at level 2.
No access at all
You send captures and documents. I never touch your build.
- Unreal Insights traces and GPU captures you record yourself, following a written capture recipe
stat unit,stat gpuand memory reports- Build and cook logs, DDC statistics, CI timings
- Design docs, plans and milestone history
Answers: where the frame time goes, what the worst hitch costs, whether the cook is CPU-bound or DDC-bound, whether the plan is credible. Enough for an advisory session or a triage.
A build, no source
A development build I can run on target hardware. Still no repository.
- Packaged development or test build, plus the console devkit or PC spec it targets
- Permission to record my own Insights traces and GPU captures
- A save or level list that reproduces the bad cases
Answers everything level 0 answers, but measured rather than reported — including the cases nobody thought to capture. This is the minimum viable level for a hands-on review.
Build plus read-only source
Read-only Perforce or Git access, scoped to the streams or branches that matter.
- Read-only account, no submit rights, no admin
- Scoped to the relevant depot paths — engine changes, game code, build scripts
- Revoked by you the day the readout finishes
Adds: why the hot path is hot, whether an engine modification is the cause, how much of the cost is in code you own versus code you inherited. Findings become fixable rather than merely locatable.
Inside your environment
VPN, VDI or a managed workstation you control, for studios whose policy forbids anything else.
- Work happens on your machine, in your network, under your logging
- Nothing is copied out; the report is written in your environment and exported through your own review
- Your MDM, your session recording, your egress controls
The strictest option, and the slowest. It costs perhaps half a day of engagement time to a poorly provisioned VDI — worth knowing before you choose it, and entirely reasonable to choose anyway.
Target hardware
Whose devkit, and how I reach it.
I do not own console devkits. Yours stays in your building, registered to your studio, and I work on it from there.
Registering and shipping devkits to Thailand is not practical, and it is not the model. The kit is yours. What I need is an interactive session on one workstation you provision, with the kit attached to it, reached through whatever remote-access tooling you already use for people working from home. Plain remote desktop is not usable for driving a running game from this distance; the Parsec or HP Anyware class of tool is.
The stream drives the tools, not the judgement. Every conclusion comes from a trace file and a GPU capture measured on the kit and read as data. Distance changes how fast I can work. It does not change what the numbers say.
Where your policy prefers it — and most do — the analysis stays inside that session on your machine, and the only thing that leaves your environment is the document I write. That is the arrangement I would propose before you ask for it.
All of this is a console concern. A PC or Steam title needs none of it.
Platform paperwork
Platform holders license the studio, not the individual, and grant access to named people under that licence. The usual route is being added as a named user under your developer organisation, under NDA, working on your behalf. Whether that needs prior written approval — and whether my being resident in Thailand changes the answer — genuinely varies, and I will not pretend otherwise on a web page.
Three questions for your account manager
Ask them early, and ask for yes or no. Does a named external contractor with remote access to a kit on our premises need your prior approval, or is it covered by our existing agreement? Does the contractor being resident outside the UK or EU change that? If approval is needed, in what form, and how long does it take in practice?
If the answer is slow, or no
Then the work starts at level 0 and needs none of this. Your engineer records the traces and captures to a written recipe; I read them. Hands-on access buys iteration — trying something and measuring again the same afternoon. It is not what buys the analysis. Plenty of engagements never need it.
Before the day starts
A paid day should not begin with a sync.
This list goes out before you book, not on the morning. It is ordered by what actually bites, and the clock does not start until it is done.
- A build in the configuration we agreed, booted on the kit in the last 48 hours. Usually Test — instrumented, but performing like the real game. It is also the configuration nobody smoke-tests, and on a forked engine it may not have been built in weeks.
- Proof that a trace comes out, and is not empty. Tracing compiled in for that configuration, channels enabled, and confirmation that nobody has quietly compiled out the profiler scopes in the hot systems. Run it once, open it, check the timeline is populated. Twenty minutes.
- Somewhere for the trace to land. Minutes of heavy-channel capture is gigabytes. Disk on the kit and the host, and a route for the file that does not depend on a slow link.
- Symbols, decided before the build is made. Matching PDBs for that exact binary, engine symbols, and shader debug data for the GPU capture. Shader symbols are a build-time flag, usually off, and cannot be retrofitted on the day.
- A test case that runs identically twice. A named route, a replay or a flythrough. Without it, comparing two cold runs means nothing — and most studios believe they have this when they do not.
- An agreed definition of cold. Power-cycled or not, shader and PSO caches present or wiped, installed or loose. Cold means four different things; both runs need to agree on which.
- Your build of Unreal Insights, if the engine is forked. Custom trace events need the tool built from your tree, not the launcher one.
- The kit reserved and labelled for the whole window. Kits are shared, and QA will reflash it at two in the afternoon without telling anyone.
- An engineer present for the first hour, and reachable afterwards. Almost everything above surfaces in the first sixty minutes or not at all.
What that costs you. Realistically half a day to a day of a senior engineer's time before my day begins. I would rather write that down than let you discover it on the morning — and most of it is worth having regardless of whether you ever hire me.
If the answer is no
What you still get with zero repository access.
A studio that cannot open Perforce to an outsider is not a studio that cannot be helped. It is a studio that starts at level 0.
Send a written capture recipe to one of your engineers, and an afternoon of their time produces Insights traces, GPU captures, memory reports, cook logs and DDC statistics. Those artefacts carry the measurements, not the source. From them it is possible to say which passes are expensive, what the worst repeatable hitch costs in milliseconds, where the memory high-water mark sits against the platform budget, and whether the cook is bound on CPU, on DDC misses or on shader compilation.
What is not possible without source is naming the exact function or asset responsible and estimating the fix cost with confidence. The finding becomes this pass costs 6.2 ms and should cost 2 rather than this pass costs 6.2 ms because of this loop.
That is frequently enough to make the decision, and it is always enough to decide whether deeper access is worth the internal argument.
The capture recipe is free. Ask for it and it will be sent whether or not you buy anything.
The flow
Where your material goes, and where it stops.
Level 3 engagements collapse the middle column into your own VDI: the working machine is your machine.
Handling
Where material is held, and what is deleted when
| Material | Where it is held | Leaves your environment? | Deleted |
|---|---|---|---|
| Engine and game source | Your repository only | Never | Access revoked at readout |
| Assets, builds, packaged content | Your environment or devkit | Never | Access revoked at readout |
| Insights traces, GPU captures | Encrypted working machine, or your environment at level 3 | Only by agreement | 30 days after delivery |
| Interview notes | Encrypted working machine | Aggregated only | 30 days after delivery |
| Draft and final report | Encrypted working machine, delivered to you | Delivered to you | Final retained 12 months for your benefit, or deleted on request |
| Credentials and access tokens | Password manager, hardware-key protected | Never | Immediately at readout |
Deletion is confirmed to you in writing. The schedule above is the default; a shorter one can be written into the statement of work and will be honoured.
For your infosec team
The questions they will actually ask
Named personnel
Robert Troughton, sole principal, is the only person with access by default. If an engagement needs a named specialist, that person is identified to you by name and role before any access is granted, and is covered by the same confidentiality terms and the same deletion schedule.
Device policy
One dedicated workstation and one laptop, both full-disk encrypted, both with automatic screen lock, neither shared with anyone. No client material on phones or tablets. No consumer cloud sync clients on the working machine. Hardware security keys on every account that touches client access.
Source handling
Source is read where it lives. Where a local sync is unavoidable for build or trace symbolication, it is confined to the encrypted working machine, excluded from every backup target, and removed at readout.
AI tools
No client source, assets, captures, documents or interview notes are placed into public or consumer AI services. Where a tool is used on client material at all, it is one you have approved in writing, running under your terms. See the position on AI.
Data jurisdiction
The working machine is physically in Thailand. That is a question worth asking, and the honest answer to it is that the strongest control is not jurisdiction but the fact that your source never leaves your environment. If your policy requires data residency in a specific region, level 3 satisfies it completely — the material never moves at all.
Background checks
A basic disclosure check and identity verification are available on request and paid for by Dino Sloth, not billed to you. Where your process requires a specific vetting standard, tell me at scoping and it will be completed before access, not after.
Forward this, not the URL
One-page security summary.
Named personnel, device policy, source handling, data jurisdiction, deletion schedule and the background-check position, on a single side of A4.
Written to be attached to a ticket and read by someone who has never heard of Dino Sloth. If your security review needs a document rather than a link, this is the document.
No gate, no form, no tracking. Send it to whoever needs it.
Can we start at level 0 and go further only if it is worth it?
Who signs the NDA?
Our publisher has to approve external access. How long does that take?
Do you keep our build afterwards?
Can our engineers watch what you are doing?
Still not sure you can grant access?
Ask for the capture recipe. It costs nothing and needs no access at all.