// pillar
Growth and Demand
The decision this page exists for is a narrow one. Which growth service you buy first, and what it has to prove before you buy a second. Six sit under this hub, and starting all six at once makes the result unattributable and the invoice look busy.
Order is decided by where your funnel is losing money, not by which channel is easiest to switch on next Monday.
Two neighbours first, so you do not spend the next ten minutes on the wrong page. Whether crawlers and answer engines can find and quote you at all belongs to the visibility hub. The product itself, meaning anything we write and ship as code, belongs to the build hub. If strangers cannot find you, or the thing you mean to sell does not exist yet, start in one of those.
One boundary gets crossed constantly, so it is worth stating plainly: organic acquisition aimed at engineers lives here, not in the visibility hub. GitHub marketing and developer marketing are both on the list of six below. The visibility hub owns crawlers, rankings and citations inside generated answers. It does not own your repository, your release notes, your docs or your quickstart. If your plan is to reach developers in the places developers already spend their time, you are on the right page.
Which of the six you need
Each is bought on its own, has its own measure, and can be run without the other five.
- SaaS marketing. Buy this if you sell a subscription and nobody in the building can say what a customer costs or which motion produced them. It is the whole funnel, positioning through renewal, not a single channel bought under a broad name.
- Media buying. Buy this if you have an offer that already converts. The question is whether the spend caused the growth or merely took credit for it. Paid distribution only. The organic routes are further down this list.
- Conversion rate optimization. Buy this if the traffic arrives and leaves. This is work on the pages you already have, shipped as code behind a flag, not a deck of recommendations handed to your engineers.
- GitHub marketing. Buy this if your product is installed and not signed up for, and the repository is the first thing an evaluator opens. Releases, registries, awesome-lists, and the question of how many of those installs are still there a week later.
- Developer marketing. Buy this if your buyer reads the reference docs before the homepage and judges you on whether the quickstart runs. Broader than the repository: docs, sample code, the path from a first key to a key that is still in use.
- Vibe-coded app launch. Buy this if the thing already works, was largely written by an AI coding tool, and has never met a stranger. Security, hardening and launch. It is not a rebuild.
If none of those descriptions is uncomfortably accurate, the constraint is probably somewhere else and the right answer is to buy nothing here yet. We would rather say that on the call.
Why these six belong together
Each takes attention that already exists somewhere and moves it one stage closer to a conversation with a buyer. That attention sits in a search result, a feed, an ad auction, a package registry or a README. They intervene at different points, which is why they are separate purchases, but they resolve to the same number.
Impressions, sessions, stars and followers are inputs. Pipeline is the output. The cost of producing a unit of it is the only honest basis for comparing two of these against each other.
Why one team does the marketing and the code
Most growth work is blocked on an engineering change. A new landing page. An event that fires server-side because the client-side one is being stripped by an ad blocker. A quickstart that compiles. A signup flow that does not lose a third of the people who start it. A marketing vendor writes that up as a recommendation, sends it to your engineering team, and waits, because they cannot open a pull request.
We can. The same engagement that designs the experiment ships the variant. That is the whole argument for this hub existing as one thing instead of six retainers.
Where we stop
A channel recommendation made before the constraint is known is a sales pitch with a media plan attached, so we do not make one.
A test your traffic cannot resolve inside a sane window does not get run. It would still produce a number, and that number is noise wearing a winner’s badge. The answer in that case is that the experiment is unavailable at your volume. That is a real finding, and cheaper than acting on the noise.
Readouts are against pipeline. A month that produced none says so on the first line, above the activity that did happen.
Your ad accounts, your analytics and your repository are yours during the work and after it. None of it is ever held over you. An agency that has to be fired carefully is one that already knows how its work looks under inspection.
We will not attach a number and a date to a result nobody can measure yet. Before the measurement exists, a forecast is decoration. A decorative forecast gets read back to you in month four as though it had been a commitment.
What you get
- A diagnosis of where your funnel loses money now, produced before anyone proposes a channel to spend on
- One measurement spine shared by every service in this hub, with events defined once and recorded server-side so an ad blocker cannot delete your data
- A sequenced plan naming which of the six services runs, in what order, and what each one has to prove to keep running
- One team for the marketing and the code it depends on, so a landing page, event or docs change never waits on a second vendor
- A monthly readout of pipeline by source that includes the experiments that failed and what they cost
- A written kill condition per workstream, agreed before it starts, so stopping is a decision instead of an argument
How it runs
- 01
Find the constraint before choosing a channel
A funnel has one binding constraint at a time. Buying more traffic when the bottleneck is activation converts budget into nothing. So we locate the limiting stage first, then say which of these services is irrelevant to you this quarter.
- 02
Instrument before spending
Attribution decided after the money is spent is a story, not a measurement. We define the events once, record them server-side, and agree what will count as a result while nobody yet has a stake in the answer.
- 03
Run the smallest sufficient set of services
Every additional workstream costs attention and makes the result harder to attribute. We run the fewest that address the constraint, in sequence. Opening six fronts at once makes the invoice look busy and the result unreadable.
- 04
Ship the code the plan depends on
Most growth work is blocked by an engineering change nobody has time for. We deliver those as pull requests into your repository, reviewed by your engineers. A plan that waits for a sprint slot is a plan that does not happen.
- 05
Report against pipeline and cut what fails
Each cycle ends with what moved, what did not, and which workstream hit its kill condition. Reporting activity instead of pipeline is how agencies stay hired for two years without ever being tested.
Questions we get asked
- Do we have to buy the whole hub?
- No. Each of the six services is bought on its own and has its own measurement. The hub exists to answer a different question, which is what applies to your business right now and in what order. Starting with one service is the normal way in.
- How is this different from hiring a specialist agency per channel?
- A channel specialist stops at the edge of their channel. The landing page, the event tracking, the documentation and the signup flow sit on the other side of that edge. In your codebase, waiting on your engineers. We do both halves, which removes the handover where most of the delay and most of the blame lives.
- What if the real problem is our product, not our marketing?
- Then we will say so, and the work belongs in the build hub or nowhere. Demand generation applied to a product that does not retain buys you a faster churn rate. We would rather lose the engagement than sell spend against a leaking bucket.
- Can you show us client results and numbers?
- No client is named anywhere on this site and we do not publish percentage gains you cannot audit. That is a standing decision, not an absence. Judge the work on the plan, on the measurement we agree before it starts, and on what we tell you we will not do.
- Who owns the accounts, the data and the code?
- You do, throughout. Campaigns run in your ad accounts on your billing, with your team holding admin. Analytics is your property. Every code change lands in your repository as a reviewed pull request. Nothing we build is hostage to us staying hired.
- How long before this produces pipeline?
- It depends on which constraint binds. Conversion and activation work can move within weeks because the traffic already exists. Paid tests need enough volume to resolve, and content and developer channels compound over quarters. We state the expected run length per workstream before you commit, and we will not shorten it to make the proposal sound better.