TensorFlow engineering
TensorFlow turns up in two places now. An estate somebody trained years ago that still has to run, and a model that has to work on a device rather than in a data centre. Both are real engineering problems. Neither is a reason to rewrite anything.
01Capabilities
Four kinds of work worth paying for on an old estate
Most new model work now starts on PyTorch, and TensorFlow persists in production estates and on devices. That shapes which work is worth doing here, and it is closer to machine learning development with a maintenance edge than to starting something from nothing.
- Estates
Models the authors have long since left
Pinned to old versions, with training code that no longer runs on any machine you own. Making training and answering repeatable again is step one, and it is usually harder than any change to the model that follows it.
- Devices
Answers produced where there is no network
The on-device runtime here, now called LiteRT, is still one of the more mature ways to run a model on a phone or a board. The real decisions are size, speed and how much accuracy you trade away, alongside our mobile work.
- Serving
The layer between a model and real traffic
Batching, hardware use, scaling, cold starts and rolling out a new version, usually behind Docker and Kubernetes. A model that is accurate in a notebook and unreliable under load has not shipped, whatever the report said.
- Constraints
Predictions with a deadline and an audience
Demand, load and arrival-time forecasting of the kind in energy and utilities and logistics, where an answer must arrive in milliseconds and an operator has to be able to defend it afterwards.
02Fit
Keep it, port it, or switch it off
We rarely start something new here, and we rarely rewrite something that works out of it. Both halves of that sentence matter, and the table is where they meet. The distinction against our PyTorch page is simple: that page is for new model work, this one is for estates and devices. Each of the six rows below names the call for that estate, from keeping a model running to PyTorch or switching one off.
| Your situation | What we recommend |
|---|---|
| Models in production, doing their job, and nobody complaining | Keep themPort only when a business reason turns up. A rewrite spends real money to arrive exactly where you already are, and it spends it twice if a number moves. |
| Answers have to be produced on a phone, a gateway or an embedded board | LiteRT is defensibleThe alternative is real and improving and it is younger, so we weigh maturity against your hardware and your timeline rather than against a preference. |
| New model work with nothing inherited behind it | Different pagePyTorch. The ecosystem, the published recipes and the people are all there now, and fighting that costs velocity for no gain. |
| The task is understanding language: pulling out fields, sorting, summarising | Rent before trainingRent a model, see the OpenAI API, and only train once cost, speed or a data rule closes that door properly. |
| Rows and columns, tens or hundreds of thousands of them | Boosted treesGradient boosting trains in minutes, explains itself better to the person who signs the decision, and usually wins outright on this shape of data. |
| A model nobody has queried in a year, still on the maintenance list | Switch it offRetiring one is a legitimate outcome and by far the cheapest available. Every estate we open contains at least one, usually more. |
Scope
What we own on this work is making training repeatable, an offline baseline you can hold us to, how the thing behaves under real traffic, and a written keep, port or retire decision for every model with the reasoning attached to it. Where the wider question is whether these models should exist at all, that is AI consulting rather than framework work. unicrew has been building software since 2012, with 100+ senior in-house engineers across six countries, under an ISO 27001:2022 certified information-security management system.
03Delivery
Taking over models the authors have left
Four steps, in this order. The temptation is always to improve the model first, and that is exactly how you lose the ability to prove you improved anything at all.
- Reproduce training and answering exactlyPinned versions, a container that builds, and a fingerprint of the training data. Until an old result can be reproduced, every number after it is unverifiable and every discussion about it is opinion.
- Write down today's scores before touching anythingA held-out set and the current numbers, recorded. Inherited models frequently perform worse than their documentation claims, and knowing that in week one changes what you should do next.
- Decide keep, port or retire, per model, in writingWith the reasoning attached. Estates usually contain two models carrying the value, several that are decorative, and one nobody dares delete because a report somewhere depends on it.
- Fix serving and monitoring before accuracySpeed, throughput, rolling out versions, watching the inputs move, and an alert that names a human being. Accuracy gains are worth nothing if nobody notices when the inputs change. It goes through the same QA and test automation practice we use on our own builds.
04Stack
What keeps an inherited estate running
The pieces that turn up around an older model estate, each with its own page if that is the decision you are actually making.
05Questions
Asked about an estate nobody documented
Six that come up when the people who built these models have moved on, answered the way we would answer them live.
Yes, and with an inherited estate that is often the practical arrangement, because your people know what the models are for. Our engineers own the keep-or-port decision for each model, since that decision sets your maintenance cost for years. An architect outside the delivery team reviews the design, and where you want an outside verdict on the estate we run a quality audit.
For anything new, PyTorch, because that is where the published work, the ready-made models and the engineers are. For something that already runs here, stay here, because a port buys no capability and costs a validation cycle. The exception worth arguing about is running on a device, where the LiteRT path is more mature, and we weigh that against your hardware and timeline.
Sometimes, and the question to answer first is what breaks if you do nothing. Version 1 code pins you to old language and driver versions, which eventually collides with a security patch or a hardware refresh, and that collision is usually the real trigger rather than any modelling benefit. When it is worth doing, we do it one model at a time behind a test proving the scores match.
Yes, and the interesting conversation is what you give up. Shrinking a model makes it smaller and faster while costing some accuracy, and how much depends on the model and the task, so we measure it rather than assume. Sometimes the answer after measuring is that the device cannot do the job, which changes both your offline behaviour and your privacy story.
A scoping call with an engineer. For an existing estate we ask for repository access and whatever test data exists beforehand, because a day spent trying to reproduce one training run tells us more than any workshop does. You get back a written recommendation per model and a view on whether your problem is the models or the serving layer. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, offered once the first read is done, because a fixed number on an estate nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer. The rate depends on the seniority mix, so it is quoted rather than listed.
Inherited models nobody wants to touch?
Tell us what the models do and who depends on them. You will get a written keep, port or retire recommendation for each one, and a clear read on whether the serving layer is where the real gain is.