AI & Machine Learning
TensorFlow
Machine-learning systems that ship and stay shipped — TensorFlow in production, deployment, and on the edge, built by engineers who operate them.
Overview
TensorFlow is Google’s end-to-end machine-learning framework: a numerical-computation engine, a deep-learning library, and — the part that has always set it apart — a mature set of tools for getting a trained model into production. Since version 2, the front door is Keras, the high-level API for defining and training models, so day-to-day model code is concise and readable rather than the graph-wrangling that gave early TensorFlow its reputation. Underneath sits a runtime that compiles computation for CPUs, GPUs, and Google’s TPUs, and around it sits an ecosystem — TensorFlow Serving, TFX, TensorFlow Lite, TensorFlow.js, TensorBoard — that covers training, deployment, monitoring, and inference on almost any target.
We reach for TensorFlow when deployment is the hard part of the problem, not the modelling. Its serving and pipeline tooling is genuinely production-grade and has been battle-tested inside large enterprises for years: TensorFlow Serving gives you a versioned, high-throughput inference server; TFX gives you a repeatable pipeline from data validation through training to a pushed model; TensorFlow Lite runs models on phones, microcontrollers, and edge hardware; and TensorFlow.js runs inference directly in the browser. When a model has to live inside an established MLOps stack, run on a device with no network, or execute client-side, this is where TensorFlow earns its place.
We will also be straight with you about the industry as it actually is in 2026. PyTorch has overtaken TensorFlow in research and across a large share of new development, and for greenfield deep-learning work most teams — ours included — now start in PyTorch. That is not a fashion statement; it reflects where the papers, the pretrained models, the tutorials, and the new talent are concentrating. TensorFlow remains a sound, well-supported choice in specific situations: an existing TensorFlow codebase, on-device and edge deployment via TF Lite, browser inference via TF.js, and teams standardised on the Google Cloud and TFX stack. Outside those, we will usually point you at PyTorch, and say why.
Best for — Teams shipping ML into production or onto devices — existing TensorFlow codebases, TF Lite edge and TF.js browser inference, and Google-Cloud/TFX pipelines — where deployment maturity matters more than research mindshare.
Why teams choose TensorFlow
Deployment is a solved problem, not an afterthought
TensorFlow Serving, TFX, TF Lite, and TF.js mean a trained model has a well-worn path to production, to a phone, or to the browser. The awkward last mile that sinks many ML projects — getting the model reliably in front of users — is where this ecosystem is strongest.
Runs where the data is
The same framework targets server GPUs, Google TPUs, mobile CPUs and DSPs, microcontrollers, and the browser. For products that need inference on-device or offline, that reach is a genuine advantage and not something you retrofit later.
A stable base for long-lived systems
TensorFlow is mature, heavily used inside large enterprises, and backed by Google. For a system that has to run and be maintained for years rather than chase the latest paper, that stability and the depth of production tooling are worth real money.
Why businesses choose TensorFlow
- You have a production TensorFlow system that needs experienced hands to maintain, optimise, or extend — not a rewrite driven by fashion.
- Your product needs the model on the device or in the browser, and you want the most mature path to get it there reliably, at an acceptable size and latency.
- You are committed to Google Cloud and want TPUs, Vertex AI, and a TFX pipeline working together as one coherent stack.
- You want engineers who will tell you honestly whether TensorFlow or PyTorch is right for your specific case, rather than defending whichever one they happen to prefer.
What we build with TensorFlow
The capabilities this technology is genuinely strong at — and what we most often build with it.
Keras model building
We build and train with the Keras API — the Sequential and Functional models for most work, and subclassed models and custom training loops where a problem needs full control. It keeps model definitions concise and legible, which matters as much for the engineer who inherits the code as for the one who writes it.
TensorFlow Serving
For server-side inference we deploy models behind TensorFlow Serving: a purpose-built, high-throughput server with model versioning, atomic hot-swaps between versions, batching, and gRPC and REST endpoints. It is one of the most production-hardened ways to serve a model, and we configure it for the latency and throughput your traffic actually needs.
TFX pipelines
TensorFlow Extended turns a notebook experiment into a repeatable pipeline — data validation, transformation, training, evaluation, and a model-push step — so retraining is a run of the pipeline rather than a manual ritual. We use it where a model must be retrained and redeployed on a schedule with confidence, not by hand.
TensorFlow Lite for edge and mobile
For on-device inference we convert models to TensorFlow Lite, applying quantisation and hardware delegates to fit a model into the memory, latency, and power budget of a phone, an embedded board, or a microcontroller. This is careful engineering — shrinking a model while keeping its accuracy honest — not a one-click export.
TensorFlow.js for the browser
Where inference should run client-side — for privacy, offline use, or to avoid a server round trip — we deploy with TensorFlow.js, running the model in the browser on WebGL or WebGPU. We are realistic about the trade-offs in model size and device performance, and we choose it when the privacy or latency gain is real.
TensorBoard and TPU training
We instrument training with TensorBoard to watch loss curves, distributions, and the compute graph rather than guessing, and where the workload and the cloud bill justify it we train on Google Cloud TPUs, which TensorFlow supports natively for large-scale training.
Use cases
Maintaining and extending existing TensorFlow systems
Taking on a production TensorFlow or Keras codebase to optimise inference, refactor training, add features, or shore up an ageing pipeline — without the cost and risk of a full migration that rarely repays itself.
On-device and edge inference
Vision, audio, or sensor models that must run on a phone or embedded device, often offline — converted and quantised with TensorFlow Lite to meet a real latency and memory budget on the target hardware.
In-browser machine learning
Client-side inference with TensorFlow.js where data should never leave the user’s device, or where a server round trip is too slow or too costly to run per prediction.
Production pipelines on Google Cloud
End-to-end TFX pipelines on Vertex AI — data validation through training to a served model — for teams standardised on Google Cloud who want retraining and deployment to be repeatable and monitored.
When TensorFlow is the right choice
- You already have a TensorFlow or Keras codebase in production and want to extend, optimise, or maintain it rather than rewrite it. A working TensorFlow system is not a reason to migrate — the porting cost rarely pays for itself, and we will tell you so.
- You need on-device or edge inference — a model running on a phone, a microcontroller, or embedded hardware, often offline. TensorFlow Lite is one of the most mature paths for this, with quantisation and hardware-delegate support that a lot of alternatives still lack.
- You need inference in the browser with no server round trip — private, offline-capable, client-side prediction. TensorFlow.js is a first-class option here, and there is no equally mature PyTorch equivalent.
- You are standardised on Google Cloud and want TPUs, Vertex AI, and a TFX pipeline as a coherent, well-integrated stack from data to deployment. Inside that ecosystem, TensorFlow is the native citizen.
- Wrong for: greenfield research and most new deep-learning projects where you are free to choose. Here PyTorch is our default — the ecosystem momentum, pretrained-model availability, and developer ergonomics now favour it, and choosing TensorFlow means swimming against that current for reasons that had better be specific.
TensorFlow: pros and cons
Strengths
- Best-in-class production and deployment tooling — TensorFlow Serving for high-throughput versioned inference, and TFX for repeatable data-to-model pipelines with validation built in.
- The strongest mature story for on-device and edge inference (TensorFlow Lite) and for browser inference (TensorFlow.js), with no equally battle-tested equivalent on the PyTorch side.
- Excellent, first-party tooling around the whole lifecycle — TensorBoard for visualising training, and tight TPU and Vertex AI integration on Google Cloud.
- Keras makes the everyday model-building experience clean and approachable, so training code is readable and quick to write once the surrounding stack is in place.
Trade-offs
- Declining research mindshare: PyTorch now dominates papers, new models, and community examples. When you hit a problem, you are more likely to find a PyTorch answer than a current TensorFlow one.
- API history is fragmented. The gap between TensorFlow 1’s static graphs and TensorFlow 2’s eager, Keras-first style still leaves confusing overlap — multiple ways to do the same thing, and a lot of stale documentation and tutorials from the TF1 era.
- It is not where new talent is concentrating. Hiring engineers already fluent in TensorFlow is harder than for PyTorch, and newcomers to ML are learning PyTorch first, so a TensorFlow codebase can become a staffing liability over time.
- For genuinely new deep-learning work with no deployment or ecosystem constraint pinning you to TensorFlow, choosing it usually adds friction for no offsetting gain — the honest recommendation is often PyTorch instead.
Architecture
A TensorFlow system is really two systems with different demands: the training path and the serving path. We keep them cleanly separated. Training produces a versioned, saved model as an artefact; serving consumes that artefact and knows nothing about how it was made. That boundary is what lets you retrain without touching production, and swap a model version without redeploying the service around it. For anything that retrains on a schedule, we express the training path as a TFX pipeline so the steps — validation, transformation, training, evaluation, push — are explicit, reproducible, and gated rather than run by hand.
The deployment target drives the rest of the architecture, and we decide it early because it constrains the model. A server model behind TensorFlow Serving can be large and GPU-backed; a TensorFlow Lite model on a microcontroller must fit in kilobytes and run without a floating-point unit; a TensorFlow.js model must download over a network the user is paying for. These are not the same model with a different export button — they are different accuracy, size, and latency trade-offs made deliberately at the start, so we settle where inference runs before we settle how the model is built.
Performance
Training performance is mostly about keeping the accelerator fed. A GPU or TPU that spends its time waiting on the data pipeline is expensive idle silicon, so we build input pipelines with the tf.data API — prefetching, parallel reads, and caching — profile them with the TensorBoard profiler, and use mixed precision and distribution strategies where the model and hardware support it. On Google Cloud, TPUs are a real lever for large-scale training when the workload suits them, though we weigh that against the cost and the lock-in before recommending it.
Inference performance is a different discipline for each target. On the server, TensorFlow Serving batches requests and we tune batch size and hardware against your real latency budget. On the edge, TensorFlow Lite performance comes from quantisation — often to eight-bit integers — and from hardware delegates that push work onto a phone’s GPU or neural accelerator; the work is trading a little accuracy for a large speed and size win, measured on the actual device rather than assumed. We optimise against representative load and hardware, because a benchmark on a workstation tells you very little about how a model behaves on a mid-range handset.
Security
A model is untrusted input handling like any other. We validate and bound what reaches a model at inference time, guard the serving endpoint with proper authentication and authorisation rather than leaving it open on the network, and treat a saved model file as executable content — because a SavedModel or a pickled artefact from an untrusted source can carry code, and we only load models whose provenance we control. Dependencies get the same scrutiny: the ML stack is deep, and every package in it is attack surface we keep current and minimal.
On-device and in-browser deployment change the threat model rather than removing it. A model shipped to a phone or a browser is a model an adversary can inspect, extract, and probe, so we assume the weights are not secret and never rely on client-side inference to protect proprietary logic or to enforce a decision that matters — those stay on the server. For anything touching personal data, keeping inference on-device with TF Lite or TF.js can be a genuine privacy gain, because the data need never leave the user’s hardware, and we design for that deliberately rather than as a side effect.
Scalability
Server-side inference scales the way any stateless service does: TensorFlow Serving instances behind a load balancer, scaled on latency and throughput, with request batching absorbing bursts. Because serving is decoupled from training, you scale the inference tier for traffic and the training tier for model complexity independently — they have nothing to do with each other, and coupling their capacity just wastes money. On Google Cloud, Vertex AI can manage that serving tier and its autoscaling for you where it makes sense.
Training scales along a different axis. Distribution strategies spread a single training job across multiple GPUs or TPU cores, and TFX pipelines make retraining at scale a governed, repeatable process rather than a heroic manual effort. Edge and browser deployment scale almost for free in one sense — inference runs on the user’s device, so serving cost does not grow with users — but that shifts the burden onto model size and device performance, which become the real limits. We plan for whichever of these axes your product actually stresses instead of over-engineering the ones it does not.
TensorFlow integrations & ecosystem
The technologies we most often pair with it — each links to how we work with it.
How we work
We start with the decision most teams skip: whether TensorFlow is even the right tool for what you are building. If you have a production TensorFlow system, an edge or browser target, or a committed Google Cloud stack, it very likely is, and we get on with it. If it is greenfield deep-learning work with a free choice, we will make the case for PyTorch and only recommend TensorFlow when there is a concrete reason. That honesty up front saves you from a codebase that fights the industry for years.
From there we settle the deployment target before the model, express retraining as a repeatable pipeline rather than a manual ritual, and build in thin slices — a real model, trained, served, and monitored end to end — instead of a notebook that impresses in a demo and cannot be deployed. The engineers who build the pipeline are the ones who run it, which is what we mean by operating what we build: we optimise for the model that still works in eighteen months, on real hardware, under real load, not the one that scored well once on a slide.
The service behind it
Delivered throughAI DevelopmentWhat we build with TensorFlow
The disciplines this technology most often shows up in — from a first build to taking over and stabilising an existing one.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves — including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Industries we use TensorFlow in
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
Also in AI & Machine Learning
Why teams choose us for TensorFlow
Senior engineers only
Production ML punishes guesswork, and its mistakes hide until a model is in front of users on real hardware. The people making your framework and deployment decisions have shipped and operated ML systems before — there are no juniors learning MLOps on your project.
We operate what we build
We run the models and pipelines we ship, so we optimise for the on-call reality: repeatable retraining, monitored inference, models that fit their target, and serving that stays up. You get a system that survives contact with production, not a demo.
Honest about TensorFlow versus PyTorch
We use both, and we have no stake in which one your project runs on. Where TensorFlow’s deployment maturity or an existing codebase makes it the right call, we say so; where PyTorch is the better default, we say that instead — before you commit years to the wrong stack.
Fluent across the deployment stack
A model is only useful once it is deployed. We bring the surrounding pieces — TensorFlow Serving, TFX, TF Lite conversion and quantisation, TF.js, Docker and Kubernetes, and the Google Cloud and Vertex AI tooling — so the model and everything that carries it to users are built by one team.
Typical timeline
- 01
Discovery and framework decision
One to two weeks agreeing the problem, the data, and — crucially — the deployment target, and confirming honestly whether TensorFlow or PyTorch is the right base for your case before any code is committed.
- 02
First working slice
Two to three weeks getting one real model trained and deployed end to end to its actual target — server, device, or browser — so the deployment path is proven early rather than discovered to be a wall at the end.
- 03
Iterative build
Model, pipeline, and serving improvements in short cycles, each measured against representative data and hardware, with training instrumented in TensorBoard rather than tuned by guesswork.
- 04
Hardening and handover
Performance profiling on the real target, inference and pipeline monitoring in place, security review of the serving surface, and documentation so your team can retrain and redeploy without us.
How pricing works
- Fixed-scope builds for well-defined ML deliverables — a served model, an edge-deployed model, a TFX pipeline — quoted once we understand the data, the target, and the accuracy and latency the job demands.
- Monthly senior engagement for ongoing ML platform and model work, where scope evolves and you want continuity rather than a fixed deliverable.
- Focused audits and rescues for existing TensorFlow codebases — inference optimisation, a stalled pipeline, an edge model that will not fit its budget, or a decision on whether to stay on TensorFlow at all.
Hire TensorFlow engineers
Need TensorFlow capacity on your own team? We embed named senior engineers into your existing team — reporting to your leads, working in your rituals — so you add capacity without a hiring cycle.
Hire TensorFlow engineersCommon questions
TensorFlow or PyTorch — which should we use?
For a new, free-choice deep-learning project, our default is PyTorch: it has won research and much of new development, so the pretrained models, examples, and new talent are concentrated there. TensorFlow is the right call when you have an existing TensorFlow codebase, need mature on-device (TF Lite) or in-browser (TF.js) inference, or are standardised on Google Cloud’s TPU and TFX stack. We use both and will recommend the one that fits your situation, not the one we prefer.
We have a working TensorFlow system — should we migrate to PyTorch?
Usually not. A working production model is not a reason to rewrite it, and the porting cost — re-implementing, re-validating, and re-deploying — rarely repays itself in anything but developer comfort. We would rather maintain, optimise, and extend a sound TensorFlow system than charge you for a migration that adds risk and no user-facing value. If there is a concrete reason to move, such as needing an ecosystem that only PyTorch has, we will make that case specifically rather than by default.
Is TensorFlow good for deploying models to mobile or the edge?
Yes — this is one of its genuine strengths. TensorFlow Lite is among the most mature paths for running a model on a phone, an embedded board, or a microcontroller, with quantisation and hardware delegates to fit real memory and latency budgets. There is no equally battle-tested equivalent on the PyTorch side yet. The work is careful engineering — shrinking a model while keeping its accuracy honest, and measuring on the actual device — not a one-click export.
Can TensorFlow run in the browser?
Yes, via TensorFlow.js, which runs inference client-side on WebGL or WebGPU. It is a strong fit when data should never leave the user’s device for privacy reasons, when you need offline prediction, or when a server round trip per inference is too slow or too expensive. The trade-offs are model size over the network and performance on lower-end devices, so we choose it when the privacy or latency gain is real and measure it on representative hardware.
Is TensorFlow a dying framework?
No, but it has lost the lead. PyTorch has overtaken it in research and much of new development, and new talent is learning PyTorch first, so TensorFlow’s mindshare is genuinely declining. That does not make it dead: it is mature, well-supported by Google, and deeply embedded in large enterprises and production stacks, and its deployment tooling — Serving, TFX, TF Lite, TF.js — remains best-in-class. It is a sound choice in the situations it suits and a poor default for greenfield work that has no reason to pick it. We will not pretend either half of that is untrue.
Building on TensorFlow?
A technical conversation with the engineers who would do the work. If we are not the right fit, we will say so on the call.