Techufy Inc.
Software for people who run networks.
We are a small engineering company in Bellevue, Washington. We built a TR-369 USP controller from scratch, we design and build large back-end systems for telecoms and enterprises, and we teach the Broadband Forum protocols we work with every day.
What we do
Development
Most of us have spent 15 years or more building systems that cannot go down: telecom billing and rating engines, message brokers, device management platforms. We take on projects where the hard part is the architecture, not the screens.
These are the areas we work in:
Consultancy
Sometimes you do not need another team writing code. You need someone who has already made the mistakes to look at your design, your cluster or your migration plan and tell you plainly what will break. That is what our consultancy is.
We consult on:
Training
The Broadband Forum specifications are long, and the useful parts are spread across several documents. Our courses walk through them in order, then put you in front of a real controller and a real agent so the theory sticks.
Two courses at the moment:
Our product: the Techufy TR-369 USP Solution
A USP controller for operators with a lot of devices. It runs on Cassandra and Kafka, talks MQTT, STOMP and WebSocket, and has a web interface for the day-to-day work of managing devices and device groups. We wrote every module for TR-369; none of it is a TR-069 ACS with a new name.
Built for TR-369, not adapted to it
USP is a different protocol from CWMP: several controllers per device, persistent broker connections, notifications, bulk data. Bolting that onto an ACS gives you an ACS with extra steps. We started from the USP specification instead.
About the product
Nothing in it has a single point of failure
The database is a Cassandra ring, the brokers are clustered, the core services talk over Kafka. Add nodes when the device count grows. The REST APIs and Camunda workflows are there from the first install, so it plugs into what you already run.
Technical detailsFour things we will tell you in the first meeting
It is new code
We did not repaint an old ACS. The USP Solution was written for TR-369 with current tools. You can read the architecture and check.
It scales sideways
Every layer, from the database to the API, is distributed. More devices means more nodes, not a bigger box.
It is a USP controller
Not "USP-ready", not "USP-capable". A controller that speaks TR-369 to agents, tested against the Broadband Forum's own OB-USP-Agent.
We know both sides
We have built a TR-069 ACS, a USP controller, and billing systems for telecoms. We know what your operations team will ask for on day two.
What that means for you
Any device that speaks USP
All three transports, the full set of message types and the TR-181 profiles. If a vendor's agent follows the specification, it will talk to the controller.
We track the specification
When the Broadband Forum publishes a new amendment or proto version, we update the controller. You will not be stuck on an old release.
Evenings and outages are not special
The Kafka backbone and clustered brokers are sized for the moment every device in a region reconnects at once.
We will change it for you
Every operator has a process nobody else has. Tell us about yours. We are a small company and the people who wrote the code are the people you will talk to.
We also run TR369.org
While building the controller we kept notes on the parts of the specification that took us longest to get right. Those notes became TR369.org: a free site with worked examples of USP records, messages, error codes and the OB-USP-Agent, written for engineers who have to implement this, not summarize it.
The specification, explained in order
Records, messages, transports, the data model. Each page shows the real bytes on the wire next to the text of the specification.
Open TR369.org
More than 25 articles with real samples
Request and response pairs you can copy, Protobuf definitions, every message type, every error code.
Read the articlesHow we work
Five rules we hold ourselves to. They are short because we expect to be judged on them.
The customer's problem comes first
We start by understanding what you are actually trying to do, then look for the simplest thing that does it. If the answer is "you do not need us for this", we say so.
Say what is true
Estimates, risks, what the product can and cannot do today. We would rather lose a deal than win it on a claim we cannot back up.
Do the work properly
Tests, reviews, documentation, and the boring parts of operations. The systems we build are meant to run for years without us standing next to them.
Treat people fairly
Different backgrounds and disagreeing opinions make better systems. We argue about designs, not about people.
Keep what we are told to ourselves
We see network topologies, subscriber counts and roadmaps. None of it leaves the engagement, and we follow the privacy rules that apply to it.
Everyone at Techufy is expected to follow these rules and to speak up, without any comeback, if they see them broken.