Open Brain: A Browser Interface with Next.js and Vercel
Before you start: Part 2’s database and search should work. Telegram and advanced retrieval are optional; keep this interface small.
Done when: an authorized user can browse, read, and search existing notes, while signed-out and unauthorized users cannot retrieve them.
Part 2 already gives you a way to save and search notes. A browser becomes useful when you want to inspect the collection without composing a command or asking an AI client to show it. It adds another application to maintain, so begin with one task that makes that work worthwhile.
I built a browser interface because retrieving information through Telegram had become inefficient for me. Sometimes I wanted to see what my agents were doing or follow up on a particular idea. I wanted a practical way to browse and search my notes, inspect their current state, and use a calendar to see both future events I had added and when notes were created.
I also created a separate Open Brain called Family Brain for my wife and me. I moved our household logistics there, keeping them in a second database apart from my own projects and thoughts. I hoped a shared interface would give us a useful view of that information. We are not using Family Brain now; Part 6 explains what happened.
That second database was a deliberate separation between two collections, not a requirement for adding a browser. The first interface below uses the database you already built. If you later add sharing, decide who may read each collection and test those permissions separately.
Start with three actions
Aim to browse recent notes, open the original text, and search with a project filter. Add calendar views or phone-install features after that path works.
Try this with Part 2’s fictional notes: open recent notes, select “Ana will send the code on Friday,” read its original text, then search for “Who will share the script, and when?” with the Survey analysis filter. You should be able to follow the result back to the same source ID without seeing the travel note in that filtered response. Browsing, reading, and searching are enough for this first version; editing notes is outside its scope.
Authentication identifies a user. Authorization determines what that user can see. Both must work on the server and in the database, not just in the visible interface.
Keep browser code in the project layout you chose in Part 1. For the difference between search filters and access controls, see Part 2; review the deployed access paths again in Part 6.
The application code lives in your project; the browser uses its server routes and the existing database. Deployment to a host such as Vercel is optional. If you deploy, configure its environment and secrets separately from your local setup.
In my implementation
The codebase reviewed for this series in October 2026 includes a Next.js interface with Supabase authentication, browsing, calendar and detail views, and search. You can begin with fewer screens.
The browser uses v3-first search and document grouping, without the MCP reranker, graph augmentation, or no-answer guard. Web capture writes one row; Node capture can split long notes. In practice, these differences mean you should compare source IDs, original text, and search settings across clients rather than expecting identical result lists or row counts. Part 4 explains the optional retrieval stages. Reuse records and access rules while testing the clients you run.
Prompt: build a small browser interface
Build a minimal browser interface for our existing Open Brain.
Inspect the current repository and official framework/Supabase docs.
Reuse the database and search pipeline where practical. Explain any
intentional difference from the bot or MCP client.
Start with sign-in, paginated recent notes, note details showing original
text/source/date, and search with project filters. Use server-verified
authentication and the approved authorization model. Never put privileged
database or provider keys in browser code.
Add loading, empty, and error states. Support keyboard navigation and
small screens. Prevent private responses from leaking through shared
caches. Use synthetic data for tests.
Run locally first. Report the test results and remaining gaps; ask before
creating hosting resources or deploying. Give me the local start command
and URL, and walk through the fictional survey-note browse/read/search task.Check the result
Sign in and find a synthetic note you saved through another client. Open it and compare the original text and ID. Repeat a filtered search through both clients and investigate unexpected differences.
Then sign out. Try reopening the note URL and calling its data route (the server endpoint used by the page) directly. The private content should remain inaccessible. A hidden navigation link is not proof of protection.
In the approved test environment, also use a signed-in account that lacks permission to read the owner’s notes under your access model. Try both the direct note route and a search request. Neither should reveal the owner’s private text or metadata. Signing out tests authentication; this separate check tests authorization.
At phone width, check that you can read results, move between pages, and use filters without horizontal scrolling. Test focus visibility and keyboard access on a desktop.
Optional: deploy and install on a phone
A Progressive Web App, or PWA, can provide an installable web experience. Installation alone does not make private notes safely available offline, and device behavior needs its own tests.
Prepare a deployment plan for this tested interface. Verify current host
limits, cost, environment variables, authentication redirects, and cache
behavior. Keep production data and credentials out of previews.
If I approve deployment, verify sign-in, sign-out, direct unauthorized
requests, and cross-client retrieval on the deployed URL. If adding PWA
installation, test it on the actual target device and clearly report
anything untested. Do not cache private notes offline by default.A preview is useful for reviewing layout. It does not replace testing authentication and data access on the deployed version.
If a check fails
If a note appears in one client but not another, compare the source IDs, filters, and search configuration before creating another copy. If signing out hides the page but a direct request still returns private text, stop deployment and fix the server-side access check.
Next: protect the notes and maintain the system.
Previous: retrieval checks. For mobile capture through a bot, see Part 3.