The people, by name
The engineers who scope your build are the engineers who write it, on the tools rather than in the pitch. Public commit history, real talks, real handles. Ask us for the CVs before the first call and we’ll send them.
Engineering studio · Available for Q1 2027 builds
The prototype is
the easy half.
PRAXS builds the AI systems, data platforms, and products that have to keep working after the launch post. Under real load, inside a real cost ceiling, on a real on-call rotation. In your cloud, in your repository, owned by you from the first commit.
30 minutes. No deck. We’ll tell you if it’s not a fit.
PRAXS · Engineering studio
Remote-first · US & EU hours
Senior engineers only
AWS · GCP · Azure
Remote-first · US & EU hours
Senior engineers only
AWS · GCP · Azure
Team
Senior only. Median 8 years shipping production systems. No juniors billed to you.
Start
Two-week architecture sprint, fixed fee. You keep every artifact.
Ownership
Your cloud accounts. Your repository. IP assigned as invoices clear.
Typical build
8–16 weeks · $50k–$180k · two to four engineers
02 · Evidence
We can’t show you a logo wall. Here’s what we can show you instead.
Most of our work is under NDA, and the rest belongs to founders who haven’t launched. So we’re not going to line up six grey logos you can’t verify, or a headshot next to a quote nobody said. Here is the evidence that survives a phone call.
A reference call before you sign anything
We’ll put you on a 20-minute call with a client who has already been through a build with us. Unscripted, and we’re not on the line. Available once we’re both past the first conversation.
A real artifact you can read
The output of an architecture sprint, redacted: system design, data model, cost model, risk register, and the criteria that would have made us tell the client to stop. Ask for it on the first call and judge the thinking before you commit to anything.
Numbers with their measurement windows
Every figure on this page names the system it came from and the period it was measured over. If a number can’t carry its own footnote, it isn’t on the site.
What we don’t have: SOC 2 Type II, and we won’t imply otherwise. We work inside your compliance perimeter, under your controls, your auditors and your DPAs.
03 · What we build
Four things, at production standard. Not a services menu.
We take work where the hard part is engineering judgement under constraint. If the hard part is headcount, a staffing firm will serve you better and cost less.
LLM systems with evaluation harnesses, retrieval that’s measured rather than assumed, fine-tuning where it beats prompting and not before, generation pipelines with human gates where the output carries risk. We instrument accuracy, latency, and cost per call from the first week, because all three are what kill these systems in month four.
Not a fit: novel model research, or an agent demo intended for a fundraise. Stack: PyTorch · LangChain · vLLM · Hugging Face · MLflow · Weights & BiasesStreaming and batch pipelines that survive replay, schema drift, and audit. Migrations off legacy batch systems without a freeze window, run in parallel with a parity harness until the numbers match record for record.
Not a fit: one-off data cleanup, or a dashboard on top of a spreadsheet. Stack: Kafka · Spark · Snowflake · Databricks · Airflow · dbtFull-stack SaaS from an empty repository: auth, billing, permissions, the admin surface nobody budgets for. We ship the spine end to end before we widen it, so there is a working system in your hands in weeks rather than at the end.
Not a fit: marketing sites, or design-only engagements. Stack: TypeScript · React · Next.js · Node · Python · Go · PostgresAWS, GCP, Azure. Terraform from the first commit, Kubernetes where it earns its complexity and managed services where it doesn’t. Cost ceilings with alerts before the invoice, not after. Observability, SLOs, and a runbook your team can execute without calling us.
Not a fit: 24/7 managed operations. We hand the pager to you, or help you hire for it. Stack: AWS · GCP · Azure · Kubernetes · Terraform · OpenTelemetry
05
What we decline
We say no to staff augmentation, to reselling someone else’s model as a product, to AI strategy engagements that end in a deck, and to any build where nobody on your side will own the result. Roughly one in three enquiries gets a referral elsewhere instead of a proposal.
No proposal
Cloud
AWS · GCP · Azure · Kubernetes · Terraform
Data
Kafka · Spark · Snowflake · Databricks · Airflow · dbt
AI/ML
PyTorch · LangChain · vLLM · Hugging Face · MLflow · Weights & Biases
Product
TypeScript · React · Next.js · Node · Python · Go · Postgres
We choose boring on purpose. Everything here has a hiring market.
04 · Selected work
Three builds, including what each one cost us.
Clients are unnamed at their request. Every number below is from a production system and names the window it was measured over.
The nightly reconciliation started finishing after the trading day did.
Problem
A payments platform reconciled its books in an overnight batch. Volume growth pushed the job past its window. Finance began each morning with numbers that were hours stale and closed the previous day by hand. Every week of growth made it worse.
Constraint
Ingestion could not pause, not for an hour. No transaction could be dropped or double-counted, and every record needed auditable lineage for the regulator. The in-house team had to own the result afterwards without hiring specialists to keep it alive.
Approach
A strangler migration rather than a rewrite. We put a Kafka log in front as the source of truth and moved transforms to Spark structured streaming one entity at a time. Old and new ran in parallel behind a parity harness that diffed every record and failed the build on any mismatch. Compute moved to autoscaling with spot capacity under a hard monthly ceiling that alerts before it is hit.
What it cost us
The parity harness was about a fifth of the build and shipped zero features. We would do it again. Cutting that harness is how migrations like this quietly lose money for six months before anyone notices.
Outcome
10×
Processing throughput
2M+ / day
At sub-second latency
60%
Lower infrastructure cost
Measured over the first six months post-cutover against the prior 90-day baseline.
200 personalised videos a day, with a human still approving every claim.
Problem
A global brand wanted personalised video across every market it sold in. Their agency priced per asset, so the campaign stopped being viable somewhere around 300 videos. The idea was fine. The unit economics weren’t.
Constraint
Brand safety was absolute: no generated line could invent a product claim, a price, or a legal disclaimer. Existing brand templates had to be honoured to the frame, because legal had already signed them.
Approach
A pipeline of constrained steps instead of one open-ended model. Copy is assembled only from an approved claim library and slot-filled into locked templates, so the model never writes a claim it could get wrong. Three automated gates follow: claim-set validation, brand term and profanity filtering, and a frame diff against the template. Anything that fails a gate goes to a human queue rather than to publish. Rendering runs on preemptible GPUs with shared-segment caching, so common intros and outros render once instead of 200 times.
What it cost us
This does not replace the creative director, and we told them so before we started. It removes the versioning work, not the judgement. The approval queue is a feature we designed in, not a fallback we settled for.
Outcome
200+ / day
Sustained render volume
85%
Lower cost per asset
0
Brand-safety escalations
Cost compared against the client’s prior per-asset agency rate. Escalations counted from launch to handover.
Twelve weeks from an empty repository to paying users.
Problem
A founder had signed design partners and a contractual launch date, and no engineering team. The deadline was not negotiable, and neither was the budget.
Constraint
One decision-maker, available weekly. Whatever shipped had to be operable by a team of two who had not been hired yet. Everything we chose, they would have to live with for three years.
Approach
We cut to the spine first: auth, billing, the single analytic the design partners were paying for, and the dashboard. Managed services over anything self-hosted, Terraform from week one, no infrastructure without a runbook. We kept a written list of what we were deliberately not building and why, and the founder signed it. Weekly demos ran on the real environment. Never on a laptop.
What it cost us
We deferred SSO, granular roles, and the reporting export. That deferral list was a document signed in week two, not a surprise discovered in month five. It is the only reason the date held.
Outcome
12weeks
To production, on the contractual date
99.9%
Uptime after launch
2
In-house engineers took it over
Uptime measured as the successful health-check ratio on the public API, at one-minute intervals, over the first six months.
Every one of these had a week where the honest answer was “this approach isn’t working.” Getting to that week early is most of what you’re paying for.
05 · How an engagement runs
Four phases, each with an artifact and an exit.
You can end this after any phase and keep everything produced up to that point. That’s the design, not a concession.
Overall · 12 weeks typ.
01
Weeks 1–2
Weeks 1–2
Architecture sprint
We work through your data, your constraints, and the two or three decisions that will determine whether this succeeds. Fixed fee.
You receive: system design and data model · a cost model at your projected volume · a ranked risk register · a delivery plan with dates · the written criteria that would make us recommend stopping.
Exit
Walk away owning all of it. Take it to another firm if you want. Around one in five clients do exactly that, and that’s a fine outcome.
02
Weeks 3–6
Weeks 3–6
The spine
The thinnest end-to-end path through the system, in your production environment behind a flag, with real data flowing through it. Not a prototype, not a mock. Small, but real and deployed.
Exit
Real data moving through production. If the spine can’t be built, you know in week five, not week fourteen.
03
Weeks 6–11
Weeks 6–11
Hardening
Where most of the work actually is. Load and failure testing, the cost ceiling and its alerts, retries and backpressure, observability, the test suite, and the ugly edge cases that only appear against real data. Weekly demos on the deployed environment.
Exit
The agreed SLO, met on production traffic for 14 consecutive days.
04
Weeks 11–12
Weeks 11–12
Handover
Handover is a phase with a deliverable list, not a goodbye email. Runbook, architecture decision records, on-call playbook, infrastructure as code, two recorded walkthroughs, and a written “what we’d build next” memo. Your engineers deploy from the runbook while we watch and say nothing. If they can’t, the runbook is wrong and we fix it.
Exit
Your team ships a change without us. Then 30 days of questions answered at no cost.
06 · Engagement and pricing
Four ways to work with us, and what each one costs.
We publish bands rather than a menu, because the honest number depends on how much of your data is where you think it is. The band is real though, and the first call will place you inside it.
01
Architecture sprint
Two weeks, fixed fee. Ends with the artifact set in section 05. No obligation to continue, and no discount for continuing, because we price it the same either way so the recommendation stays honest.
$9k–$14kTwo weeks · fixed
02
Build
Fixed scope and fixed price per phase, invoiced monthly. Scope changes are a written change order, never a quiet extension.
$50k–$180k8–16 weeks
03
Embedded team
Two to four senior engineers working inside your process, your standups, your repo. For when the work is ongoing and the constraint is senior capacity.
$22k–$45kPer month · min. 3
04
Rescue and audit
For a build that has gone sideways or a system nobody can safely change. You get a written assessment and options, including the option of keeping your current team.
$8kOne week
Up
Regulated data, a migration with no freeze window, integrations with systems that have no documented API.
Down
A greenfield build, one decision-maker, and data that is already where you say it is.
Fixed
Our rate. We don’t discount for volume, and we don’t have a cheaper team to switch you to after signing.
07 · Terms
What happens if this goes wrong.
You are considering a five- or six-figure commitment to a studio you met on the internet. The reasonable thing to do is assume it might fail. So here is what is true on your worst day.
You own it from the first commit
Work for hire. Code lands in your repository and your cloud accounts, not ours. IP is assigned as invoices clear, so you are never in a position where you have paid for something you don’t yet own. We keep no licence, no reuse right, and no copy after the engagement ends.
We never hold the keys
We work as invited members of your organisation. Your cloud, your DNS, your CI, your secrets manager. There is no PRAXS account anything depends on, and nothing to migrate off when we leave. Our access is revoked on the last day and nothing breaks.
No PRAXS framework, ever
The oldest trick in this industry is shipping an in-house framework so the client has to keep paying the firm that wrote it. We build on technology with a hiring market. If we hand you something your next engineer can’t learn from public documentation, we’ve failed. We’ll also write the job description for the person who takes it over.
The written stop condition
Before any build starts, we agree in writing on the threshold below which the system is not worth shipping, whether that is accuracy, latency or cost per call, and on how we’ll measure it against your data rather than a benchmark. If we hit that wall, we say so immediately and stop billing.
Exit in 14 days, any phase, no penalty
Give 14 days’ notice and the phase closes cleanly. Everything merges to main. You get the runbook as it stands, the decision records, a recorded walkthrough, and 30 days of questions answered. There is no kill fee and no clause that makes leaving expensive. If we’re not earning the next phase, we shouldn’t get it.
Your data stays your data
We don’t train on it, we don’t retain it, and we don’t move it into a third-party tool without a named agreement you’ve seen. Wherever possible we work against synthetic or masked data and never take production data out of your environment. If your compliance team wants to review that arrangement before we start, put us on the call.
Handover is a deliverable, not a favour
- Runbook
- Architecture decision records
- On-call playbook
- Infrastructure as code
- Test suite
- Seed and fixture data
- Two recorded walkthroughs
- A written next-steps memo
It is on the invoice as a line item. Which means it is contractual, and which means it gets done in weeks 1 through 11 rather than promised in week 12.
None of the above is unusual to ask for. It is unusual to publish before you ask.
08 · The questions
Five reasons not to hire us, answered.
Two named engineers on every engagement from week one, never one, and both are in the code. Everything lives in your repository and your cloud from the first commit, so continuity doesn’t depend on us being reachable. The runbook is written during the build and tested by having the second engineer deploy from it without help. If they can’t, the runbook is wrong.
If PRAXS disappeared overnight, you would have a running system, the decision records explaining every non-obvious choice, and recorded walkthroughs. Several of the systems we’ve handed over have had no involvement from us since. Ask us to name them on the call.
Two different answers, and one of them might be no.
Scale: we’ve built pipelines sustaining 2M+ transactions a day at sub-second latency. If your number is a hundred times that, we’ll say so and tell you what we’d want to prove in the first two weeks before either of us commits.
Regulation: we work inside your compliance perimeter: your accounts, your controls, your auditors, your DPAs. We are not a compliance vendor. We don’t sign as your data protection officer and we don’t claim certifications we don’t hold. We do not hold SOC 2 Type II, and if your procurement requires it from a vendor at this stage, we will not pass and you should filter us out now rather than in week six.
It’s a real failure mode, and on most projects it isn’t an accident. It’s the vendor’s business model.
Our defences are structural rather than promised. No proprietary framework. No PRAXS-hosted component. No licence you have to renew. Boring, hireable technology throughout. Handover as a contractual line item with a fixed deliverable list. And a final exit test where your engineers ship a change to production while we sit silently on the call. That test either passes or the engagement isn’t finished.
On in-house: if this capability is core to your company and permanent, hiring is usually the right answer, and we’ll tell you that for free. The catch is that a senior hire is four to six months away and this build probably isn’t. We’re a good fit for the first version, a migration with a fixed date, or the thing that has to exist before you can justify the headcount.
On cheaper: the price gap is real and we’re not going to pretend it away. You are paying for fewer, more senior people and for architectural decisions that don’t get re-made in month nine. That’s worth it on systems where being wrong is expensive, and genuinely not worth it on systems where it isn’t. If unit price is your deciding variable, we will lose this, and you should let us.
Sometimes it doesn’t. Retrieval quality on messy internal documents, extraction accuracy on scanned forms, latency under a cost ceiling. These fail against real data more often than the demo circuit suggests.
Which is why the first artifact we produce is the number that means stop. Before the build we agree on the threshold and how we’ll measure it on your data. If we hit that wall, you hear it in week three, not week eleven, and your exposure was the sprint rather than the build. We have told prospective clients that the honest answer was “don’t build this yet.” Some came back the following year with better data, and we built it then.
Who owns the IP?
You do. Work for hire, assigned as invoices clear. We keep no licence.
Do you sign our NDA and MSA?
Yes. We’ll also send ours if you’d rather start there. Typical turnaround is three business days.
How fast can you start?
Architecture sprints usually begin within two weeks. Full builds depend on current commitments, and we’ll give you a real date, not “soon.”
Where are you based?
Remote-first, working across US and EU hours. All communication in your tools, not a portal.
09 · Start
Tell us what has to exist, and by when.
The first call is 30 minutes with the engineer who would run the build. Bring the constraint that worries you most. If we’re not the right team for it, we’ll say so on that call and point you toward someone who is.
01
A 30-minute call. No deck, no discovery deck, no salesperson.
02
A written scope and a fixed price for a two-week architecture sprint, within three business days.
03
You decide. Roughly one in five of these conversations ends with us recommending you do it in-house instead.
Prefer email? hello@praxs.ai
We store what you send to reply to you and nothing else. No sequences, no newsletter, no CRM enrichment.