Running a Deaf-owned interpreting agency on modern software

Most software for interpreting agencies is built by people who have watched interpreting from a distance — through market research, customer interviews, and the occasional site visit. IMP is built differently, and the difference is one sentence long: Frederick Interpreting Agency is a Deaf-owned interpreting agency, and the same team that dispatches interpreters, manages rosters, and sends invoices is the team that builds this platform.

That sentence sounds like a founding story. It’s actually an engineering methodology — a quality process, an incentive structure, and a design philosophy compressed into a staffing decision. Here’s what it changes, concretely.

The one-sentence methodology

Unpack the sentence and three mechanisms fall out. Deaf-owned means accessibility decisions are made by people with direct stakes in them — not reviewed for, advocated for, or consulted on, but made by. The same team means there is no translation layer between the people who feel a problem and the people who can fix it. And dispatches, manages rosters, and sends invoices means the feedback covers the whole operation — scheduling, people, and money — not just the screens a product manager happened to shadow. Everything else in this post is one of those three mechanisms playing out.

Visual-first is not a feature request

When the owner of the company experiences the world visually, “accessible” stops being a checklist item reviewed before launch and becomes the water the product swims in. Communication in a Deaf-owned agency is visual by default — so the software’s job is to make the state of the operation visible, not narrated. In practice, that shows up as a handful of standing rules:

• Schedules you can read at a glance — the day’s shape should be legible before a single row is clicked.
• Statuses that announce themselves by shape and color, with text carrying the meaning — never sound alone.
• Anything important arrives in writing. If a signal only exists as an audio cue, it doesn’t exist.
• Workflows that survive being done in a hallway, on a phone, in silence.

The quiet consequence: design decisions that are essential for Deaf users turn out to be simply better for everyone. A dispatcher in a loud office, an interpreter checking their phone between assignments, an admin on mute in a meeting — every one of them benefits from an interface that assumes the eyes are doing the work. Accessibility done structurally isn’t a constraint on good design; it’s a head start.

ASL work is the center, not an edge case

Plenty of scheduling tools treat interpreting as a generic staffing problem and signed languages as a checkbox within it. Run an actual agency and the picture inverts: ASL assignments come with their own non-negotiables. Video-capable dispatch, because a signed language can never be served over an audio line. Credential tracking that takes certification seriously. Team assignments for long or demanding jobs. The distinction between a request that can flex modality and one that absolutely cannot.

Building inside a Deaf-owned agency means those requirements were in the foundation, not discovered in a support ticket from an early customer. The platform handles spoken-language work across 100+ languages with the same machinery — but it was never designed as if spoken-language phone work were the default and everything else a variation. Architecture remembers where it started.

The feedback loop is measured in days

Every software company says it listens to users. Listening has latency, though: a frustration has to survive being noticed, articulated, submitted, triaged, prioritized, and scheduled before anyone builds the fix. At most companies that pipeline is measured in quarters — and every stage is a place where the real problem gets summarized into something adjacent to itself.

When the dispatch desk and the development desk belong to the same team, the pipeline mostly disappears. A workflow that wastes clicks on Monday is a fix that ships within days — because the person it was wasting clicks on has the commit access. Nothing is lost in translation, because there is no translation. The feature list stops being a wishlist negotiated between departments and becomes a running record of what a real agency needed next.

Every feature ships to ourselves first

There’s a name for using your own product, but the practice matters more than the term: every capability in IMP runs on our own dispatch desk before it reaches anyone else’s. That’s a different kind of testing than a QA checklist. A feature that technically works but slows a real Tuesday gets rebuilt, because the person it slowed has both the motive and the means. Features arrive pre-tested by the least forgiving user there is: an operator whose own payroll depends on them working.

It also keeps the roadmap honest. We build what running an agency demands, in the order the agency demands it — which is why the platform’s foundation is scheduling, dispatch, rates, invoicing, and portals rather than a dashboard of vanity charts. The operation decides.

Every feature ships to ourselves first. If it can’t survive our own dispatch desk, it never reaches yours.

How the loop closes

Questions worth asking any vendor

You don’t have to take alignment on faith — it’s checkable. Three questions surface it quickly, whoever you’re evaluating:

• Who inside your company uses this software to do real work every day? Not tests it — depends on it.
• When did someone on the product team last dispatch a job, confirm an interpreter, or send an invoice with it?
• How do accessibility decisions get made — and by whom? “We have a review process” and “our owner experiences the product visually” are different answers.

Good vendors of every kind can answer these. The answers just tell you where the software’s instincts will come from when a hard trade-off arrives.

What this means if you run an agency

You don’t have to be Deaf-owned for any of this to matter to you. The point is alignment: software built inside a working agency inherits that agency’s incentives. It has to make the daily operation — scheduling, dispatch, interpreter pay, client invoicing — genuinely faster, because its own builders live inside that operation every day. It has to treat interpreters as first-class users, because the builders answer to interpreters personally. And it has to keep accessibility structural rather than cosmetic, because for its owners, that was never optional.

Modern software didn’t change what our agency does. It changed how much of the day goes to the work itself instead of to the tools — and that’s the standard we hold the platform to, one dispatch shift at a time.

Frequently asked questions