I Built a Full-Stack AI Second Brain App Without Writing a Single Line of Backend Code

Souren Ghosh — Thu, 14 May 2026 10:56:54 +0000

PDF OCR, semantic mind maps, RAG search, and a hierarchical tag system — all generated through conversations with an AI app builder.

I want to tell you about the most productive few days of building I have ever had.

Not because I wrote exceptional code. But because I barely wrote any backend code at all.

I built Neuron — a full-stack personal knowledge management app with AI summarisation, PDF text extraction via OCR, three-mode interactive mind maps, a plain English query interface, and a Studio document editor — using MeDo, a no-code AI app builder, as my primary development tool.

This is the honest story of how that went: what worked brilliantly, what broke repeatedly, and what I learned about describing software to an AI well enough that it builds the right thing.

The Problem I Was Solving

Most of us consume hundreds of articles, videos, and ideas every week and forget almost all of them.

Traditional note apps — Notion, Obsidian, Evernote — store information well. But they require manual effort. You paste a link, you write the summary, you add the tags, you find the connections. The app is a filing cabinet. You are the librarian.

I wanted to build something where the AI does the librarian work. Capture anything, and the system automatically:

Summarises it in three sentences
Tags it and places it in a topic hierarchy
Finds semantic connections to everything else you have saved
Lets you query your entire knowledge base in plain English

The result is Neuron. Here is what it ended up containing.

What Got Built

Five screens, fully functional:

Capture — paste any URL, raw text, or upload a PDF. AI processes everything automatically.
Library — flat grid view or date-based folder tree, with a hierarchical tag sidebar for filtering.
Mind Map — three zoomable drill-down modes (Time, Topic, Network) with level-of-detail unfolding.
Ask — plain English RAG search across your entire knowledge base with cited answers.
Studio — rich text document editor with inline drawing canvas, autosave, and publish flow.

Four external API integrations:

Jina Reader for clean URL content extraction
Baidu AI Studio PaddleOCR for PDF text extraction via a server-side proxy
Supabase for the complete backend (database, auth, edge functions)

A tag hierarchy system where tags form a parent-child tree four levels deep, with eight permanent root categories (technology, science, business, creativity, health, philosophy, history, other) that cannot be deleted.

User authentication with anonymous 24-hour sessions and full account registration, with complete data isolation between users and sessions.

How I Actually Built It: Describing Software to an AI

The first and most important thing I learned is that MeDo is not a command executor. It is a generative app builder. The difference matters enormously.

If you tell it "create a database with these fields," it responds politely saying it cannot execute backend commands. If you tell it "build an app where users paste URLs and the app scrapes the content, summarises it with AI, and saves it to a library," it builds the entire thing.

The mental model shift: describe what users experience, not what the system does internally.

Instead of: "Create a notes table with fields: id, title, raw_content, summary, source_type, tags, topic_category, owner_id, created_at"

Say: "Build an app where users paste any URL. The app fetches the full page content, uses AI to generate a 3-sentence summary, assigns topic tags, and saves everything to a library the user can browse."

MeDo handles the schema, the database, the API routes, and the frontend — all from the second description.

My Prompting Structure

I built Neuron in five distinct conversation phases:

Phase 1 — Master prompt. One large prompt describing the entire app: all five screens, what users do on each, what the AI does, what data gets stored, and all four source types. This gave MeDo the full picture before generating anything, producing a coherent skeleton rather than disconnected fragments.

Phase 2 — Feature depth. One feature per conversation turn. I described UI in exhaustive detail — exact pixel sizes, colours, hover states, animations, error cases, empty states. MeDo generates better code when it can visualise the precise output.

Phase 3 — API integrations. Each external service introduced as a user flow with the exact API endpoint and response structure included in the prompt. For the OCR proxy I described the CORS problem explicitly: "the browser cannot call this URL directly, so we need the backend to make the call instead." MeDo generated the proxy route, the frontend fetch, and all error handling from that one sentence.

Phase 4 — Debugging. When something broke silently, I asked MeDo to add visible debug logging panels in the UI rather than guessing at fixes. Reading actual error messages produced precise fix prompts rather than regenerating large sections.

Phase 5 — Polish. Visual redesign described in CSS tokens — exact colour values, spacing, shadow definitions, transition timings. This let MeDo apply comprehensive visual changes without touching logic.

The Feature That Impressed Me Most: The Mind Map

I was most sceptical about the mind map. This is genuinely complex visualisation work — SVG rendering, zoom and pan mechanics, force-directed layouts, level-of-detail algorithms. Normally this is the kind of thing that requires a specialist engineer and several weeks.

I described three completely different visualisation modes in a single prompt:

Time Drill — knowledge unfolds as a timeline. Start at the year level, zoom in to months, then days, then hours, then individual notes. Each zoom level reveals children around their parent. The parent stays visible at 30% opacity as a ghost anchor — so you never lose context of where you are in the hierarchy.

Topic Drill — knowledge organised by subject. Topic category hexagons at the top level, clicking one reveals its root tags as pill nodes, drilling further reveals subtags, then individual notes. The tag hierarchy from the database directly powers the drill-down structure.

Network mode — an orbital layout showing what is at the centre of your knowledge. The most-connected note becomes the hub. Its direct connections orbit it in the first ring at 220px radius. Second-degree connections form an outer ring at 420px. Isolated notes sit at the periphery. Faint concentric guide circles (like an orrery) make the ring structure immediately legible.

MeDo generated working SVG-based visualisations from these descriptions. The ghost parent mechanic — where drilling into a year node leaves a dim outline of the year behind as spatial context — came from one paragraph describing the desired user experience. The bezier connection lines that animate in using SVG stroke-dashoffset came from a single sentence specifying the animation.

The Integration That Required the Most Problem-Solving: PDF OCR

The PDF OCR pipeline was the most technically interesting challenge.

I wanted to use PaddleOCR from Baidu AI Studio — it is excellent for document text extraction. The API is straightforward: send a base64-encoded PDF, receive an array of recognised text strings.

The problem: CORS.

Browsers block direct cross-origin requests to external APIs. The fetch would fire, and immediately fail with TypeError: Failed to fetch — the browser refusing to complete the request before it even reached the server.

The solution is a server-side proxy. The browser calls your own backend, your backend calls the external API server-to-server where CORS does not apply, and your backend forwards the response back. Simple in principle. Previously required writing actual server code.

I described the problem to MeDo in plain language:

"The OCR API call is being blocked by CORS — the browser cannot call this endpoint directly. Fix this by creating a server-side proxy route /api/proxy/ocr that receives the request from the frontend, forwards it to the Baidu endpoint server-to-server, and returns the response."

MeDo generated the proxy route, updated the frontend fetch to target it, and handled upstream failure cases with a 502 error response. The fix worked on the first attempt.

The response parsing was also non-trivial. The PaddleOCR response nests extracted text inside:

response.result.ocrResults[i].prunedResult.rec_texts

A multi-level nested array structure. I described the exact path to MeDo and it generated correct parsing code that joins all rec_texts arrays across all pages into a single clean text string for AI summarisation.

What Broke (Honest Account)

I am not going to pretend this was frictionless. Here is what broke and why:

Tag hierarchy duplicates. The tag system creates parent-child tag relationships automatically. The findOrCreateTag function was matching tags on name only, not on (name, parent_id) together. This created duplicate history tags — one root-level, one nested under other. Fix: always match on both name AND parent_id simultaneously.

The save button going silent. After adding the tag hierarchy system, the Save button stopped doing anything. No errors, no network calls, just silence. Root cause: a Promise chain was returning early when tag resolution threw an exception, and the error was being swallowed. Fix: wrap tag resolution in try/catch with tags = [] fallback — tags failing must never prevent a note from saving.

Anonymous session UUIDs. The database owner_id column was typed as UUID. Anonymous sessions were generating IDs like anon-17780529566 — valid strings, invalid UUIDs. Every anonymous save failed silently. Fix: generate proper UUID v4 strings for anonymous sessions using the standard hex replacement algorithm.

OCR token management. The initial design had separate API Key and Secret Key fields for OAuth flow. The actual Baidu AI Studio app uses a single bearer token with no OAuth. Prompted MeDo to simplify the key management to a single token field once I had the real API documentation.

CORS on OCR (described above). Not a MeDo failure — a fundamental browser security constraint. Solved with the proxy architecture.

The Tag Hierarchy System

This deserves its own section because it was the most architecturally interesting piece.

Tags in Neuron are not a flat list. They form a tree:

technology (root — permanent)
  └── artificial-intelligence (domain)
        └── neural-networks (specific)
              └── backpropagation (detail)

Eight root categories are permanent and cannot be deleted. Every other tag must have a parent. Maximum depth of four levels.

When AI generates tags for a new note, it returns a hierarchy array:

[
  { "tag": "technology", "parent": null },
  { "tag": "artificial-intelligence", "parent": "technology" },
  { "tag": "neural-networks", "parent": "artificial-intelligence" },
  { "tag": "backpropagation", "parent": "neural-networks" }
]

Only the leaf tags (those not appearing as a parent of any other tag in the array) are saved to the note. Parent tags are implied through ancestry.

This structure powers the Topic Drill mind map — each drill level corresponds to one depth level of the tag tree. It also powers the Library tag filter panel, where selecting a parent tag automatically includes all descendant notes.

Getting MeDo to implement this correctly required the most precise prompting in the entire project. The key insight: describe the data structure as a user experience, not a schema. "Tags form a hierarchy where clicking a parent tag in the filter shows all notes with that tag or any of its child tags" produced correct implementation. "Create a self-referential foreign key on the tags table" produced a schema confirmation with no UI.

What I Would Do Differently

Start with the data model described as user flows. The earliest version of Neuron had a flat tag array on notes. Retrofitting a hierarchy system onto an existing schema caused most of the bugs. Starting with "tags can have child tags, and a note can be tagged at any level of the hierarchy" in the initial master prompt would have generated the right structure from day one.

One edge case per prompt. When I described multiple fix scenarios in one message, MeDo sometimes fixed one and introduced a regression in another. The most reliable workflow: one specific problem, one focused description, one test before the next prompt.

Describe empty states and error states upfront. The initial prompts focused on the happy path. Adding empty states, loading states, and error states as afterthoughts required going back to every screen. Describing them in the initial prompt would have been more efficient.

Debug logging panels are incredibly useful. Adding a visible in-app debug log to the Capture screen — showing each step of the processing pipeline with timestamps — was the single best debugging decision I made. Being able to see "OCR returned 4 pages, 183 text blocks, first 120 chars: Nathan Lerner..." in the UI while testing was worth more than any amount of console.log hunting in DevTools.

The Honest Answer to "Can No-Code Build Real Apps?"

Yes. With caveats.

The limiting factor was never MeDo's capability. Every feature I described carefully enough was generated correctly. The features that broke were the ones I described vaguely, or where I described multiple things at once, or where I used technical terminology (schema, endpoint, foreign key) instead of user-experience language.

The skill required is not programming. It is product thinking expressed precisely in natural language. Knowing what you want the user to experience. Knowing the edge cases. Knowing what happens when things go wrong. Being able to describe a user interaction from first click to final state without ambiguity.

That skill is arguably harder than writing the code itself, because it requires understanding both the product and the engineering constraints well enough to describe them accurately to someone — or something — that will implement exactly what you say.

Neuron is a genuinely useful application that I am continuing to develop. It was built in days. It has a full backend, real authentication, external API integrations, a complex data model, and three different interactive visualisation modes.

That is what MeDo makes possible when you learn to describe software well.

Try It / Links

Neuron app: https://app-aw8hrevmfcox.appmedo.com/
MeDo platform: https://medo.dev
Demo video: https://www.youtube.com/watch?v=PtNkFK_Q7W4
Hackathon submission: https://devpost.com/software/mindweave-f2wiv4

*Built for the MeDo Hackathon 2026

Tags: BuiltWithMeDo nocode ai buildinpublic productivity javascript react supabase hackathon webdev showdev

DEV Community: Souren Ghosh