Frequently asked questions

Do you work on-site or remotely?

On-site, by default. The hardware lives somewhere physical, the network it sits on matters, and the handover works better when you have watched the system get built on your own desk. Some work can be done remotely โ€” a Tune-Up on a system I set up, follow-up questions after an engagement, diagnosis that only needs a shell โ€” and I will say so when that is the case. New setups are on-site.

What area do you cover?

I work within roughly a three-hour drive of New York City. Larger multi-day Studio jobs further afield are sometimes possible with travel costs scoped in โ€” ask on the intake form and I will give you a straight answer rather than a maybe.

What does the hardware cost, and who buys it?

You buy it, directly, from whichever supplier you prefer. I do not sell hardware, do not mark it up, and do not take a cut on it. During an engagement I recommend what fits the workload โ€” which is sometimes cheaper than what you were about to buy. Some links elsewhere on this site are affiliate links and are disclosed as such; recommendations made inside a paid engagement are based on fit, not commission. Hardware cost depends entirely on the workload, and I will tell you the realistic figure for yours before you spend anything.

What happens if it breaks after you leave?

First: the handover notes exist precisely so that most "broken" is something you can fix yourself in five minutes โ€” a service that did not restart, an update that needs re-running. The common failures are written down with their fixes. Second: email me. Questions about a system I set up get answered without a meter running. Third: if it genuinely needs hands on it, that is what the Rescue and Tune-Up services are for, and a system I built is fast for me to diagnose because the documentation already exists. What I do not offer is a support subscription or a guaranteed response time โ€” I do this part-time, and I would rather be clear about that than sell a promise I cannot staff.

What happens to my data?

It stays on your hardware. That is the entire premise. During setup I work with your files only as far as the job requires โ€” pointing a document store at the right folder, testing retrieval โ€” and nothing is copied off your machines, sent to a cloud service, or kept by me afterward. If a job involves material under NDA or similar, say so up front and we put paperwork around it before I arrive.

Why run models locally at all, instead of just paying for a cloud API?

Cloud APIs are the right answer for plenty of workloads, and I will say so on the intro call if yours is one of them. Local makes sense when some combination of these is true: your data cannot or should not leave the building; usage is heavy enough that per-token billing exceeds the hardware cost within a year or two; you need the system to keep working with no internet; or you want capability that does not change, disappear, or get repriced on a vendor's schedule. The trade-offs are real โ€” local models below the frontier, your hardware, your maintenance โ€” and part of the intro call is checking that the trade favors you.

How long from booking to a working system?

The honest answer involves my calendar: this is part-time work, scheduled across weekdays and some weekends, with a limited number of setups per month. Typical shape: the intake form gets a reply within a few days; the intro call happens within a week or two; the on-site day is usually two to six weeks out depending on the queue and whether hardware still needs buying. The setup itself is half a day to three days depending on scope. If you have a hard deadline, put it on the form โ€” I would rather decline early than deliver late.