DEV Community: shaojie gong

Why a local search index is also a privacy decision

shaojie gong — Wed, 14 Oct 2026 14:08:05 +0000

A local index defines both the engineering model and what the product can see.

NotebookBloom indexes the chat and Studio content loaded in the current NotebookLM page and stores that index in the browser. Saved sources, citations, cards and prompts can then be searched from the same panel.

The cost is coverage. Unopened notebooks and source bodies that never appeared on the page are not included. The benefit is that search queries and indexed notebook text do not need to leave the browser for a central search service.

I updated the product and store copy to state that tradeoff directly. “Search every notebook” sounded stronger, but it described a product that did not exist. Accurate limits are part of the feature.

Implementation check

Before publishing or shipping this workflow, I verify it against a real notebook, keep the limitation visible, and make sure the next action returns to evidence.

A search result should take you back to the evidence

shaojie gong — Tue, 13 Oct 2026 14:13:30 +0000

I used to treat a search result as the finish line. A user showed me why that was wrong.

They searched for a phrase, clicked the result, and reached the correct conversation. Technically the navigation worked. Visually, the phrase was still outside the viewport, so the user had to search again with their eyes.

The 1.1.4 release changed that handoff. A result in the current notebook scrolls to the matching content and highlights the query. A result in another notebook opens that notebook first, then restores the search context and locates the match.

Cards and citations keep their existing behavior. The change is deliberately narrow: reduce the distance between “I found it” and “I can verify it.”

Implementation check

Before publishing or shipping this workflow, I verify it against a real notebook, keep the limitation visible, and make sure the next action returns to evidence.

What cross-notebook search includes

shaojie gong — Mon, 12 Oct 2026 13:18:48 +0000

Search across NotebookLM notebooks sounds simple until you ask what “across” means.

NotebookBloom builds a local index when you open Search inside a notebook. The index includes the chat and Studio content currently loaded on that page. The same search box also covers source records, citations, cards and prompts saved in NotebookBloom.

There are two limits worth stating clearly. An unopened notebook has not been indexed, and source text that was never loaded on the page is not silently fetched in the background.

The feature retrieves matching records. It does not claim that an extension can read every private notebook and produce one combined AI answer. A useful result should show where the match came from and help you return to the evidence.

Implementation check

Before publishing or shipping this workflow, I verify it against a real notebook, keep the limitation visible, and make sure the next action returns to evidence.

A Plant Reminder Is Useless If Android Quietly Stops It: What GrowBook Does About That — Implementation Notes From GrowBook

shaojie gong — Mon, 21 Sep 2026 01:40:31 +0000

I wrote this down because the implementation only makes sense after the plant-care problem is clear.

A plant reminder has one job: appear when the plant needs attention. Android can make that surprisingly fragile. Notification permission may be off, exact alarms may be restricted, a reboot clears scheduled alarms, and some phone makers are aggressive about background apps.

What GrowBook does

GrowBook explains why it asks for notification access before showing the system prompt. It checks the relevant settings, saves schedules locally, and rebuilds reminders after a reboot or app update. When the operating system refuses an exact time, the app needs to say so instead of pretending everything is fine.

The boundary I kept

There is still no universal switch that defeats every battery manager on every Android phone. I would rather be clear about that limitation and guide people to the right setting than promise a reminder that may never arrive.

A reminder that admits it needs one more system setting is better than a silent reminder that never appears.

GrowBook on Google Play: https://play.google.com/store/apps/details?id=com.yuntai.growbook

The Plant Care Question I Ask Most Often Is Not Complicated: When Did I Last Water This? — Implementation Notes From GrowBook

shaojie gong — Sun, 20 Sep 2026 02:08:35 +0000

The feature looks simple from the screen. The useful part is the rule behind it.

Most of my plant mistakes do not begin with rare diseases or mysterious nutrients. They begin with a boring question: when did I last water this one?

What GrowBook does

Memory is unreliable because watering is a tiny task. I do it while making coffee, moving laundry or answering a message. Three days later, I remember touching the pot but not whether I watered it. A note with a date settles the argument in a few seconds.

The boundary I kept

GrowBook keeps care history beside the plant, so I can see the last watering, fertilizing or repotting entry without digging through a general calendar. It is not expert advice. It is a record of what I did, which is often the missing piece.

The next time a leaf turns yellow, I would rather check a date than debate my own memory.

GrowBook on Google Play: https://play.google.com/store/apps/details?id=com.yuntai.growbook

NotebookBloom: 31 installs, 17 opens, 9 successful users — what the funnel changed

shaojie gong — Fri, 18 Sep 2026 14:13:45 +0000

My earlier analytics showed 31 extension_installed users, 17 extension_open users, and 9 users with at least one successful action. That changed what I chose to build next.

The biggest issue was not attracting zero users; it was helping users finish.
AnkiConnect push succeeded 5 times out of 21 starts in that measurement window.
Citation import and bulk links also failed when prerequisites were unclear.

These are small-sample observations from the earlier measurement window, not proof of product-market fit and not a claim about 1.1.3 performance.

The next useful metric is not another install. It is one more person completing the action they came for.

I built NotebookBloom around this workflow: https://notebookbloom.com

Why Watering Every Houseplant on Sunday Is Convenient for You and Rough on the Plants — Implementation Notes From GrowBook

shaojie gong — Fri, 18 Sep 2026 01:50:43 +0000

I ran into this while using GrowBook on my own plants, then had to decide what the app should do.

A weekly watering day sounds tidy. I used to line up every pot on Sunday, water the lot, and feel unusually responsible for ten minutes. The problem is that a pothos, a fern and a succulent do not care about my calendar.

What GrowBook does

A schedule is useful as a prompt to check, not an order to pour water. I look at the soil, the weight of the pot and the plant itself before marking the task complete. Some plants keep a seven-day rhythm. Others change as the room gets warmer or the days get shorter.

The boundary I kept

That is why GrowBook stores a separate interval for each plant instead of giving the whole collection one watering day. The reminder says which plant needs attention; the final decision still belongs to the person standing next to the pot.

Sunday is still on my calendar. It now means “check the plants,” not “pour water into every pot.”

GrowBook on Google Play: https://play.google.com/store/apps/details?id=com.yuntai.growbook

NotebookBloom: A valid YouTube link can still be a bad NotebookLM source

shaojie gong — Thu, 17 Sep 2026 13:30:53 +0000

NotebookLM mainly needs usable transcript text. A video can play perfectly and still become a weak source.

Confirm captions exist before importing a full playlist.
Check whether the spoken language is recognized correctly.
Test two or three videos with a question whose answer is clearly spoken.

Bulk import can save repetitive pasting. It cannot create a transcript that is not there.

Test a small sample before adding an entire playlist or channel.

I built NotebookBloom around this workflow: https://notebookbloom.com/blog/notebooklm-bulk-import-folders/

GrowBook Is Live on Google Play: A Plant Care App for People Who Forget What They Did Last Week — Implementation Notes From GrowBook

shaojie gong — Thu, 17 Sep 2026 02:02:46 +0000

This started as a small user-facing problem and turned into a product decision.

I built GrowBook because I kept watering every plant on the same day. That was easy for me to remember and terrible for the plants. The succulents stayed wet too long, while the thirstier plants were already drooping by the time I noticed.

What GrowBook does

The app gives each plant its own photo, care schedule, journal and reminder. The basic flow works without an account and without a network connection. There is also an on-device plant identifier and a light meter that uses the phone's ambient light sensor when the device has one.

The boundary I kept

GrowBook is now live on Google Play in 12 languages. It is still a small independent app, so I am watching the first month closely: where people get stuck, which tools they return to, and whether the paid features are useful enough to earn a subscription.

If you keep forgetting whether you watered something yesterday or last Tuesday, I would like to hear how you handle it now.

GrowBook on Google Play: https://play.google.com/store/apps/details?id=com.yuntai.growbook

NotebookBloom: I remembered the quote, but not which NotebookLM notebook it was in

shaojie gong — Wed, 16 Sep 2026 13:10:10 +0000

NotebookLM works beautifully until the notebook list gets long enough that you remember the idea but not its location.

Good notebook names delay the problem but do not remove it.
Browser history helps only when you remember when the notebook was opened.
Searching saved sources, citations, cards, and prompts gives you a path back.

Cross-notebook search is retrieval. It does not pretend to generate one combined answer across every notebook.

A useful search result should help you reopen the right source, not hide it behind another summary.

I built NotebookBloom around this workflow: https://notebookbloom.com/blog/search-across-notebooklm-notebooks/

NotebookBloom: Check these four fields before trusting a NotebookLM-to-Zotero import

shaojie gong — Tue, 15 Sep 2026 14:33:27 +0000

BibTeX removes repetitive typing. It does not remove the need to check metadata.

Title — especially when the PDF filename is meaningless.
Author — organization and personal authors are often mixed up.
Year and DOI/URL — verify the publication year and route back to the original.

A clean-looking Zotero record can still contain bad source metadata. Import first, verify second.

Automation should save time without turning unchecked data into a polished-looking citation.

I built NotebookBloom around this workflow: https://notebookbloom.com/blog/notebooklm-zotero/

GrowBook: shipping in 12 languages, and the boring gauntlet before Google Play

shaojie gong — Tue, 15 Sep 2026 01:25:02 +0000

The code was done. The app worked. And then came the part nobody blogs about: the distance between "it runs on my phone" and "strangers can install it from the Play Store." That distance is longer than it looks, and it's paved with paperwork.

Two things ate this final stretch: languages and compliance.

First, languages. GrowBook ships in 12 of them. Not "we'll localize later" — twelve, in the box, from launch. That decision reshaped small things everywhere. My plant labels needed translations keyed by scientific name. My notification copy had to make sense in every locale. And Chinese alone is two of the twelve — Simplified and Traditional — which is how I ended up hand-writing a Simplified→Traditional character table for plant names, because I had Simplified data and Traditional users and no budget to translate hundreds of names twice. Android has a localeConfig for declaring supported languages so the system knows what you offer; filling it out honestly is a small file that represents a large amount of "did you actually check this screen in Arabic" work.

Then, compliance — the genuinely unglamorous part. A few things I learned the slow way:

Version numbers are two numbers, not one. Users see 1.0.0. Google cares about versionCode — an integer that must increase with every single upload. My first public version is 1.0.0, but internally it's versionCode 7, because there were six builds before it that only ever existed inside the Play Console. Every test upload burns a number. Nobody tells you this; you just watch the integer climb.
Signing is forever. Release builds are signed with a keystore, configured out of a keystore.properties file kept out of the repo. Lose that key and you can't update your own app — a new key means a new app. My build falls back to the debug signing config when the keystore is absent, so a teammate (or CI) can still build without holding the release secret. That fallback is a convenience that must never, ever run for a store upload.
The target API level is a moving deadline. Google requires new apps to target a recent Android API level, and that bar rises every year. Mine has a hard date attached: I have to be on the required target level by August 31, 2026, or updates get blocked. "Ship it and forget it" isn't a thing anymore — staying published is a subscription paid in maintenance.
Developer verification is now a gate, not a formality. Before your app reaches anyone, your developer identity has to be verified. It's a real checkpoint with real back-and-forth, and it's a step you can't compress by writing better code.

None of this is hard the way a light-sensor bridge is hard. It's hard the way taxes are hard: unfamiliar, unforgiving of small mistakes, and impossible to skip. The lesson I wish I'd internalized earlier is that "done" is a developer's word. The store has its own definition, and it includes a pile of forms, an ever-rising API target, a signing key you must guard for the life of the app, and an integer that only goes up.

GrowBook is 1.0.0 now — version code 7, twelve languages, offline-first, on the Play Store. The code was the fun 80%. This last 20% is why so many finished apps never actually ship.

If you've launched on Google Play: what caught you off guard in the final stretch — the API level treadmill, the signing paranoia, the version-code accounting, or something worse? I want to know what's still ahead of me.

https://growbookcare.com

— building GrowBook in public, #6