The bench is a bad place to type

You’ve got flux on your fingers and a half-mitred tube in the jig, and a thought arrives that needs writing down. The thought is for later — tell the client the stays are waiting on the dropouts, or order more silver rod before the next batch. The keyboard is across the room. The phone is in your apron, but typing on it means gloves off, screen squinted at, the thought half-formed by the time the first word is down.

So this season we did the obvious thing: a microphone button on every place you write in Vidual. Press it, say the sentence, and it lands as text — in your morning brief, in a project update, in a Backstory note, on a job in the Docket. It works the same on the phone in your apron as it does at the desk. That part isn’t novel; dictation has existed for years.

What we did differently is everything behind the button.

Where the words go

When you dictate into most software, your voice is sent to a large technology company — one of a small handful that run speech-to-text as a service. Your sentence about a client’s frame goes to their servers, gets transcribed and comes back. It works, and it is also a quiet little export: a recording of your voice, about your client, leaving your control and landing somewhere you’ll never see, governed by a privacy policy you didn’t read.

We weren’t comfortable with that. So we built our own.

Vidual’s voice transcription runs on an open-weights speech model that we host, on our server, in a data centre in Amsterdam. When you dictate, the audio goes to our backend, straight to that machine, and nowhere else. It is never handed to OpenAI, or Google, or anyone selling transcription by the minute. It never leaves the European Union. And it is never stored: the clip is held in memory only long enough to turn it into words, transcribed from a temporary file the machine deletes the moment it’s finished. The text comes back to you; the recording is already gone.

A recording of your voice, about your client, should not be a company’s asset. It should be a sentence that becomes text and then ceases to exist.

This was the harder road. It would have been an afternoon’s work to wire up a paid API and move on. Running the model ourselves meant standing up the infrastructure, keeping it fed, and owning the thing when it breaks. We did it anyway, for three reasons that matter more the longer you use Vidual.

Privacy that isn’t a promise on a page. “We don’t train on your data” is a sentence anyone can write. “Your audio physically never reaches a third party, and is deleted in the same breath it’s transcribed” is an architecture. We prefer the architecture.

Data that stays in Europe. Your voice note about a client’s commission is transcribed in Amsterdam and stays in the EU, start to finish. For a maker with European clients, that’s not a nicety — it’s the difference between a clean answer and an awkward one when someone asks where their data goes.

A bill that doesn’t punish you for using it. When the meter belongs to someone else, every feature has a per-use cost, and the temptation is always to ration it — to put the good stuff behind a higher tier. On our own hardware, the marginal cost of one more transcription is essentially nothing. That’s how features stay generous instead of metered.

This is the start of a longer project, not the end of one. Voice is the first thing we moved onto our own AI infrastructure; it won’t be the last. The principle is simple and we intend to hold it: the bounded, mechanical AI work — transcribing, tidying, matching — should run on machines we own, where your data is ours to protect, not a vendor’s to monetise.

On the Bench, and on the Docket

The second thing we shipped has nothing to do with clients at all — which is exactly the point.

Vidual has always been built around the client build: the project, the timeline, the photos, the portal where your customer watches their commission come together. We call that work on the Bench. But a workshop is full of work that has no client attached. Re-true the alignment table, order brazing flux before it runs out, photograph the green tourer for the website, chase the powder-coater, tidy the offcuts rack. It’s real work — it just isn’t a build, and it has never had a proper home. It lived on the back of an envelope, or a whiteboard, or in the founder’s head.

So we gave it one. It’s called the Docket, and it’s the workshop’s own to-do list — lists of jobs, completely separate from client projects, that no client ever sees. On the Bench is the work you’re showing, and on the Docket is the work you’re doing to keep the place running.

On the DocketWorkshop · this week
Order brazing flux — running low
Mitre & tack the main triangle — Donald’s road frame half a day ▲ Holds Frame Order S
Re-true the alignment table an hour or two P
Photograph the green tourer for the site due Fri N
+ Add a job
The Docket — the workshop’s own list. Plain jobs, a size, a person, and the odd one that’s holding a client build up.

Each job is as light or as full as it needs to be. At its simplest, it’s a line of text you tick off. But tap into one and there’s room for a proper note, a due date, the person it belongs to, a thread of comments with the rest of the team, an “@” to pull someone in, and files dropped straight onto it. You follow the jobs you care about and get told when they move; you don’t for the ones you don’t. Nobody is hard-wired as a recipient — people opt into the threads that concern them, the way they should.

And because the Docket sits inside the same workshop as your builds, a job can be tied to a step in a real project — and marked as blocking it. That’s the small amber flag in the list above: Holds Frame Order. It means the build cannot move on until that job is done. Which leads to the third thing.

Who’s carrying what

There’s a question that gets harder to answer the busier a workshop gets, and it’s the one that wrecks delivery dates: can we actually do all of this in the time we’ve promised?

Most software answers it with a Gantt chart and a scheduling engine — drag the bars around, assign the hours, watch the cascade. We’ve written about why that doesn’t fit a workshop. So we built the smallest useful version of an answer instead, and it starts with sizing a job in the words you’d actually use.

When you put a size on a Docket job, you don’t type hours into a box. You pick a phrase. A quick job. An hour or two. Half a day. A couple of days. Most of a week. Underneath, Vidual reads those as rough hours — half a day is four, a couple of days is sixteen — but you never have to think in those terms. You estimate the way you’d estimate out loud to a customer.

Add those sizes up across everything a person is on the hook for — their client-build steps and their Docket jobs — and you get the Load view: a calm read of who’s carrying what over the next week or two.

Load — the shopnext two weeks
Pete 17h / ~21h
Sam 32h / ~24h
Nia 9h / ~20h
Client build Workshop & internal |  Their comfortable week
Load — each maker’s committed hours against their own comfortable week. Sam’s over; Nia has room. No targets, no scheduler.

Two things make this different from a capacity dashboard, and they’re both deliberate.

First, the line you’re measured against is your own. Vidual doesn’t impose a forty-hour week or a productivity target. It learns what a comfortable fortnight has actually looked like for each person, from the work they’ve actually got through, and draws the line there. One maker’s comfortable week and another’s are different numbers, because they are different people. The marker moves with them, not against them.

Second, it never tells anyone they’re full. There’s no red “over capacity” alarm, no blocked state, no scolding. When someone’s past their comfortable line, the figure simply leans amber — a signal, not a verdict. You’re the one who decides what it means. Maybe it’s fine — a known heavy fortnight. Maybe a job moves to the colleague who has room. The software’s job is to show you the shape clearly enough to make that call in a glance — not to make it for you.

Where it earns its keep

A new commission comes in and the client asks for a date. You open Load, see that the maker who’d own it is already leaning amber through that fortnight, and you have the awkward conversation now — before you promise a date you can’t keep. The deadline you don’t miss is the one you never made.

It ties back to the blocking flag on the Docket, too. A job that’s holding a build — and whose maker is already over their line — is the most useful thing a workshop can know on a Monday. That’s the difference between an ETC that’s a real promise and one that’s a hopeful guess.

One thread

These three things look unrelated — a microphone, a to-do list, a workload bar. But they’re the same instinct pointed at three different places.

The voice transcription says: the unglamorous machinery should be ours, so that your data stays yours. The Docket says: the work that keeps a workshop running deserves the same care as the work you show. And Load says: a view of your own capacity, drawn against your own real weeks, beats a planning tool that pretends to schedule you.

None of it decides anything for you. The voice note becomes your sentence to edit. The Docket holds your jobs, not the software’s. Load shows you the shape and hands you the call. The same line we’ve always held runs through all three: Vidual prepares; the maker decides.

It’s already in there. Press the microphone on your next update. Open the Docket and write down the three things rattling around your head. Put a size on them, and watch the shop’s week take shape.