Impulse — Launch Plan¶

Drafted: August 2026 | Revised: 2026-08-21 — timeline moved four months; see §6 Target ship: September 2027 (communicate October to backers) Kickstarter: 1 March 2027, 30 days | Advertising budget: $2–5k (BUD-ADS, §9)

1. What We're Actually Launching¶

A hardware commitment device: a watch, 1–5 anchors, and a mobile app that enforce commitments you set for yourself in advance. The defining property is that the enforcer is not the thing being bypassed — remove the watch and anchors take over; the watch, not the app, adjudicates schedule changes; loosenings are delayed a day while tightenings apply instantly.

This is a bigger product than "ADHD smartwatch," and the positioning should reflect that. Self-binding is the category. ADHD is the beachhead.

Primary demo: Sunrise Lock¶

The overview already identifies it, and it's the right call. The alarm you can't snooze, because the alarm isn't on your nightstand — it's the whole room. It is instantly legible, physically dramatic, films in seven seconds, and solves the most relatable problem in the category. Everything in the content plan is built on this clip.

Secondary demo: phone-distance commitments — we don't block the distracting apps, we keep the phone out of your hands. Strong on its own, and a sharper story than every app-blocker on the market.

2. Audience — Revised¶

Three distinct audiences, reached through different channels with different language.

Audience	Why they buy	Where they are
Adults with ADHD (beachhead)	Takes the all-day project of self-management off their plate	TikTok, IG, ADHD podcasts, ADDitude, coaches, r/ADHD
Technical / self-binding	The mechanism itself is the appeal; the threat model is interesting	HN, Lobsters, Hackaday, Hackster, GitHub, rationalist-adjacent blogs
Broad self-improvement	Sleep, gym, screen time, students, remote workers, parents	YouTube, paid social, newsletters, retail

Why the technical overlap is genuinely large¶

This was under-weighted in the previous draft. Impulse is not a wearable with a hacker skin on it — it is a product whose core concept is native to technical culture:

Commitment devices are a tech-native idea. Ulysses contracts, akrasia, precommitment — Beeminder and StickK have small, devoted, overwhelmingly technical followings. This audience has been discussing self-binding for fifteen years and has never had good hardware for it.
"The root of trust is the watch, not the app" is a threat-model story. That's a Show HN, not an ad. The adversary is future-you; the design question is which component to trust and what to fail open on. Elapsed-time timers so winding the clock ages nothing, quarantining loosenings in firmware, fail-open on degraded links, credential sharing scoped to scheduled anchors — this is real security architecture and it will be read as such.
Anti-phone hardware has a devoted tech following. Brick, Light Phone, Daylight, Freewrite. Physical solutions to software problems are a recognised genre.
The engineering is interesting on its own terms. BLE proximity, servo lockdown, anchor local schedule persistence with midnight recomputation, WiFi self-repair from a charging watch.
Open-source firmware + hackable anchors gives you the Flipper path: community apps, custom commitment types, third-party anchors.

Strategic consequence: the technical channels move up in priority, and they are also your best email channels (see conversion table in §7). Lead ADHD-forward on social video, self-binding-forward on HN/Hackaday, outcome-forward on paid.

A large bonus: the Meta ad problem mostly dissolves¶

The previous plan had to route around Meta's personal attributes policy, which prohibits ads that directly or indirectly assert or imply a person's disability or mental health condition — with enforcement expanded in early 2026 to indirect third-person framing like "for people managing X."

Impulse's own house voice already avoids this. Stop negotiating with yourself. Get your mornings back. Keep the promises you make to yourself. None of that names a condition, and all of it is what the voice guide says to lead with anyway. So the compliant framing is not a workaround — it's the brand.

Rule stands: ADHD language lives in organic content, site copy, email, and creator videos. It never appears in paid creative. Never boost a creator post where they say "as someone with ADHD, this is for us."

Medical-efficacy claims remain off the table entirely, per the overview and per FTC/FDA exposure.

3. Unit Economics¶

Item	Watch	Anchor
BOM at scale	~$15	~$16
Landed (×1.5: packaging, strap, charger, PSU, freight, duty, cert amortisation)	~$23	~$24

Per-order: fulfilment/shipping $8–12, processing ~3%, support + warranty/returns reserve $8–15. Hardware returns run 8–15% and returned wearables aren't resalable at full price.

Not in COGS and easy to forget: ongoing app development and cloud costs across iOS and Android. The app is a hard dependency — no app, no product — and it's the single largest recurring expense. This is the strongest argument for a subscription tier (§4).

Note: the anchor now costs slightly more than the watch, which is unusual but plausible given the servo, speaker, wall PSU, and backup battery. Worth one engineering pass anyway — every dollar off the anchor BOM compounds across a 1–5 unit attach rate.

4. Pricing¶

Retail (post-campaign)¶

SKU	Price	Landed	Contribution
Starter (watch + 1 anchor)	$199	~$47	~$122
Complete (watch + 3 anchors)	$299	~$95	~$155
Whole home (watch + 5 anchors)	$379	~$143	~$180
Single anchor	$59	~$24	~$21
Anchor 2-pack	$99	~$48	~$30
Anchor 4-pack	$179	~$96	~$52

Anchor prices went up from the previous draft because anchor landed cost rose to ~$24. At $49 a single anchor nets only ~$10 after fulfilment and reserve — too thin to be worth shipping. $59 is the floor.

Never sell the watch alone. One anchor is the minimum for a working Sunrise Lock, which is the whole reason people buy.

Per-customer contribution: 122 + (n × 21) for n additional anchors. At n=2, ~$164 against a target CAC of ~$110.

Margin logic unchanged: the watch carries the entire CAC; later anchors have near-zero acquisition cost. But the anchor is core, not an accessory — closer to a Hue bulb than a Flipper case. Price it for attach rate, because multi-anchor households are your retention and word-of-mouth engine.

The subscription case is now stronger¶

$149 hardware + $8–10/month. At ~$23 landed you still take ~$105 on hardware plus recurring margin, supporting a CAC of $120–140. The app is genuinely ongoing work and genuinely where the value lives — this is honest, not a squeeze.

But: the overview's own voice guide warns against anything that feels like coercion, and a subscription on a device that already constrains you is a delicate combination. If you go this route, cancellation must be trivial, and the hardware must keep enforcing existing schedules if the subscription lapses. A commitment device that stops working when you stop paying is a very bad headline.

Crowdfunding ladder¶

Tier	Price	Retail equiv.	Contribution
Early bird starter (cap ~400)	$119	$199	~$37
Starter — watch + 1 anchor	$135	$199	~$52
Complete — watch + 3 anchors	$209	$299	~$70
Whole home — watch + 5 anchors	$269	$379	~$82
Founder's edition (cap ~100)	$369	—	~$170
Add-on: 2 anchors	$69	$99	~$20

On your $125 target: it works, but at the revised costs it yields only ~$43 contribution against a ~$110 CAC-equivalent of effort. $135 is the better number — still 32% off retail, still under the $150 psychological line, and it buys back roughly $4,500 across 500 backers. If you want $125 for the round-number appeal, take it out of the early bird instead and hold the main tier at $135.

Incremental anchor pricing stays ~$35 per unit across tiers. Consistency reads as fair; irregularity reads as manipulation.

Early bird is identical contents, capped, ~$16 cheaper. Its job is day-one urgency and the "X of 400 left" counter. Size it to sell out in 24–48 hours. Consider an exclusive colourway instead of only cutting price.
Founder's edition — whole home kit, early firmware access, private dev channel, input on features, name in the repo contributors file, first access to the hardware spec. Near-zero marginal cost, seeds the open-source community, lifts average pledge.
Metric to optimise is average pledge, not backer count. Flipper's was $128.54 against a $119 early bird — their tiers barely lifted it. This ladder should land $165–185.
Set the goal at $15,000. 66.4% of successfully funded Kickstarter projects had goals under $10k. Low goals fund fast, and "funded in 3 hours" is a headline. Real ambition goes in stretch goals — Flipper tied theirs to features and unlocked everything the next day.
Cap tiers at six. Decision paralysis is a defining trait of the beachhead audience.

Pricing discipline: Flipper launched at $169 and now sells at $199, having never discounted. Frame the campaign price explicitly as X% off the $199 retail so retail never reads as a hike.

5. Regulatory (FCC)¶

What pre-certified modules buy you¶

2026-08-08 — the modules are now specific, one of them is not certified yet, and there is a fallback. The board ordered 2026-08-07 uses two Fanstel modules: BM20C (Bluetooth, nRF54LM20A — also the host MCU) and WM02C (WiFi). One vendor, so both integration-guidance requests go on one thread.

Asked on 2026-08-04, Fanstel replied: "We plan to complete FCC testing of BM20C this month. We ordered nRF54LM20A and B a few months ago. There is no confirmed ship date yet." That is two risks, not one — the grant, and the underlying Nordic silicon supply. Everything in this section is contingent on the first; the schedule is contingent on the second. Get the grant number in writing before booking a lab slot. Tracked as BLK-15.

2026-08-11 — v1 ships with WiFi. Decided by the author, closing a question that had been open since the 2026-08-09 log weighed dropping the WM02C from the first run to save ~$5 of BOM on both the watch and the anchor and to simplify certification. The reason it stayed open is that the saving is real and compounds across a 1–5 anchor attach rate; the reason it closed is that WiFi turned out to be carrying more than the two criteria it appears to carry. In the author's words: "it simply sacrifices too much on this product's mission."

The specific thing it carries is the WATCH_REMOVED notification (firmware_spec_v3_nrf.md §1.5). Sunrise Lock's known bypass is to leave the watch far enough away that BLE cannot reach it and go back to bed — and the mitigation is the watch telling the anchor it has been taken off, over a transport that by construction has to outreach BLE. WiFi is the only one on the board. Channel sounding does not substitute: it makes an in-range distance honest, and the attack is about not being in range.

Two consequences for this plan. The BOM stays at ~$15/$16 rather than falling to ~$10, so BLK-09 and BLK-11 are costed against the WiFi build. And the SAR question in §5 stops being optional — 2.4 GHz WiFi cannot be excluded at Fanstel's declared power, so shipping the module means paying for a SAR test or cutting declared power ~8 dB, and the range that cut spends is the range the notification above depends on. That trade is now on the critical path rather than a contingency.

The fallback is the BC15C (Nordic nRF54L15) — believed footprint-compatible with the BM20C and already FCC-certified. Its datasheet was filed 2026-08-09 and settles the question that mattered most: it supports channel sounding, so the whole proximity design survives the fallback rather than reverting. Two real costs remain. It cannot drive the WM02C, so a BC15C build is a watch with no WiFi — the getOnWifi / getOffWifi criteria and the §5.5.3 anchor-WiFi repair both disappear. And it halves RAM (256 KB against 512 KB), which is the exact constraint that prompted moving off it. Still, it converts "the campaign is blocked on someone else's certification" into "the campaign ships a smaller product," which is a far better position to be standing in.

Confirm the part number before ordering or quoting: the filed datasheet is titled BC15C, earlier notes say BM15C, and Fanstel's BC15/BM15 naming is dense enough to get wrong by one letter.

Approach the labs accordingly: quote the BM20C build as the primary, and ask what a delta re-test to a no-WiFi BC15C variant would cost if the BM20C grant slips. Labs price this kind of contingency routinely, and asking now costs nothing — asking in October, after OCT-05 has booked the slot, costs the schedule. Expect that delta to be negative on the RF-exposure line — see the SAR result below.

2026-08-09 — both datasheets read end to end. Three things changed, and the integration-guidance request was never needed. Full working in Concepts/FCC Certification.md.

The WM02C is already certified — FCC ID X8WWM02C, ISED 4100A-WM02C, TELEC 201-240555, printed on page 1 of a Ver 1.00 production datasheet. Half of BLK-15's regulatory risk was never real. The BM20C's draft datasheet (Ver 0.82, Jul 2026) has all five certification rows blank, which is the other half in writing, from the vendor, dated.

The Part 15B integration guidance is in the datasheets (BM20C p.17 and p.27, WM02C p.12) and always was. AUG-11 is discharged by reading them, not by asking. Board V1 already violates one rule: the WM02C's 7.4 mm chip-antenna area must overhang the board edge and instead sits over the four-layer stackup. Cheap on a prototype; tracked in Todos.md.

Part of the WM02C's grant condition is source code — certified gain and band-edge backoff settings the host application must reproduce (NCS ≥ 2.6.1). Recorded in firmware_spec_v3_nrf.md §1.1 as a normative constraint, because obligation 3 below makes it a $35k mistake and it is otherwise invisible until a lab finds it.

2026-08-11 — the first lab replied, and obligations 2 and 3 below turn out to be the same obligation. Washington Laboratories sent back the actual X8WWM02C grant. It is a mobile grant: at least 20 cm from all persons. The watch breaks that condition, so the WM02C's modular approval does not cover it — and no SAR arithmetic changes it, because it is a clause on the grant rather than a consequence of the power figure.

Corrected 2026-08-12. This note originally said the grant also forbade co-location with another transmitter, and that the watch broke both conditions. That was a misreading, caught by the user on the sensible grounds that the WM02C is sold as a WiFi companion module for the nRF54 series. The grant sentence ends "except in accordance with FCC multi-transmitter procedures" — co-location beside the BM20C is permitted, via the simultaneous-transmission evaluation in KDB 447498 D01 §4.4. One condition is broken, not two. The permissive change is still required, for the exposure category alone. Fixing it needs a Class II permissive change, which only the grantee (Fanstel) may file; the lab's recommended route is a change of ID, where Fanstel authorises you to hold your own FCC ID for the module and you then file your own permissive changes. Full reading in Concepts/Module Grant Conditions.md.

Three consequences for this plan. The grant declares 0.17 W, not the datasheet's 18.24 dBm — the 2.4 GHz exclusion ratio is 53, not 26.2. §12.5's $15k → $35k permissive-change scenario stops being the failure case and becomes the baseline path for a WiFi watch, though the scope is narrower than a full re-certification. And the 2026-08-11 "v1 ships with WiFi" decision above was made against a §5 that priced this as "8 dB of range or a SAR test" — the WATCH_REMOVED reasoning is untouched and still correct, but the other side of the ledger has moved and the decision deserves re-opening on the new number.

⚠️ The urgent item is neither of those. Fanstel is filing the BM20C's certification this month — now. If they file it mobile-only the way they filed the WM02C, then the BLE-only fallback is not SAR-excluded by calculation alone either, and the claim to that effect in obligation 2 below, in BLK-15, and in Concepts/FCC Certification.md §5 is unsafe. Asking them to scope an open filing for portable body-worn use is free; asking after it grants costs a permissive change. drafts/fanstel-followup.md does not currently ask it.

⛔ 2026-09-20 — the conditional resolved, and it resolved the bad way. X8WBM20C granted 2026-09-11, mobile, carrying the same "at least 20 cm from all persons" clause as X8WWM02C. The paragraph above was written on 2026-08-11 as a risk; it is now a description. Two things follow and both are corrections to text elsewhere in this document. First, "the BLE-only fallback is SAR-excluded by calculation" must now name its module — it is true of the BC15C (X8WBC15, evaluated portable under §2.1093, 2.82 against 3.0) and false of the BM20C, so obligation 2 below and Concepts/FCC Certification.md §5 are unsafe exactly as predicted. Second, wornness-gating (§4.1 of Concepts/FCC Respin.md) cannot reach this one: it was an argument about the WiFi radio, which is off the wrist by construction, and the watch transmits BLE while worn because that is the enforcement channel. The permissive change on BLE is unconditional. Source and caveat in docs/agent-notes.md, 2026-09-20 — it came off the public record rather than from Fanstel, and the FCC's own search was unreachable.

✅ 2026-09-22 — the grant note read verbatim, and it carries the multi-transmitter exception. The note above quoted the 20 cm clause as far as the source went. The full text reads "…at least 20 cm from all persons and must not be co-located or operating in conjunction with any other transmitter, except in accordance with FCC multi-transmitter product procedures." So the 2026-08-12 correction boxed above applies to the BM20C as well as the WM02C, and on evidence rather than by analogy: one condition is broken on each module, not two, and it is the exposure category both times. Co-location of the two radios on one board is permitted under both grants via KDB 447498 D01 §4.4 — which is the arithmetic Concepts/FCC Certification.md §5 has already done. Nothing in this correction reduces the permissive change the paragraph above describes; it stops the scope of that change from being overstated to a lab, which is not a small thing when §12.5 prices scope at $20k. Two practical items came with it. The grant's exhibits include an MPE report and a model difference letter covering the ten BM20* variants — those are the two documents AUG-12's labs will ask for first, and they are downloadable now. And Fanstel's own BM20C page now lists ISED 4100A-BM20C and TELEC R201-260622 alongside the FCC ID, and states "Availability: Production 09/2026" — a vendor availability line, not a confirmation to you, but the first plausible answer the ship-date half of BLK-15 has had, and an easy thing to ask SEP-13's conversation to confirm. The caveat on the 2026-09-20 note stands and got sharper: apps.fcc.gov and fccid.io both returned 403 again on 2026-09-22, by two independent network paths, so this is corroborated across three reads of one mirror plus search and is still not confirmed against the FCC database. Do that before a lab quotes off it.

Two pre-certified modules (WiFi, Bluetooth) let you skip getting your own FCC ID for the radios. Three obligations remain:

Part 15 Subpart B (SDoC) on the finished product. Where a host is authorized as an unintentional radiator and a module is added, the host manufacturer is responsible for the installed module's Part 15B compliance — and the module grantee must supply integration guidance. ~~Request both guidance documents now~~ — done 2026-08-09: both are in the datasheets already filed. The remaining work is the SDoC testing itself, which needs a lab.
RF exposure — the real risk. Body-worn devices need SAR or an MPE evaluation. The watch is a portable, wrist-worn device. 2026-08-09 — the exclusion calculation is done, and the guess above was right. Under FCC KDB 447498 D01 §4.3.1, at the 5 mm separation a wrist device is floored to: - BLE clears — +8 dBm with tune-up gives a ratio of 2.5 against a 1-g threshold of 3.0. No SAR test. - 2.4 GHz WiFi does not, and not marginally — 26.2 against the same threshold at the datasheet's declared power, and it stays over 3.0 at every separation a watch can offer. 5 GHz is 7.3. Three ways out, and the third reframes the fallback: cut the declared WiFi TX power in firmware to ≤ +9.8 dBm (costs ~8 dB of range, and the criteria that depend on WiFi range with it); test SAR; or ship BLE-only, which is SAR-excluded by calculation alone — no test, no phantom, no 1–2 weeks, no failure-and-retest risk. Working in Concepts/FCC Certification.md §5. Still to confirm with the TCB: whether the wrist is treated as an extremity (threshold 7.5 rather than 3.0), and whether BLE/WiFi coexistence arbitration is accepted as preventing simultaneous transmission. Both change the scope of the quote and both are free to ask.
Staying inside the module grant conditions — same antenna, gain, trace layout, separation. Deviation triggers a Class II Permissive Change requiring grantee cooperation and full intentional-radiator retesting. The $35k scenario.

Watch vs Anchor¶

Shared PCB helps but won't yield one report — Subpart B emissions depend on enclosure, cabling, and power arrangement, and these differ on all three. Expect worst-case configuration testing covering both as a product family, with a reduced delta test on the second.

Exposure categories diverge entirely: the anchor is wall-powered and stationary, so it can likely claim 20 cm separation and be evaluated under MPE (cheap). The watch cannot.

Additional wrinkle from the spec: the anchor contains a servo and a mains PSU. Ask the lab whether the motor drive affects conducted/radiated emissions, and confirm whether your PSU arrangement pulls you into any additional conducted-emissions scope.

Scope it yourself as: one PCB, two host configurations, two exposure categories. Get three quotes — 2–3× spreads on identical scopes are common.

2026-08-09 — the quote form is already filled in. Concepts/FCC Lab Quote Responses.md holds paste-ready answers for a lab's intake form: product description, every operating mode, cable counts, dimensions and electrical, and the additional-information block carrying the three TCB questions and the BLE-only delta request. Use it unchanged across all three labs — identical scope text is what makes the three numbers comparable, which is the entire point of getting three. Two blanks are yours to fill (cell capacities, enclosure dimensions and weights) and the document says so in place.

Two corrections it forced, both worth knowing outside the FCC context: only one of the two modules is certified (say so on the form — the lab will look both IDs up), and the anchor carries a backup battery, because an anchor you can defeat by pulling the plug defeats Sunrise Lock at exactly the moment it matters. The second contradicted firmware_spec_v3_nrf.md, now fixed there at v0.5.

2026-08-10 — the launch is US-only, and the quotes are scoped to that. Decided by the author. No CE/RED and no ISED in the certification scope for launch; both are left unchecked on the intake forms rather than annotated, because a conditional on a quote form becomes a line item. Neither module carries a CE/RED grant, so the EU was never a free ride off the modules — it is a separate body of work whenever it happens. Canada stays comparatively cheap later on the strength of the WM02C's 4100A-WM02C, and nothing here forecloses either market; it keeps the three quotes comparing the same work. The covering emails, the lab shortlist for quotes 2 and 3, and the reasoning are in drafts/fcc-lab-quote-request.md.

Timing¶

Stage	Duration
Lab booking lead time	2–6 weeks ← binding constraint
Pre-scan	1–2 days
SAR exclusion analysis	days (desk work)
Subpart B SDoC testing	1–3 days
SAR testing if required	1–2 weeks
Report writing	1–2 weeks

6–10 weeks booking to signed report if everything passes. Each failure adds 3–6 weeks. You'll need 2–3 production-representative samples; labs can reject hand-soldered prototypes with different stackups.

2026-08-21 — certification now happens after the campaign, and that is a deliberate sequencing decision rather than a deferral. The §6 timeline puts the lab booking in mid-March 2027 (during the campaign, once it is visibly funding) and the testing in May–July, funded by money that exists. This is the §12.4 principle applied to the whole certification rather than just the pre-scan: don't spend on certification that might fail, and don't spend it on a product nobody has committed to.

Three things are explicitly carved out of that deferral, because they are somebody else's calendar rather than a purchase:

The WM02C change-of-ID (see the 2026-08-11 note above). A Class II permissive change can only be filed by the grantee; the lab's recommended route is a change of ID in which Fanstel authorises you to hold your own FCC ID. This is a negotiation, not a transaction, it is the baseline path for a WiFi watch rather than the failure case, and it must start in September 2026 — tracked as SEP-13, concluding at SHIP-05. Starting it in April 2027 is how a five-month buffer becomes zero.

⛔ ~~Scoping Fanstel's open BM20C filing for portable body-worn use.~~ Free while the filing is open, a permissive change afterwards, and their filing month is now. SEP-12. — Expired 2026-09-11 when the grant issued, mobile. The carve-out was right and the item was never actioned; what it was protecting now belongs to item 1, which becomes a two-module change-of-ID conversation rather than a one-module one.

Lab quotes. Free, comparable only if all three answer the same scope text, and they age well. AUG-12.

And one that is arguable: the pre-scan (FEB-05). It sits in February 2027 on deposit money, ahead of the campaign, because ~$1–2k is the smallest useful bet in the plan and a failure found in February changes the campaign while the same failure found in June changes the ship date.

This is where the board revision matters. The current revision pin-shares the vibration motor and LED ring. Certify the shipping revision, not the prototype. Testing the wrong board means retesting.

2026-08-08: "Impulse Board V1" (ordered 2026-08-07) is a bring-up prototype, not the shipping revision — the author's own correction: "final as in this board will have 100% functionality for me personally… not final as in this is shipping ready." It moves to nRF silicon and separates the motor and ring pins, so it is the board on which the product first works end to end. It is not the board to certify. Expect at least one more spin between V1 and the certification article, and note that §12.6 now bites twice: the units in hand are a different MCU family from the one that ships, and V1 itself is a prototype.

The unlock: campaign before certification¶

The 2022 FCC rule change permits conditional sales contracts and advertising to the general public prior to equipment authorization, provided a prominent disclosure states the equipment is subject to FCC rules and that delivery is conditional on completing authorization. Delivery before authorization is prohibited. You may also import ≤4,000 units for pre-sale activity before certification with required temporary labelling.

So the campaign funds the certification. Put the disclosure prominently in campaign copy — legally required, and it reads as competence to a technical audience.

6. Master Timeline¶

Revised 2026-08-21 — the campaign moves to March 2027 and the ship date to September 2027. Decided by the author (2026-08-21 log) on the grounds that school and the day job have taken the hours the twelve-week plan assumed. The strategic shape is deliberate: market and finish the nRF redesign for six months, prove demand with the campaign, and only then start FCC certification — the expensive, irreversible, third-party-dependent part. §5's 2022 rule change already permits advertising and conditional sales before authorization, so the ordering costs calendar rather than legality.

What this fixes: the old plan gave 3.5 months from a December campaign close to a March ship, for a 6–10 week certification that adds 3–6 weeks per failure, plus a pilot run, mass production and two app-store reviews. There was no slack anywhere in it. March close → September ship gives five months and room for one failure.

What it costs, and it is not nothing: a twenty-seven-week run-up is a much harder thing to sustain than a twelve-week one, and §12.32 already named that as a likely killer at the shorter length. Every cadence rate in Timeline.md was cut on the same day for that reason.

The dated windows, the milestone IDs, the old→new ID mapping and the phased advertising budget are all in vault/Timeline.md, which is the operational copy.

Window	Actions
Aug 21 – Sep 30, 2026	Finish the open Phase-1 assets: footage off the camera, founder video, Hackaday.io page + first logs, Kickstarter pre-launch page, site analytics, a blog (every HN submission needs one). Posting begins at 2/week. Two Fanstel conversations open now, not in 2027 — scope their open BM20C filing for portable body-worn use, and start the WM02C change-of-ID. Three lab quotes.
Oct 1 – Nov 30, 2026	Board V1 bring-up, with enough time for the power-tree failure to appear — it takes days, not one demonstration. Draw and order the respin. First Show HN (framing) in October; the ESP32→nRF power post in November, when it finally has measured numbers behind it. Second YouTube long-form. Newsletter and podcast pitches. Gate: 600 emails by Nov 30 — a hook decision, not a launch decision.
Dec 2026 – Jan 2027	Open $15 refundable reservations. Paid creator placements, 5–8, bought as data ($1.5–3k of `BUD-ADS`). Hackaday tip line ×2. Third HN post. Newsletter and podcast placements run in January. MOQ and tier pricing settled before February — Chinese New Year is Feb 6, 2027. Dec 19 – Jan 3 is deliberately light.
Feb 2027	Do only what won. Retargeting spend, never cold. Pre-launch push and the "we launch in 10 days" sequence. Campaign assets locked. Pre-scan on deposit money — the one certification item worth paying for before the campaign. Gate check 2027-02-14: 2,500+ emails, 250+ deposits, ≥1 creator video that outperformed.
Mar 1 – 31, 2027	Kickstarter launches. 30 days. All traffic to Kickstarter, no exceptions. Book the lab slot mid-March, once it is visibly funding — the 2–6 week lead time is otherwise added to the critical path in April.
Apr 2027	Campaign closes Mar 31; funds land ~14 days later. Pay the lab. Pilot run of production-representative units on the shipping revision. Long-lead component orders.
May – Jul 2027	Formal Subpart B + SAR. WM02C change-of-ID concluded — if this is still open in May, the ship date is not September. Mass production in parallel. App store submission and review.
Aug 2027	Authorization in hand. Import, label, fulfil. Physical creator seeding begins (now legal).
Sep 2027	Ship.

Hard gate: do not launch without 2,500+ emails, 250+ deposits and at least one creator video that visibly outperformed — checked 2027-02-14, two weeks before launch so that "no" is still a decision rather than a post-mortem. If six months of organic doesn't produce that, the campaign wouldn't have worked — and you learned it for the price of your time rather than a public failure.

A second, earlier gate now exists. GATE-TRAJECTORY — 600 emails by 2026-11-30. A single go/no-go at the end of a twenty-seven-week runway tells you in February what you needed to know in November, and the correct response to missing it is to change the hook, not to post more.

Funding requirement¶

F = 15,000 (FCC) + ~24,000 (500-set volume order) + tooling + app dev ≈ $60–75k

At $165 average pledge less ~10% platform/processing: 400–500 backers. Achievable off 2,500 emails and a working demo clip. Not achievable cold.

7. Pre-Launch Content (Aug 2026 – Feb 2027)¶

Make 100 versions of Sunrise Lock, not 100 different videos. The most common failure is producing variety instead of iterating on what worked.

Pillars¶

Pillar	Channel	Cadence
Sunrise Lock demo	TikTok, Reels, Shorts	4–5×/week
Phone-distance demo	TikTok, Reels	2×/week
Build-in-public + threat model	YouTube long-form, X, Hackaday.io logs, HN	weekly
Problem content (breaking promises to yourself, mornings, screen time)	TikTok, IG	2×/week, ~half with no product mention
Founder story	YouTube	once, done well

Build-in-public is what Flipper did before their campaign, and it earns the technical audience you need when you open-source.

The Show HN angle¶

Do not post "I built an ADHD smartwatch." Post the engineering problem: a commitment device where the adversary is your future self. Which component holds the root of trust and why it isn't the app. Why loosenings are quarantined in firmware. Why timers run on elapsed time so winding the clock ages nothing. Why the system fails open on degraded links. That's a front-page post; a product announcement is not.

Realistic email conversion¶

Source	View → email
TikTok / Reels	0.05–0.3%
YouTube (description link)	0.5–2%
Hacker News front page	5–10% of ~10–40k visits
Hackaday feature	3–8%
Newsletter mention	2–5%

500k TikTok views ≈ 500 emails. One HN front page ≈ 1,000–3,000. Emails come from the technical channels, not the social ones — which now aligns with the fact that your concept is technically native. Front-load the build-in-public work.

Honest expectation over 27 weeks (revised 2026-08-21 from 10–12): 2,500–6,000 emails, still with enormous variance. Flat outcome ≈ 800 (don't launch). One breakout ≈ 10,000+. The longer runway raises the floor and the median; it does not change the shape of the distribution, because that is set by whether one technical post lands.

On virality: don't plan for it, make it possible. Sunrise Lock is a genuinely strong viral candidate — an object doing something unexpected, solving a universally understood problem. Build the funnel to work at 50k views; treat 5M as upside.

Batch-film. A Sunday producing 15 clips beats posting on inspiration.

8. Creator Outreach¶

The constraint¶

You largely cannot ship units before authorization — delivery, display, and operation of an uncertified device are prohibited. Physical seeding moves to Feb–March. Pre-launch creator content runs on your footage.

Formats, ranked¶

Founder interview / collab on their channel — you demo live, they ask real questions. Highest conversion, often free, no production burden on them.
Reaction / stitch to the Sunrise Lock clip — native, near-zero effort, captures the "wait, what" response.
Problem-first content with your clip as payoff — least ad-like thing you can buy.
Explainer over your b-roll — cheap, weaker engagement, fine for reach.
Concept commentary ("would you buy this?") — good comment volume, free market research.

Live demo over video call is the secret weapon. A 20-minute Zoom showing Sunrise Lock working in real time. They can honestly say they watched it work. No shipping. Do this with every top-tier contact.

The asset pack¶

4–6 clean vertical Sunrise Lock clips, no text overlay, so they can cut their own
Same shots in landscape for YouTube
One 60-second "what it is" cut usable whole
Product stills, white and in-context
One-page brief: what it is, what it isn't, three claims they can make and the claims they cannot (see §10)
Link and launch date

List and mechanics¶

100–150 people across three audiences: ADHD creators, digital-minimalism/productivity channels, and hardware/maker channels. Tiers: 10–20 mid-size (100k–1M), 60–80 small (10–100k), rest micro. The small tier converts best — higher engagement, they answer emails.

Four-sentence individual emails referencing something they actually made. Expect 10–20% reply on genuine personalisation, 1–2% on templates.

Pay for 5–10 in October. $300–1,500 for a dedicated video from a 50k-follower creator. Treat it as data — you're measuring which framing converts before spending on ads.

The currency that beats money¶

Offer influence: advisory role, public credit, input on which commitment types ship, a private channel with you. Converts a one-off post into six months of advocacy, and they get first units in February for a genuine review. Offer 2–3 early firmware access and a repo contributors listing — how Flipper turned enthusiasts into unpaid evangelists.

9. Post-Launch Channels¶

Hacker News, Lobsters — the threat-model story, repeatable with new angles (firmware release, open-sourcing, post-mortems)
Hackaday, Hackster.io, Tindie, Adafruit blog, Make:
Crowd Supply as a secondary/alternative crowdfunding home for open hardware
GitHub as top-of-funnel — publish firmware; stars, forks, awesome-list inclusion are acquisition. Flipper's repo is above 16,000 stars.
Newsletter sponsorships — dev newsletters, productivity newsletters, ADDitude for the ADHD side. All permit language Meta won't approve.
Podcast reads — ADHD podcasts, productivity podcasts, digital-minimalism shows. Hosts can name conditions freely.
Conferences — Maker Faire, Hackaday Supercon, Open Sauce; CHADD annual for the ADHD audience
Specialty retail — Adafruit, SparkFun, Pimoroni. At $199 with a 45% distributor margin you keep $109 against $47 landed — viable. Anchors at $59/$24 leave too little for distribution, so anchors stay direct-only.
ADHD coaches, therapists, university disability offices — slow, strong trust transfer. Note the overview's caution: reach recovery and depression audiences through professionals, never direct marketing.

Function-and-outcome-first creative once organic proves the framing. Retargeting first — cheapest conversions. Median Meta ecommerce CPA ~$38, electronics ~$49, but that's established catalog retailers. Budget $100–250 blended CAC in year one; target sustainable CAC ~$70–110.

2026-08-21 — there is now a pre-launch advertising budget, and it is small on purpose: BUD-ADS, $2,000–5,000 total across Aug 2026 – Mar 2027. Phasing and rationale are in Timeline.md; the shape is $0–200 through November (tooling only), $1,500–3,000 on creator placements in Dec–Jan, $500–1,500 on retargeting in February, and up to $500 held for the campaign itself and spent only if it is already funding.

The rule that decides most of it: no cold paid social at any point in this budget. At $2–5k against a ~$49 electronics CPA you would buy at most a hundred conversions across six months, with attribution too thin to learn anything from — you would be paying for noise and then treating it as data. The two defensible uses of this money are creator placements, which produce assets you keep and are the only reliable route to GATE-CREATOR, and retargeting an audience you already own. Cold acquisition is what the campaign's own traffic is for.

Two preconditions travel with it. BLK-05 (regulatory/claims review with a lawyer before the first ad) is written as a precondition to exactly this and now has a date: before DEC-03. And §2's Meta rule is unchanged and matters more once money is behind it — ADHD language never appears in paid creative, and never boost a creator post where they name the condition in the first person. One rejected ad is recoverable; a restricted business account in March is not.

Allowable CAC: CAC_max = (P − COGS − f) + LTV_add

10. Claims Discipline¶

A one-page version of this goes to every creator and into every piece of copy. These are not stylistic preferences — several are legal exposure.

Never claim: - Impossible to cheat, unbeatable, can't be bypassed → say hard to beat on impulse - The anchor locks or restrains the watch or the wearer → it locks its own strap - Indefinite anchor battery → ~1 hour today, 2–3 hour target; state it plainly on spec sheets - App-blocking or uninstall detection → both were cut. Purge from all comparison material - Any medical efficacy, treatment, or symptom-management claim - Multi-day watch battery → 8–12 hours, overnight charging is the model - Vibration and LED ring on the same unit → the hardware fence is discharged (2026-09-10): on Board V1 the ring (P0.02) and the motor (P3.03) are separate pins and have been driven simultaneously with a human watching. Footage showing both on one unit is now truthful, and demos should be shot on a V1. The remaining limit is §12.6, not §10 — Board V1 is a bring-up prototype, the shipping board is OCT-10's respin, and nothing is certified. So: show both, and do not describe the unit on camera as the production hardware.

Lead with: the freedom on the other side of the friction. Not the buzzing. Stop negotiating with yourself. Get your mornings back. Past-you runs the day.

Avoid: "enforcement" in consumer copy, parole-officer framing, mechanism-worship, coercive flourishes.

11. Safety & Misuse — Design Requirements¶

You cannot prevent misuse, and preventing it is the wrong goal. The achievable goals are: don't make it easy, don't be the one who suggested it, and make sure the person can always get out. Most of what follows belongs in the firmware spec, not just here.

11.1 The dangerous mechanic is the day-delay, not custom blocks¶

Custom blocks alone are relatively benign. The risk comes from combining them with irrevocability: someone sets a harmful commitment while in a bad state, comes to their senses an hour later, and the system is designed specifically to refuse them. The core feature becomes the harm.

11.2 Hard override — required, and not only for this reason¶

A stop that is never delayed, never rationed, never removable. Distinct from emergency passes.

Both buttons held 10 seconds → all enforcement stops for 24 hours
Works on the watch alone: no app, no network, no account
Logs the event; does not require justification
Cannot be disabled, capped, or configured away by the user

Enough friction that impulse doesn't reach for it; zero friction for someone who needs out.

This is a general safety requirement, not just a self-harm safeguard. What currently happens on hospitalisation, a fire at 6am, or a failed wear sensor alarming all night in a hotel? Any device that physically locks and escalates needs an unconditional stop. Shipping without one is a physical safety defect.

Cost: the "inescapable" claim — which §10 already forbids. The honest promise is better: you can always stop; the friction is that stopping is total and visible, not that it's impossible.

2026-08-08 — the requirement stands; the mechanism is under review. "Both buttons held 10 seconds" was written against a board that no longer exists. Board V1 has one user-accessible button (P0.05, on the back) plus a reset switch, so the mechanic is not implementable as written, and the author's judgement is that it was the wrong mechanic anyway: a stop that requires opening the case fails the "zero friction for someone who needs out" half of this section while doing little about the "impulse doesn't reach for it" half. Every bullet above remains a requirement. What replaces the two-button hold is being worked out in vault/Concepts/Safety.md; nothing here changes until that lands and this section is rewritten with it.

11.3 Bound the primitives, not the intentions¶

You can't enumerate bad goals. You can limit the mechanism in ways that make the worst configurations unbuildable, without guessing at intent:

Maximum single-window duration
Mandatory minimum gap between windows — no 24/7 coverage
Cap on total enforced hours per day
Cap on escalation duration; an alarm cannot run indefinitely
No "remain in place" enforcement beyond a short window — that's confinement, not commitment

These read as sensible engineering limits and survive forking better than policy, because removing them becomes a deliberate, visible act rather than a default.

Impulse enforces presence — location, proximity, network. It has no idea what you ate. Protect that permanently.

Refuse, and write down why now so it isn't argued away in a 2028 feature meeting: HealthKit weight integration, smart-scale support, calorie-app hooks, fasting templates, exercise-minimum templates, food or weight logging of any kind. Without a data substrate, restriction enforcement stays clumsy and manual.

Never ship food, weight, fasting, or exercise-minimum templates, and don't let the app suggest or autocomplete toward them. If a user builds it themselves, that's on them. If the app offered it, that's on you.

11.5 Point the same mechanic at care¶

Ship minimum commitments alongside maximums: in bed by midnight, eaten by noon, take a rest day. Same self-binding architecture, inverted. Gives people worried about their own patterns something to bind themselves to, and reframes the product around keeping promises rather than denying yourself. Good safety feature; also a good product feature.

11.6 Interrupt patterns you can see¶

Not lectures — a pause. Triggers worth watching: rapid successive tightenings, window durations trending up week over week, passes spent then immediately followed by re-tightening, sleep windows shrinking. One calm interstitial offering to set a floor.

If a user constructs a food- or weight-adjacent custom block, one screen with a resource. Use the National Alliance for Eating Disorders helpline — NEDA's line has been permanently disconnected and stale references to it are common.

11.7 Open-source specifics¶

Put the bounds in firmware, not the app. Forking an app is trivial; reflashing a watch is a real barrier that self-selects for people who know what they're doing.
Trademark is the lever, not the license. An OSI license can't restrict use, but you control the name. "Impulse"-branded builds retain the safety bounds; forks that strip them ship under their own name and reputation.
Write SAFETY.md explaining what the bounds are and why. Highest-value single action: it turns removal from a cleanup task into an argument someone must make in public, and every fork author reads your reasoning.
State in the contribution policy that PRs removing safety bounds won't be merged. Expect pushback; it's a useful filter.
Don't link to or promote forks that remove them.

11.8 Accept the residual risk explicitly¶

Document what you decided, what you refused to build, and why. Then get one clinician hour — a psychologist working with eating disorders or OCD, asked specifically: how would a patient of yours misuse this? You'll get two or three answers you haven't thought of. Cheapest risk reduction available.

You will not reach zero. Someone will eventually misuse this, and it won't be your fault if the above is done — but it will be your fault if you shipped with no stop button and templates that suggested it.

12. Common Mistakes — Things Most Likely To Kill This Launch¶

Ordered roughly by lethality.

Fatal¶

Launching the Kickstarter cold. Technology scores ~24% success versus 68% for comics. Campaigns securing 20% of funding in the first 48 hours have a 78% chance of hitting goal, and in most cases the majority of backers come from the creator's own network — discovery surfaces you because you have velocity, not to create it. Over 60,000 projects have finished at 0%. It's all-or-nothing, and a failure burns the one launch news cycle you get. Do not launch without the list.
Demo footage that shows both vibration and the LED ring on one unit. The current board pin-shares them. Kickstarter holds creators to their footage, and a technical audience will find this. It is the difference between a hardware startup and a fraud accusation. Resolved 2026-09-10 for the demo half: Board V1 unshares the two pins and both have now been driven at once with a human watching, so footage showing both is accurate — shoot demos on a V1. Unresolved for the certification half: V1 is not the shipping revision and nothing has been certified, so a campaign claim may describe what the device does but must not present V1 as production hardware. See §12.6.
Ordering at volume before validating demand. The $15/$16 BOM assumes an MOQ commitment. Order for $15 volumes, sell at $25 volumes, and the margin structure evaporates. Get tier pricing in writing and model break-even at the next tier down.
Spending customer money on certification that might fail. Take 400 full pre-orders, empty the account on lab fees, fail testing, and you owe 400 refunds you can't make. Pre-scan first, on deposit money, before anything is at stake.
Deviating from the module grant conditions. Wrong antenna, gain, trace layout or separation → Class II Permissive Change, grantee cooperation, full retest. $15k becomes $35k and months. Read the integration guidance before the PCB is final.
Certifying the wrong board revision. Test the shipping board, not the prototype in hand.
Medical claims. "Treats ADHD," "clinically improves focus," "manages your symptoms" moves you into FDA device territory and FTC substantiation exposure. Stay on general-wellness framing, per the overview's own guidance.
Letting the coercion narrative define you. This is the reputational tail risk nobody plans for. A servo lock, escalating alarms, a device you can't turn off — one viral "I bought a dystopian punishment watch" take, or one journalist framing it as self-harm technology, and you spend your launch on defence. Mitigation: self-binding language in every single asset, never mechanism-worship, always show the user as the author of the constraint. The overview's voice guide is not a style preference; it is your reputational insurance. Have a prepared, calm response written before launch.

Severe¶

Shipping without the hard override. See §11.2. This is the single most important unshipped requirement in the plan, and it is a safety defect independent of the misuse question — a device that locks and escalates with no unconditional stop fails on hospitalisation, fire, and sensor faults alike.
Not building duty-of-care boundaries into the product. A device that enforces behaviour will be used to enforce the wrong behaviour, and the day that surfaces publicly is very bad — for the user first, the company second. §11 is the full treatment; the short version is bound the primitives, ship no food/weight/exercise templates, keep the device blind to anything but presence, and get a clinician hour before launch rather than after.
The battery arithmetic doesn't close. The watch runs 8–12 hours and charges overnight. Full at 6am means empty between 2pm and 6pm — but the overview's own example day has commitments at 5:30pm and 9pm. Either the example day or the battery figure has to change. Ship this unresolved and your most common support ticket is "it died before my evening commitment," which reads as the product not working. Resolve before any marketing describes an all-day schedule.

2026-08-11 — half resolved, and the remaining half is worth stating plainly. The advertised figure is now 8 hours minimum (firmware_spec_v3_nrf.md §6.3 — a floor, chosen because a floor is what can be advertised), and the 9 pm window is deleted from impulse_overview.md's example day. That closes the 9 pm contradiction.

It does not close this risk. 8 h from 6 am is flat at 2 pm, and the example day still enforces a gym-arrival window at 5:30 pm. The figure moved down and the day lost its last item but not its latest one, so the gap widened rather than closed. Three ways out, all copy decisions available today: move the gym window earlier in the example day, write an afternoon top-up into it, or advertise a figure that reaches 5:30 pm. Until one is picked, no marketing may show the 5:30 pm window and the 8-hour figure together — which is a live constraint, because the launch video and the pre-launch page are both being built this week.
Taking full pre-orders instead of refundable deposits. Every pre-order removes a backer from day-one velocity — spending your highest-intent buyers on the one variable that decides the campaign. Chargeback windows run ~120 days, so an August payment shipping in March triggers rolling reserves or frozen funds, often exactly when the manufacturer needs paying. And the FTC 30-day rule means you owe refunds when you slip, and hardware slips.
Getting the ad account restricted with ADHD copy. One rejected ad is recoverable; a restricted business account mid-launch is not. Never put spend behind a creator post that names the condition in the first person.
Letting a creator imply they tested it. Unsubstantiated endorsement under FTC rules, and the creator-marketing mistake that genuinely bites. Bold it in the brief. Paid partnerships need visible disclosure.
Shipping prototypes to creators before authorization. Prohibited. Use footage, live video demos, and access instead.
Overclaiming anywhere. "Impossible to cheat" invites a thousand people to disprove you, and one YouTube video titled "I beat the Impulse watch in 30 seconds" does more damage than any ad buy repairs. §10 exists for this.
Promising a date with no slack behind it. Revised 2026-08-21. The old version of this line said "promising February," against a March ship with zero slack in the schedule. The new timeline ships in September 2027 off a campaign closing 31 March, which is about five months of certification-and-manufacturing time with genuine room for one failure — the first version of this plan where the line is honest. Communicate October to backers regardless. Under-promising costs nothing; shipping early is the cheapest goodwill available, and this is a first hardware product with an FTC 30-day-rule obligation attached to whatever date the campaign page carries.
Splitting traffic during the campaign. Site pre-orders don't count toward the total that makes the campaign look successful and dilute the velocity driving placement. Everything to Kickstarter for 30 days. Site reverts to primary afterwards — Kickstarter takes 8–10% and gives you no list, no pixel, no repeat-purchase path.
Pricing anchors too high. Kit-out cost above ~$180 kills the multi-anchor behaviour the product depends on. Attach rate is retention.
Forgetting the app is on the critical path. No app, no product. App store review, two platforms, ongoing maintenance. It's the least visible dependency and the one most likely to slip past the hardware.

Costly¶

Making varied content instead of iterating on Sunrise Lock. If a clip works, make forty more of that clip. Founders reliably do the opposite.
Posting the wrong Show HN. "I built an ADHD smartwatch" dies. "A commitment device where the adversary is future-me" goes front page. You get roughly one good shot per angle.
Discounting after launch. Flipper went $169 → $199 and never discounted. Frame the campaign price as X% off retail from day one. Never add a second early-bird tier after the first sells out — it reads as manipulative to exactly the audience most likely to notice.
Too many tiers. Six maximum, one visually default.
An early bird cap that never fills. The counter then advertises weak demand. Size to sell out in 24–48 hours.
Open-sourcing before the moat exists. Flipper-compatible clones are sold openly today. Publish when brand, firmware velocity, and community can carry you.
Not owning the list. Kickstarter gives you names and addresses, no attribution, no behavioural data, no retargeting. Build on your own domain with your own pixel from day one.
Underestimating the working-capital gap. Between paying the manufacturer and shipping, plus tooling, certification, campaign costs, and app development. Check the target clears total cost, not marginal cost.
Under-reserving for support and returns. 8–15% hardware returns, unresalable wearables, and a three-component system that generates pairing and false-alarm tickets indefinitely.
Phone-distance false alarms in reviewers' hands. The overview already flags low-power mode and degraded Bluetooth. Steer every reviewer to anchor-docking, and state the phone conditions plainly in setup. A false alarm in a review video is worse than a missing feature.
Subscription resentment. If you go $149 + monthly: trivial cancellation, usable free tier, and existing schedules keep enforcing if payment lapses.
Founder burnout on the content cadence. You're testing sustained routine on yourself while building a product for people who find that hard. Batch-film or the plan quietly dies in week five.

2026-08-21 — this risk went up, not down, and it is now the most likely way this plan fails. The run-up went from twelve weeks to twenty-seven, at reduced hours, through a school term and a busier job. More calendar is not more capacity, and a distant deadline generates less urgency than a near one — the failure mode moved from not enough time to not enough sustained attention.

The mitigation is in Timeline.md and it is real: every cadence rate was cut on the same day the dates moved. Posts 3–5/week → 2/week rising to 3; Hackaday.io logs weekly → fortnightly until January; creator emails 20/week → 10. Sunday batch-filming survives at 8–10 clips rather than 12–15, because it is the mechanic the whole thing rests on. A rate you hit for six months beats a rate you abandon in month three, and the metric that decides the campaign — emails per week, trending — does not care about post count. If the rates turn out to be too easy, raise them in January; that is a far better problem than the alternative.

13. Open Questions¶

Reordered 2026-08-21 by the new timeline. Three items became urgent because they are somebody else's calendar; several became less urgent because the campaign is four months further away.

Now urgent — third-party calendars, not purchases¶

⛔ ~~Ask Fanstel to scope the open BM20C filing for portable body-worn use~~ — SEP-12, due 2026-08-31. Expired 2026-09-11, when the grant issued — mobile, with the same 20 cm clause as the WM02C's. The conditional above is no longer a risk to hedge; it is what happened. The draft was never sent, and the free question is now a Class II permissive change only Fanstel may file. The BLE-only fallback is still SAR-excluded by calculation, but only on the BC15C (X8WBC15, evaluated portable) — not on the BM20C, and every document using the bare phrase needs to name the module. Folded into SEP-13, which is now a two-module conversation. See docs/agent-notes.md, 2026-09-20
Open the WM02C change-of-ID conversation with Fanstel — SEP-13, due 2026-09-30, concluding at SHIP-05 by May 2027. The longest-lead item in the plan and the one most able to move the ship date on its own. See §5
Get the BM20C FCC grant number in writing — new 2026-08-08. X8WBM20C, granted 2026-09-11, DTS, 2402–2480 MHz, ≈8.4 dBm conducted. Read from the public record on 2026-09-20, not from Fanstel — so get it confirmed on the thread before it goes in front of a lab. The §5 pre-certified-module strategy is funded again, with one condition attached: the grant is mobile, 20 cm from all persons, so the watch needs a permissive change on the BLE radio as well as the WiFi one. The BC15C fallback (nRF54L15 — channel sounding confirmed, RAM halved) is unchanged and is still the only module here evaluated portable. The nRF54LM20A silicon ship date is the half of BLK-15 that remains unconfirmed
Three lab quotes, scoped as one PCB / two hosts / two exposure categories — AUG-12, due 2026-09-30. 1 of 3 answered
Regulatory/claims review with a lawyer before the first ad — BLK-05, and it now has a date: before DEC-03, because BUD-ADS means there will genuinely be a first ad in December

New, from the 2026-08-21 timeline change¶

What mechanism holds a $15 deposit for nine months? DEC-01 opens reservations on 1 Dec 2026 against a September 2027 ship. That is well outside the ~120-day chargeback window §12.12 warns about and long enough to attract rolling reserves. Ask a processor about authorization-and-later-capture before defaulting to holding cash
Decide FEB-05 explicitly — pre-scan on deposit money in February, or wait for campaign funds? ~$1–2k. A failure found in February changes the campaign; the same failure found in June changes the ship date. Don't let this slide by default
Where does the blog live? SEP-11. Every HN submission in BUD-HN requires it, and none of the three remaining posts can be spent until it exists