# Boom — the first app on the network

> Boom is an AI screen recorder for macOS and Windows and the first application integrating GHAN. This documents every decision, every measurement and every number the integration will produce. The results section is empty on purpose, and dated.

Source: https://ghan.io/case-studies/boomshare/  
Published: 2026-09-22 · Updated: 2026-09-22  
Publisher: GHAN — the audited cross-promotion network for desktop apps (https://ghan.io)

---

### Read this before anything else

**Boom and GHAN share a founder.** Daniel Matalon builds both. That makes Boom a design partner, not an independent customer, and it means this document can prove the integration works — it cannot prove the network is popular. Those are different claims and we are only making the first one.

We are putting our own product through the gate, the SDK, the ledger and the fraud rules before asking anybody else to. A case study that buried that relationship would deserve to be thrown out the moment somebody checked, so it is the first thing on the page.

The partner

## Boom

An AI screen recorder and video editor. You record once; it trims the silence, cleans the audio, adds captions and a summary, and can dub the result into more than fifty languages in your own voice.

PlatformsMac · WindowsAlso iOS, Android and a Chrome extension. Only the two desktop builds are relevant here — GHAN is desktop-only.
ModelFreemiumFree tier with no card required, plus a Pro tier. A one-time-licence economy, not a high-LTV subscription one.
AudienceMakersIndie developers, course creators, designers, solo founders — people who install desktop tools constantly.
Integrations~30 toolsSlack, Notion, Drive, Zoom. A product whose users already expect it to hand off to other software.

Why this app first

## A screen recorder is an unusually good first member.

Not because it is ours. Three properties make it a better test of the design than a typical utility would be.

### Its users install things

Boom's audience is makers and course creators — people who tried four tools this month. GHAN's whole premise is that an app's users have *proven* they install desktop software. Boom's have proven it harder than most.

### Success is unambiguous

Most apps struggle to define first_success. For a recorder it is exact: processing finished and there is a shareable video. No judgement call, no proxy metric, no guessing when the person is actually pleased.

### Freemium needs non-cash acquisition

A free tier cannot outbid subscription products for clicks. Boom is precisely the app the [auction arithmetic](/compare/google-ads/) locks out, which makes it the right product to test whether paying in attention actually works.

The decision

## One slot. Four rejected.

GHAN offers five lifecycle slots. Boom enabled one, and the reasoning for each rejection is as much a part of the integration as the code.

Design mockup. The SDK has not shipped in a Boom release yet — see the status list below.

| Slot | Decision | Reasoning |
|---|---|---|
| `first_success` | **Enabled** | Recording processed, video shareable. Maximum satisfaction, unambiguous trigger. |
| `install_complete` | Rejected | Too early. The person has not yet had a good experience with Boom, so a recommendation is a cost with no earned trust behind it. |
| `update` | Rejected | Attention we already own, but release notes are not a moment of delight. Low value, non-zero annoyance. |
| `idle` | Rejected | Cheapest inventory in interruption terms and the lowest-converting. Not worth making the product feel busier. |
| `uninstall_intent` | **Deliberately off** | GHAN allows same-category placements here and it converts well. Boom would rather forgo the earning than show a competitor to somebody who is leaving. |

Plus the controls Boom set, all enforced client-side in Boom's own signed build rather than by GHAN's server: **one card per week maximum**, screen-recording and video-editing categories excluded entirely, and telemetry gated on Boom's existing consent state so nothing is emitted before a user has agreed to measurement.

The gate

## Boom passes the same five checks as everyone else.

Being the founder's own product buys nothing here. The gate is automated and re-runs weekly.

| Check | Requirement | Boom |
|---|---|---|
| Code signature | Notarised macOS build, or a valid Windows Authenticode chain | Ships signed installers for both |
| Malware | No malicious or suspicious detections above threshold | Clean |
| Domain age | At least six months, verified over RDAP | `boomshare.ai`, well over |
| Contact | An address that answers a challenge | Verified |
| Binary identity | Download URL serves the declared bundle id | Verified per platform |

If Boom lets a certificate lapse, the weekly re-run removes it from the network like anybody else. There is no allowance for being first.

The integration

## One dependency, two calls.

```js
import { ghan } from '@ghan/sdk'

await ghan.init({
  appId: process.env.GHAN_APP_ID,
  consent: settings.analyticsConsent,          // nothing emitted while false
  excludeCategories: ['screen_recording',      // never a competitor
                      'video_editing'],
  maxPerWeek: 1,                               // Boom's cap, not GHAN's
})

// Called from exactly one place: the post-processing success handler.
onRecordingReady(async (video) => {
  showShareActions(video)
  await ghan.slot('first_success')             // returns false if capped
})
```

The protocol handler is registered in the packaging config so attribution survives the browser hop, and the handoff file covers machines where the handler is blocked by policy.

```json
{ "protocols": [{ "name": "GHAN", "schemes": ["ghan"] }] }
```

The mechanism

## What happens when someone clicks.

Boom's SDK signs the impression. The partner app's SDK signs the claim. Neither can produce the other's signature, and GHAN can produce neither — which is why Boom can verify its own earnings against keys generated inside its own signed binary rather than trusting a dashboard. [The full mechanics](/guides/desktop-install-attribution/).

The results

## Empty, on purpose.

No installs have been traded on GHAN. Every row below is generated from the ledger when the data exists, and prints nothing until then.

done**Gate passed.** Signature, malware, domain age, contact and binary identity all verified. Re-runs weekly.
done**Slot decided and instrumented.** Boom's activation and retention baselines are being recorded *before* the first card renders, so any effect on Boom's own product is measurable rather than arguable.
next**Ship the SDK in a signed Boom release.** The one step GHAN cannot do — third-party code entering a binary Boom signs is Boom's decision.
then**First cleared install, 48 hours later.** Clearing rate and credits earned appear here, generated from get_ledger.
then**First cohort at D30.** Retention of referred installs, against the methodology in the [retention guide](/guides/referred-install-retention/).

Projection, not a result

## What we think will happen, with the assumptions exposed.

This is a model. Every input is a guess, each one is shown, and all of them are ours rather than observed. Substitute your own and the output changes — that is the point of printing them.

| Assumption | Value | Where it comes from |
|---|---|---|
| Weekly active desktop users eligible for a card | 1,000 | Placeholder. Boom's real figure replaces it. |
| Share reaching `first_success` in a week | 55% | Guess. Recorders have high task-completion rates. |
| Frequency cap | 1 / week | **Real** — Boom's setting |
| Click-through on a templated card | 3% | Guess, at the pessimistic end of in-app recommendation rates |
| Click → install claim | 45% | Guess. Loses people to the download-later path. |
| Claim → cleared at 48 h | 60% | Guess. GHAN's whole thesis is that this number is the one that matters. |
| Partner category CPI | EUR 24 | **Real** — mid-point of the published creator-tools floor |
| Boom's share | 70% cash, 84% as credits | **Real** — published rate |

**Output of the model:** roughly 550 impressions, 17 clicks, 7 claims and **4 cleared installs per week**, earning Boom about **EUR 67 in cash or EUR 81 in credits per week**.

That is a small number, and printing it small is deliberate. A network is worth joining at this scale only because the inventory costs nothing to supply — one card a week, at a moment the app chose, to people who were already happy. If the real figures come in at half the model we will publish that too, in this section, with the same assumptions table beside them.

Risk

## What would make Boom turn this off.

A measurable effect on Boom's own retentionThe reason baselines are recorded before the first card renders. If Boom's activation or D7 retention moves against the baseline, the placement goes off and the finding gets published here — including if the effect is small.
ComplaintsComplaint rate feeds the behaviour score automatically and throttles an app above threshold. For Boom it is also a product signal: one card a week should be invisible, and if it is not, the cap was wrong.
A partner Boom would not recommendWhat the gate exists to prevent and the kill switch exists to fix within one fetch cycle. Boom also excludes two whole categories client-side, in its own build, where GHAN's server cannot override it.
The economics not workingFour cleared installs a week is not a business. If the real numbers come in far below the model, the honest conclusion is that cross-promotion needs more members before it is worth anyone's slot — and that conclusion gets published here too.

Next

## Be the app on the other side of this.

Boom cannot trade with itself. The first real chain needs a second desktop app, and that partner gets the same page written about their integration — decisions, instrumentation, risks and all.

[Become a founding partner](/get-started/)[How you verify any of this](/transparency/)


## Questions people ask about this

### Is this a real case study or a projection?

It is a real integration study and an explicitly labelled projection, kept strictly apart. The integration decisions, the slot choice, the exclusions, the frequency cap, the consent gating and the instrumentation are all real and documented here. The results section contains no numbers because no installs have been traded. There is one projection section, and every assumption in it is shown so you can substitute your own; it is a model, not a result, and it is labelled that way on the page.

### Why are there no results?

Because none exist. GHAN has not cleared a single install. Publishing a results table now would require inventing it, and the entire product is sold on the claim that every number we publish is reproducible from signed data a partner already holds. A fabricated case study is the one thing that claim cannot survive. The empty table with dates against each row is a more honest artefact than a full one would be, and it is the first test of whether the positioning means anything.

### Doesn't GHAN own Boom?

Yes, and stating that up front is the point. Boom and GHAN share a founder, Daniel Matalon. That makes Boom a design partner rather than an independent customer, and it means this study proves the integration works, not that the network is popular. We are running our own product through the gate, the SDK and the ledger before asking anyone else to. Any case study that hid that relationship would deserve to be dismissed the moment somebody checked.

### What is Boom?

Boom is an AI screen recorder and video editor for macOS, Windows, iOS and Android, at boomshare.ai. It records once and then trims silence, cleans audio, adds captions and summaries automatically, dubs into 50-plus languages, and integrates with around 30 tools. It is freemium. Only the macOS and Windows desktop builds are relevant to GHAN, because GHAN is desktop-only.

### Which lifecycle slot did Boom choose and why?

first_success, and nothing else. For a screen recorder that moment is unusually well defined - the recording finishes processing and the person has a shareable video. It is the point of maximum satisfaction and the only moment in the app where a recommendation is plausibly welcome. install_complete was rejected as too early, update and idle as unearned interruptions, and uninstall_intent was left off because Boom would rather lose the earning than show a competitor to somebody leaving.

### What would make Boom turn this off?

Three things, all already built. A complaint rate above threshold, which feeds the behaviour score automatically. Any measurable effect on Boom's own activation or retention, which is why those are instrumented before the first card renders. Or a single partner app turning out to be something Boom would not personally recommend, which is what the vetting gate exists to prevent and the kill switch exists to fix within one fetch cycle.

### When will there be numbers?

The clearing rate and credits earned appear 48 hours after the first install claim. Impressions, click-through and fraud rejections appear on day one of serving. Cohort retention at D7 and D30 appears 30 days after the first claim. No rate is published below a 200 cleared-install sample; under that the page prints insufficient sample rather than a number.