Product & platform
Typed, observable services with contracts your clients can rely on. Boring in the way infrastructure should be boring — which mostly means the failure modes were thought about before they happened.
We start from the contract your clients need and the load they will put on it. Throughput, payload shape and failure behaviour are far cheaper to agree now than once something depends on them.
The API is designed as a contract — typed, versioned and specific about what happens when it fails. Idempotency and retries are decided here, not added after the first duplicate charge.
Types are generated from one schema, so client and server cannot disagree. Instrumented as it is built, so the traces already exist the first time something is slow.
Load tested to the number agreed in Discover and then past it, so you know the shape of the failure rather than only the ceiling. Auth and dependency review before anything is exposed.
Dashboards and alerts that point at a cause rather than a symptom, each with a runbook. Deploys are boring, which is the whole objective.
A typed streaming endpoint that stops generating the moment the caller disconnects — the cheapest performance work there is.
"""A typed streaming endpoint that stops when the client does."""
from fastapi import FastAPI, Request
from pydantic import BaseModel
from sse_starlette.sse import EventSourceResponse
app = FastAPI()
class Ask(BaseModel):
question: str
conversation_id: str | None = None
@app.post("/v1/ask")
async def ask(body: Ask, request: Request):
async def events():
async for token in answer(body.question):
# The caller hung up. Stop paying for the rest of it.
if await request.is_disconnected():
break
yield {"event": "token", "data": token}
yield {"event": "done", "data": "[DONE]"}
return EventSourceResponse(events())A document-extraction pipeline for a retail group, classifying and extracting structured records from supplier invoices and delivery notes arriving in every format a supplier felt like using.
An inbound voice agent for a freight operator, handling status enquiries and booking amendments outside staffed hours, with a clean handover into the morning queue.
Python with FastAPI when the work sits close to models or data, TypeScript when it sits close to the product, Go when a hot path justifies it. The deciding factor is usually which one your team can maintain, not which one is fastest on a benchmark.
REST for service-to-service and anything cacheable; GraphQL when a client genuinely needs to compose its own queries across many resources. Both get a typed, generated contract — the mistake is picking either one as a default without asking who is calling it.
Yes. Most of this work is integration rather than greenfield. We map the current call graph and failure modes first, and we are explicit about what we are changing and what we are leaving alone.
By measuring first. We load test against your real traffic shape, find the actual bottleneck — usually the database or a synchronous external call — and fix that, rather than scaling everything horizontally and paying for it forever.
A first call is 30 minutes and costs nothing. Bring the problem rather than a spec — the useful part is usually working out whether this is the right shape of solution at all.
contact@algologix.coWe reply within 24 hours.