EU Speech-to-Text API Procurement: Compare Startup Pricing, SLOs, and Exit Tests

#speechtotext #sre #procurement

Short answer: the cheapest speech-to-text API for an EU startup is the one that passes the startup's region, quality, latency, and recovery gates, then produces the lowest measured cost for the startup's own audio mix; a public per-minute price cannot establish that result by itself.

Treat this as a procurement runbook, not a rate-card contest. Freeze the workload, collect dated quotes for the exact modes under review, replay one corpus through each candidate, and preserve the raw results. OpenAI, Deepgram, AssemblyAI, and Google Cloud can sit in the candidate column, but no name gets a pass on the same acceptance criteria.

The order matters. A low rate attached to a deployment that fails an EU data boundary, transcription-quality target, or recovery drill is not a bargain. It is an excluded option.

What should an EU startup measure when comparing speech-to-text API per-minute pricing?

Begin with a capacity envelope. Record uploaded audio minutes per month, peak uploads per minute, concurrent live sessions if streaming is in scope, the p50 and p95 recording duration, language mix, channel count, and the share of audio expected to need replay. Don't collapse those inputs into one average recording: ten thousand short voice notes and a few long interviews can consume the same audio minutes while creating very different queue pressure, request volume, and failure recovery work.

Then define the product SLO before opening a pricing page. A useful specification names the accepted-to-durable latency objective, the maximum proportion of accepted jobs without a terminal record, the quality review method, and the maximum queue age during peak load. The exact thresholds belong to the product team; I'm not sure a generic threshold would survive contact with both a live-captioning product and an overnight archive workflow. Your mileage may vary, and that is precisely why the test corpus must resemble the workload.

Pricing comes after the gates. Ask every candidate for a dated quote tied to the same processing mode, region, language assumptions, feature set, and billing unit. Capture minimum commitments and separately billed dependencies if they apply to the quote. A per-minute number without those qualifiers is not comparable evidence.

Normalize the resulting observations with one equation:

monthly run cost = billed processing + required storage + transfer + measured replay

Keep on-call hours beside that currency total rather than converting uncertain labor into a suspiciously precise dollar figure. This is a capacity-planning decision — invoices matter, but so do queue saturation, quota headroom, and the number of ambiguous jobs an operator must reconcile. If the estimated cost difference is smaller than the uncertainty created by traffic growth or replay volume, mark the result inconclusive and measure again.

Gate or signal	Evidence to retain	Decision use
EU processing and retention	Contract terms and deployed configuration	Exclude candidates that miss the required boundary
Transcript quality	Frozen audio, reference text, review notes, and raw output	Apply one acceptance method to every candidate
End-to-end latency	Accepted and durable timestamps at p50, p95, and p99	Compare against the product SLO
Missing outcomes	Accepted job IDs reconciled to terminal records	Enforce the reliability gate
Replay-adjusted cost	Dated quote plus observed billed units and replays	Compare only after all gates pass
Exit effort	Adapter contract test and export drill	Expose lock-in before launch

This table is intentionally hostile to a quick winner. Good. Procurement should fail closed when the evidence is incomplete.

A successful upload is not a durable transcript

The dangerous signal is a job that was accepted but never reconciled to a durable terminal outcome. Submission, processing, callback delivery, transcript storage, and product consumption are separate boundaries; monitoring only the first boundary makes the dashboard look healthy while the user-visible result is absent. HTTP status alone cannot answer whether the right audio was processed, whether the result was stored, or whether a duplicate callback overwrote a newer record.

Use an application-generated job ID and source checksum. Write a ledger record before submission, keep the audio object through a declared replay window, and permit only explicit state transitions such as queued, submitted, complete, and failed. A reconciler scans overdue nonterminal records and asks the adapter for authoritative state. Callback delivery is a notification. The ledger is evidence.

One awkward example explains why this matters. Suppose 12,000 recordings are accepted during a launch window, the worker fleet is near its concurrency ceiling, and a small set of callbacks arrive twice while another set arrives after the consumer deadline. A transport-success chart cannot distinguish a safe duplicate from a missing result. The operator needs the source checksum, local job ID, provider job ID, attempt number, terminal timestamp, and output checksum in one place; without that chain, replay may duplicate work or attach text to the wrong recording. The precise counts in a real system will differ, but the control does not: reconcile accepted IDs against terminal IDs before declaring the batch complete.

Short audio doesn't make this safe.

Separate transport rejection, terminal processing failure, quality rejection, overdue reconciliation, and duplicate output into distinct counters. A blended “success rate” erases the reason an error budget is burning. Alert on user-visible SLO consumption and sustained queue age, while keeping raw provider response classes available for diagnosis. Avoid paging on every retry; page when retries threaten the objective or exhaust a bounded recovery policy.

The catch is storage. Retaining source audio improves replay safety and auditability, but it may conflict with a deletion requirement or expand the data-handling surface. Set a documented retention window, encrypt and restrict the objects according to the startup's own policy, and test deletion. When immediate deletion is mandatory, accept that replay may be impossible and design the product state accordingly; don't promise both instant erasure and unlimited recovery.

Put a narrow Go contract around the runtime

The application boundary should express the product operation rather than one vendor's request schema. A narrow interface will not erase differences in streaming, diarization, timing, or language behavior — those capabilities still need explicit tests — but it keeps provider identifiers and response shapes outside the product workflow.

package transcript

import (
    "context"
    "errors"
    "time"
)

type Job struct {
    ID           string
    ObjectURI    string
    SourceSHA256 string
    Language     string
    CreatedAt    time.Time
}

type Result struct {
    JobID        string
    Text         string
    OutputSHA256 string
    CompletedAt  time.Time
}

type Runtime interface {
    Submit(context.Context, Job) (providerJobID string, err error)
    Result(context.Context, string) (Result, error)
}

type Ledger interface {
    CreateQueued(context.Context, Job) error
    MarkSubmitted(context.Context, string, string) error
    MarkComplete(context.Context, Result) error
}

type Service struct {
    runtime Runtime
    ledger  Ledger
}

func (s Service) Submit(ctx context.Context, job Job) error {
    if job.ID == "" || job.ObjectURI == "" || job.SourceSHA256 == "" {
        return errors.New("job ID, object URI, and checksum are required")
    }
    if err := s.ledger.CreateQueued(ctx, job); err != nil {
        return err
    }
    providerJobID, err := s.runtime.Submit(ctx, job)
    if err != nil {
        return err
    }
    return s.ledger.MarkSubmitted(ctx, job.ID, providerJobID)
}

The omission is deliberate: this example has no generic retry loop. Retry safety depends on the selected API's idempotency and error contract, so each adapter must classify outcomes as terminal, retryable, or ambiguous. An ambiguous submission goes to reconciliation before replay. Bound attempts by deadline and error-budget policy, apply backoff only where the applicable contract permits it, and preserve the attempt history.

A provider-neutral boundary is not suitable for every startup. A team using one basic batch mode may reasonably keep a direct integration if it accepts the exit cost and still maintains ledger and reconciliation controls. Stick with a provider-specific interface when a differentiated streaming feature is central to the product and flattening it would make the design dishonest. Add a common adapter when a second implementation, a procurement constraint, or a tested failover objective pays for the extra code.

Verify the bill, the SLO, and the rollback path

Freeze a legally usable corpus that covers the actual risk strata: supported languages, short and long recordings, clean and noisy input, silence, multiple channels where applicable, and deliberately repeated submissions. Version its expected metadata and human review notes. The runner should retain raw output and timestamps rather than emitting only a weighted score, because a single score hides the assumptions that made one failure more expensive than another.

Run the same corpus and load shape through every candidate configuration. Measure accepted-to-durable latency, terminal-outcome coverage, queue age, worker saturation, duplicate results, reconciliation lag, billed units, and replay volume. Review transcript quality with one documented method and the same sampling strategy. I wouldn't approve a decision from a small convenience sample; sample size should come from the required confidence and the risk strata, not a round number chosen for an attractive chart.

Now do the operational arithmetic.

Ownership question	Managed speech API	Self-operated runtime
Capacity planning	Quotas, concurrency, queue depth, and backpressure	Serving capacity, schedulers, accelerators, queue depth, and backpressure
On-call boundary	Ingestion, adapters, reconciliation, and the provider boundary	Model serving, upgrades, ingestion, and reconciliation
Configuration control	Available modes and contract terms	Deployment and runtime choices owned by the team
Lock-in surface	API semantics and transcript features	Model format, serving stack, and internal expertise
Poor fit	Required boundary or control is unavailable	No staffed model-serving ownership or demand is too uncertain to size

Managed service is not suitable when the required deployment boundary or contract terms are unavailable. Self-operation is not suitable when nobody owns model serving on call, upgrade work would displace the product roadmap, or utilization is too uncertain for defensible capacity planning. Neither choice removes the ledger, quality test, or user-facing SLO.

Roll out by cohort with the old path intact. Write rollback triggers before the first production job: a quality-gate breach, sustained queue-age burn, missing terminal outcomes, or projected error-budget exhaustion. Rollback stops new submissions, preserves ledger state, drains or reconciles in-flight work, and replays only jobs whose idempotency evidence makes replay safe. Verify recovery by joining accepted IDs to terminal records and checking source and output checksums. A traffic percentage is not proof that no transcript was lost.

After launch, reconcile the invoice against observed billed units and configuration, rerun quality samples as the audio mix changes, and exercise the exit path on current production-shaped audio. A fallback that exists only in an architecture diagram has zero demonstrated recovery value.

Decision record and operating cadence

The final decision record should be boring: dated candidate configurations, hard gates, raw benchmark locations, SLOs, capacity assumptions, quote inputs, on-call owner, retention decision, rollout trigger, and rollback trigger. Do not write “cheapest” unless the winning configuration passed every gate and its measured total remains lower across the documented uncertainty range.

Revisit the record when traffic shape, language mix, product latency, contract terms, or processing mode changes. Rate cards expire; so do benchmarks.