About
A content studio that reads like an engineering team.
Technical Growth Lab exists because devtool content now has to satisfy two readers at once — the developer deciding whether to trust you, and the model deciding whether to quote you — and almost nobody is staffed for both.
Companies our team has worked with and written for
Strapi
The open-source headless CMS. A Node.js and TypeScript content API that teams either self-host or run on Strapi Cloud.
strapi.io
OpenReplay
Open-source session replay and product analytics, built to be self-hosted so the recordings never leave your own infrastructure.
openreplay.com
Turing
AI research and talent infrastructure. Connects domain experts — engineering, science, medicine, finance — to the companies training and evaluating frontier models.
turing.com
Educative
Hands-on courses for developers: text-first rather than video, with the code editable and runnable in the browser. Strongest on system design, AI, and interview preparation.
educative.io
TestMu AI
Agentic quality engineering, and LambdaTest until the rebrand in January 2026. Its Kane AI agent writes, runs, and repairs end-to-end tests across web and mobile from a plain-language description.
testmuai.com
The premise
Two things that are usually kept apart.
On one side, content agencies that can produce volume but cannot run your product, and have no view on whether a page is extractable by an answer engine. On the other, engineers who can build anything but do not think about search intent, citation, or why anyone would read the thing.
We put the two in the same workflow. Machines do the sweep: the keyword landscape, the competitor coverage, the gaps in your own docs, the questions piling up in your issue tracker, and which sources assistants already cite for the queries you care about. That research is fast, broad, and genuinely better than what a person would do by hand in the same hour.
Then a person decides. What is worth writing, what angle survives a skeptical reader, where the product is weak and the piece needs to concede it. That judgment is the whole job, and it is the part we will never hand to a model.
Machine intelligence to find the questions. Human judgment to decide which answers are worth publishing under your name. That is the operating model, not a description of one.
How we work
Standards we hold regardless of the engagement.
We build before we write
Every tutorial and integration guide starts as a repository that runs on a clean machine. The article documents what happened, not what the docs claim should happen — which is also what makes it safe for a model to quote.
Audited before it reaches you
Every draft is checked against its brief for coverage, technical accuracy, and whether an answer engine could lift a clean answer from it. Quality does not depend on who happened to be free that week.
Friction gets reported
When your product fights us during a build, you get those notes. It is usually the most valuable part of the engagement and we do not charge for it.
We will tell you not to publish
If the honest answer is that a piece will not rank, will not convert, or will embarrass you in six months, we say so before it is written.
Who you work with
A small senior team, not a content mill.
Engagements are run by the people who write them. There is no account manager relaying questions to a freelancer pool, and no ghostwritten draft from someone who has never installed your CLI. If you are on a call with us, you are on a call with whoever will be building the work.
The logos above are that team's track record rather than a client list — companies whose developer content the people here have written, built, or edited. Select any one of them to see what they do.
Say hello
Worth a conversation?
Bring your site, your roadmap, and the thing you wish you had published six months ago. Thirty minutes is usually enough to know whether we are a fit.