Reference · Chapter 36
Working with TechFabric
This chapter is about us rather than about the platform, and it is here because the rest of the manual is only useful to you if you know what to do with it.
The short version
TechFabric is a software development company. Senior engineers who embed in your team or own delivery as a pod, shipping production software on Databricks, Temporal, and the major clouds. We were founded in 2017 by engineers, and there are 115 or more of us across Phoenix, Amsterdam, Dnipro and Hyderabad. We are a Databricks partner and a Temporal partner. The short description of what makes our Databricks work different is that we run our own products on it, so the opinions in this manual are not observations about other people's platforms.
The two ways we work #
Both modes are real, and which one fits depends on whether you have a team that needs strengthening or a problem that needs owning.
Engineers inside your team. Senior people who join your standups, work in your repository, follow your review process, and raise your standards from the inside. This suits an organisation that already has a team and a direction and needs capacity or specific depth it does not have.
A pod that owns delivery end to end. A self-contained group that takes a problem, designs it, builds it, ships it, and hands it over. This suits an organisation that needs an outcome by a date and does not have the team to reach it, or that wants a new capability built alongside the existing one rather than inside it.
The shape that does not work is supplying engineers into a design we did not participate in and cannot change. We would rather say so than take the work and watch it go badly.
Where an engagement usually starts #
Three starting points cover most of what we do.
An architecture engagement, typically a few weeks, producing the decisions in this manual made specifically for your estate: catalog layout, environment topology, governance model, migration sequence, and a costed plan. This is the right start when the direction is unclear, and it is deliberately scoped so you can take the output and execute it without us.
A delivery engagement, where we build the platform or run the migration with the explicit goal of handing it over. Handover is a design constraint from the first sprint rather than a phase at the end, which shows up as documentation, runbooks, and your engineers doing the work alongside ours rather than watching.
An accelerator engagement, where one of our products does the mechanical share and we handle the judgement. Fabric Airlift for migrations is the clearest example.
What we build on top of the platform #
Several of our products run on Databricks and are available to clients we work with.
Fabric Airlift handles the artefact bookkeeping of a migration across tables, pipelines, and jobs, supporting more than thirty source types including traditional data warehouses, ERPs, and other systems of record. What it does not do is the semantic reconstruction described in Migration, because that requires judgement about business meaning and we would not trust a tool that claimed otherwise.
Fabric Harness is an open source TypeScript framework for governed data and AI agents, published under Apache 2.0. It provides durable execution through Temporal and capability-level policy governance, and it is portable from Databricks, where Unity Catalog, Lakebase and on-behalf-of authentication are first class, out to the other clouds and to Kubernetes.
The fabric.pro platform layer provides the policy evaluation and governed action pipeline described in Governed Actions, which is how we let agents affect systems of record without letting a model be the last thing that decides.
Where our judgement is sharpest #
Our deepest vertical experience is automotive and auto finance, covering loan origination, refinancing, and vehicle repossession, which is why the examples in this manual keep returning to loans and applications. We work well outside that vertical and this is where our instincts need the least calibration.
The second place is anywhere durable execution matters, meaning systems where a half-completed operation is the worst available outcome. That is the same instinct that produced Governed Actions, and it is why we are a Temporal partner as well as a Databricks one.
What we expect from you #
Engagements go well when three things are true, and we would rather establish them at the start than discover their absence in month three.
Someone on your side has the authority to settle a definition. Conformance work in the silver layer needs a person who can decide what a customer is, and no amount of engineering substitutes for that decision.
The consumers of the platform are identified and reachable. Migration and modelling both stall on consumers who cannot be found or cannot prioritise a conversation.
There is a real answer to the question of what decision this data supports. It is the question we ask first, and it separates a project that will be used from one that will merely be delivered.
Getting in touch #
The best starting conversation is a specific problem rather than a general enquiry, and the most useful thing you can bring is one requirement that currently spans several systems. Reach us through techfabric.com.
If you found something in this manual that is wrong, out of date, or too generous to us, we would like to know. The manual is maintained rather than published once, and corrections from people running this in production are the most valuable input it gets.