For Data science leads whose best model is still in a notebook
Machine learning
TechFabric builds and deploys machine learning on Databricks: feature definitions in Unity Catalog, MLflow experiment tracking and model registry, Model Serving endpoints, evaluation gates on promotion, and Lakehouse Monitoring for drift. The engagement covers the retraining schedule and the rollback path as well as the model itself.
Models that reach an endpoint, get retrained on a schedule, and can be rolled back by somebody who was not there.
4 common questions, answered below ↓A model that never ships usually failed on deployment rather than on accuracy. The features were computed in a notebook that runs on one laptop, the training set cannot be reproduced six months later, and nothing downstream notices when the data underneath shifts. The Databricks path out of that is well worn by now: features registered in Unity Catalog so training and serving read one definition, MLflow holding the experiments and the registry, Model Serving behind an endpoint, and Lakehouse Monitoring watching the inputs for drift instead of waiting for the business to notice the outputs. We do the unglamorous half of that. The retraining job that runs on a schedule, the evaluation gate that stops a worse model reaching production, and a rollback path written down before anybody needs it at two in the morning.
- Features registered once, so the training set and the live request read the same definition
- MLflow experiments and a registry, so which model is serving is a lookup rather than an argument
- Evaluation gates on promotion, so a worse model is blocked instead of discussed
- Drift watched on the inputs, with a threshold and an owner rather than a dashboard nobody opens
How an engagement works
01
Talk to an engineer
A real conversation about your initiative with a senior engineer who has built this before. Not a sales call. What you are trying to build, what has been tried, and what is realistic.
02
Discovery and scoping
Two to three weeks to clarify requirements, evaluate where AI fits, and define realistic scope. On AI work this is also where success gets defined precisely enough to score, because a goal nobody can measure cannot be hillclimbed. You get a plan you can act on before committing to a larger engagement.
03
The right team, daily demos
We put the team the work actually needs on it and show you running software every day. Built with the same rigor as any enterprise system: tested, monitored, documented.
04
Production and beyond
Deployed and running under real load, handling real business processes. Ongoing support and team continuity for whatever comes next.
Migrations to Databricks
Off Snowflake, Synapse, Teradata and SQL Server, onto Lakehouse and Lakebase, with a cutover you can reverse.
Data engineering
Pipelines that hold, tables people trust, and a bill that stops surprising you.
Data science & AI
Context stores, memory, retrieval and governed agents that survive production.
AI/BI & Genie dashboards
Genie answers a business question in English, and the answer holds up when somebody checks it against finance.
Data & AI governance
Unity Catalog designed so grants hold, lineage survives a refactor, and an agent inherits permissions instead of routing around them.
Forward-deployed teams
Product, design and engineering people who sit inside your business, find the real problem, and ship it.
Product development
Full product delivery: multi-tenant architecture, operator consoles and the data layer under them. Shipped as Databricks Apps when the product belongs next to the lakehouse.
APIs & durable systems
Long-running operations that survive restarts and partial failure. Temporal under the lakehouse jobs, agent runs and approvals that must not half-complete.
FAQ
Machine learning, answered
Our model works in a notebook. What does it take to serve it?
Less than teams expect on the serving itself and more than they expect on everything around it. The endpoint is straightforward. Reproducing the training set, moving feature computation somewhere that runs without one person's laptop, and deciding what happens when the model degrades are where the work actually is. That is usually two to six weeks depending on how the features were built.
How do you decide when to retrain?
On a schedule to begin with, because it is honest and it is cheap, then on a drift signal once there is enough production history to know what normal looks like. Retraining on drift before you can characterise drift produces a model that chases noise. Lakehouse Monitoring gives the inputs a baseline to be measured against.
Do you build models, or productionise the ones we have?
Both, and the second is more common. Most teams we meet have a data scientist who has already found something that works and no path from there to an endpoint anyone will depend on. Where a model does need building, our engineers work alongside your data scientists rather than replacing them, because the domain knowledge that makes a feature useful is already in your building.
Where does this stop and data engineering start?
At the feature. Everything upstream of a feature definition is the pipeline work at /services/data-engineering, and treating them as separate projects is how a feature ends up computed twice with two different answers. We design the feature alongside the table it reads, for the same reason we design grants alongside the schema.