DEV Community: Memduh PANPALLI

A quiet Product Hunt launch showed me what my AI workspace was missing

Memduh PANPALLI — Thu, 18 Jun 2026 11:14:21 +0000

I launched Fluxerv on Product Hunt recently.
The launch was quieter than I hoped, but it showed me something useful: the product needed to get new users to the core value much faster.
Fluxerv is a workspace where notes can become working interactive tools.
Instead of switching from notes to an AI chat, then copying code somewhere else, you can type /ai inside a note and generate a working component directly in the document.
I recorded a short demo where I generated a World Cup-style group standings calculator inside a note.

The component is interactive:

score inputs update the standings live
points and goal difference are calculated automatically
the UI can be refined without leaving the page

The lesson for me was not simply “the launch was quiet. It was that first-run activation matters. If someone lands on the product and does not quickly reach the moment where a note turns into a working tool, the value is easy to miss.
So I’m now focusing on making that first working-component moment happen much earlier.

I’d love feedback from other builders and developers:

Is the value clear from the demo?
Would you use this workflow for planning, teaching, product work, or dev notes?
What part feels confusing or unnecessary?

Try Fluxerv:
https://www.fluxerv.com

I built a note app where /ai creates working tools inside the note

Memduh PANPALLI — Wed, 17 Jun 2026 06:14:25 +0000

I recorded a quick demo of Fluxerv to make the core idea easier to understand.

Fluxerv is a workspace where your notes can become working interactive tools.

In the demo, I typed /ai inside a note and generated a World Cup-style group standings calculator. The component runs directly inside the document:

score inputs update the standings live
points and goal difference are calculated automatically
the UI can be refined without leaving the page

That is the main idea: not a screenshot, not a static note, not a code block.

Notes that run code.

Demo video:

Fluxerv:

https://www.fluxerv.com

Product Hunt launch:
https://www.producthunt.com/products/fluxerv?launch=fluxerv

Fluxerv is live on Product Hunt today

Memduh PANPALLI — Tue, 16 Jun 2026 07:27:25 +0000

Fluxerv is live on Product Hunt today

After 3 months of building solo, today is launch day.

Fluxerv is a workspace where you type /ai in any note, describe a tool you need, and a working interactive component appears directly inside your document. Calculator, data formatter, color picker, anything you describe. The thinking and the output stay on the same page.

Free to start. 20% off Pro with code PH20OFF this week.

If you want to support the launch:

producthunt.com

What building alone actually feels like

Memduh PANPALLI — Thu, 11 Jun 2026 04:38:56 +0000

Nobody tells you what building alone actually feels like.

The blog posts make it sound clean. You have an idea, you build it, you launch. Maybe you hit some technical walls, you push through, and eventually things work out.

What they skip is the part where you sit in front of your laptop for three hours and produce nothing useful. Or the part where you ship something and hear silence. Or the part where you start questioning whether the whole thing even makes sense.

That part is most of it.

The decision load nobody warns you about

When you build alone, every single decision is yours.

Not just the technical ones. What to name things, how to price them, what to say on the landing page, which bug is worth fixing today and which one can wait. You make dozens of these calls every day, and most of them have no clearly right answer.

After a while, the weight of that accumulates. Decision fatigue is real, and it hits harder when there is no one to share it with.

The upside is that you move fast. No alignment meetings, no waiting for someone to sign off. But the downside is you also carry the full weight of every wrong call.

The silence after you ship

There is a specific feeling that comes after you push something live.

For a few minutes you feel good. Then you open analytics. Then you wait. Then you check again. Then you start wondering if anyone will ever find this, or if the landing page copy is wrong, or if you should have built something else entirely.

Shipping is supposed to feel like progress, and sometimes it does. But more often it just opens a new kind of uncertainty.

The work does not stop at launch. In some ways it gets harder.

Progress that does not look like progress

Software development has this property where nothing visible happens for a long time, and then suddenly it does.

You spend days tracking down a bug. You rewrite a component that looked fine but was causing subtle issues. You read documentation for a feature you thought would take an hour. None of that shows up anywhere. There is no visible output.

Then one day the thing works, and the next thing works, and the day after that you have something you could not have imagined a week ago.

The hard part is the in-between. You have to keep going during the periods when it does not look like you are going anywhere, because usually you are.

The comparison trap

You will spend time looking at what other people are building.

Some of it is useful. You learn things, you get ideas, you see what is working. But a lot of it just makes you feel behind. Someone else launched faster, has more users, raised money, built a team.

The problem with comparing is that you are seeing their output and comparing it to your process. You do not see the false starts, the pivots, the things they tried that did not work. You see the finished thing and measure yourself against it.

The only comparison that actually helps is you versus yourself last week.

What keeps you going

Everyone has a different answer to this. Some people are driven by the users they already have. Some people just need to know the thing is possible. Some people genuinely enjoy the building itself and treat everything else as secondary.

What probably does not work, at least not long term, is pure willpower. Grinding through something you do not care about is exhausting in a way that compounds quickly.

The founders who stick with it tend to have some version of the same thing: they actually care about the problem. Not the startup, not the metrics. The problem. And they are curious enough about the solution that building it keeps being interesting even when it is hard.

The part that does not go away

Here is the honest version: building alone does not get easier. You just get better at knowing what to expect.

The silence after a launch still happens. The stretches where nothing seems to move still happen. The moment where you wonder if it is worth continuing still happens.

What changes is that you stop treating those things as signals that something is wrong. They are just part of it.

The people who keep going are not the ones who found a way to skip that part. They are the ones who decided to keep going anyway.

Building something? fluxerv.com

What I learned building a SaaS alone for 3 months

Memduh PANPALLI — Wed, 10 Jun 2026 15:37:06 +0000

I didn't have a co-founder. No team, no office, no standup meetings. Just me, a laptop, and a feature I couldn't get to work.

The feature was the whole point of the app.

You type /ai in a document, describe a tool you need, and a working interactive component appears inline. Not a code block. A real, running UI inside your note.

Simple to describe. Hard to build.

The part that broke me first

Getting AI-generated code to render safely inside a rich text editor is not straightforward.

The component had to be sandboxed so it couldn't touch the parent app, but still functional enough to do useful things. I got that wrong more times than I want to admit.

The iframe configuration, the CSP headers, the streaming approach, each one had an edge case I didn't see coming. I'd fix one thing and break another.

Some days the only visible progress was a slightly better understanding of why it didn't work.

The moment I knew it could ship

Then one day I typed a prompt, and the component started generating.

Not a broken render. Not a half-working preview. A real, interactive tool appearing inside the document as the AI wrote it.

That was the moment I thought: this is different.

Not because the code was perfect, but because the experience felt like something that didn't exist before. The tool and the thinking behind it, living in the same place.

After that, finishing felt possible.

What three months alone actually teaches you

You make every decision.

Tech stack, pricing, copy, color of a button. Nobody to delegate to, nobody to blame.

It's clarifying in a way I didn't expect. You stop overthinking and just ship, because the alternative is sitting still.

You also learn what the product actually is by building it. My initial idea shifted significantly. The core stayed, but the details changed constantly as I ran into real problems.

The hardest part wasn't the code. It was the stretches where nothing seemed to be moving.

Progress in software is invisible until suddenly it isn't.

Where it is now

Fluxerv is live. Free to start, no waitlist.

I'm launching it on Product Hunt on June 16, 2026, with 20% off Pro using code PH20OFF.

If you're building something alone and feel stuck, keep going. The gap between "this doesn't work" and "this is exactly what I imagined" is usually smaller than it looks.

https://www.fluxerv.com

Why I built a notes app instead of yet another AI chatbot

Memduh PANPALLI — Wed, 10 Jun 2026 11:00:54 +0000

Every developer I know takes notes. Meeting notes, architecture ideas, quick references — it all ends up somewhere, usually scattered across five different tools.

I was doing the same thing. And at some point I noticed a pattern: I'd write a note describing a UI idea, then open a separate tool to actually build it, then come back to the note. The thinking and the output lived in completely different places.

Most AI tools I looked at had the same shape: you ask, it answers. You copy the output, paste it somewhere, run it. The AI is a consultant you have to carry the work for.

That gap bothered me more than I expected.

The gap nobody talks about

So I started thinking about what it would look like if the output just stayed where the thinking happened. Not a code block you copy. Not a link you follow. A working, interactive component, right inside the note.

That's the core idea behind Fluxerv. You type /ai, describe what you want, and a live component appears in your document. A calculator, a color picker, a data formatter — whatever you need. You can refine it with natural language, share the whole document with anyone, and the component works for them too.

Why notes matter as much as the AI

The notes part matters as much as the AI part. A developer writing about a feature doesn't just want to describe it. They want to show it. When the component and the context live on the same page, the document becomes something you actually use — not just something you wrote once and forgot.

How it started

I didn't set out to build another notes app or an AI coding assistant. I just kept running into the same friction, and eventually the only way to get rid of it was to build the thing myself.

If you've felt the same gap — fluxerv.com

I built /ai inside a notes app -here's how I render generated UI components safely

Memduh PANPALLI — Wed, 27 May 2026 08:35:55 +0000

I take a lot of notes while I'm working. Meeting notes, quick ideas, system design sketches — all of it ends up somewhere.

The frustrating part was never writing the notes. It was what happened after. I'd describe a UI idea in a note — a color picker, a calculator, a data formatter — and then I'd have to open a separate editor, build the thing, test it, and come back. The note and the tool lived in completely different places.

At some point I thought: what if the tool just lived inside the note?

That's what I've been building for the past few weeks. You type /ai in the editor, describe what you want, and a working interactive component appears inside your document. Not a screenshot. Not a code block. A real, running UI.

Here's what that looks like mid-generation:

This is the streaming moment — the AI is writing the component live, and it appears inside the note as it generates.

Let me walk through how I built this.

The editor foundation

I'm using Tiptap — a headless, extensible rich text editor for React. Tiptap is built on ProseMirror, which means you can define custom nodes: blocks that behave however you want inside the document.

I created a custom AiNode — a Tiptap node that holds generated HTML/CSS/JS as a string in its attributes. When the node renders, it shows a live iframe. The node persists to Supabase as part of the document's JSON content.

const AiNodeExtension = Node.create({
  name: 'aiComponent',
  group: 'block',
  atom: true,
  addAttributes() {
    return {
      code: { default: '' },
      prompt: { default: '' },
    }
  },
  // ...
})

Simple enough. The hard part was getting the code into the node while streaming.

The streaming problem

The AI backend uses Gemini 2.5 Flash via Server-Sent Events. The model streams the HTML, CSS, and JS as one big string — character by character.

The problem: I needed to show this output live inside the Tiptap node while it was still being generated. Users shouldn't stare at a spinner for 10 seconds.

My first approach was to update the rendered output on every streamed chunk. It worked, but it caused too many re-renders and made the editor feel heavy.

The better approach was to decouple streaming from rendering: accumulate the generated code in a ref while the stream is active, then render the final result once inside a sandboxed iframe.

const accumulated = useRef('')

// On each chunk:
accumulated.current += chunk

// On stream close:
editor.commands.updateAttributes('aiComponent', {
  code: accumulated.current
})

The node re-renders once, the iframe appears, the component runs.

The sandbox setup

The iframe uses this sandbox configuration:

<iframe
  sandbox="allow-scripts"
  srcdoc={generateSrcdoc(code)}
/>

Notice what's missing: allow-same-origin.

This is intentional and critical. Without allow-same-origin, the iframe cannot access localStorage, cookies, or the parent document's DOM. The AI-generated code runs in complete isolation. It can't read your tokens, it can't exfiltrate data, it can't touch anything outside its own sandbox.

allow-scripts alone is enough for interactive components to work — timers, event listeners, DOM manipulation inside the frame, all fine.

I also inject Tailwind CSS via CDN inside the iframe's srcdoc so generated components can use utility classes without any build step:

function generateSrcdoc(code) {
  return `
    <!DOCTYPE html>
    <html>
      <head>
        <script src="https://cdn.tailwindcss.com"></script>
        <style>
          body { background: #09090b; margin: 0; padding: 16px; }
        </style>
      </head>
      <body>${code}</body>
    </html>
  `
}

The refine system

Once a component is generated, users can update it with natural language. There's a "Refine" button in the component toolbar. You type something like "make the background darker" or "add a reset button" — and the component updates.

The naive approach would be to regenerate the entire component from scratch. That works but it's slow and wasteful.

Instead, I built a /api/edit endpoint that receives two things: the current component code and the edit instruction. The system prompt wraps them together:

You are editing an existing UI component.

Current code:
[CURRENT_CODE]

Edit instruction:
[INSTRUCTION]

Return only the updated full component code. No explanations.

The model returns the full updated component — but it only needs to reason about the delta. In practice this is faster and produces more coherent edits than full regeneration.

The response streams the same way as generation, and the node updates when it's done.

What I got wrong

A few things that cost me time:

Stale closures in Tiptap. If you reference editor inside a useEffect without including it in the dependency array, you'll be working with a stale editor instance. Commands will silently fail. This one took a while to track down.

Rate limiting before you think you need it. I added Upstash Redis rate limiting to both endpoints early on. Good call — during testing I hit Gemini's limits faster than expected. Shared rate limiter utility across both endpoints so I wasn't duplicating logic.

The middleware gap. My Next.js middleware was redirecting unauthenticated users to login — including the /share/ route for public documents and the /api/ routes. Had to explicitly whitelist these paths. Simple fix, annoying to debug.

Where it is now

The app is called Fluxerv. It's live at fluxerv.com — free to start, no waitlist.

Here's a 2-minute demo of it generating a pomodoro timer from a single prompt:

// Detect dark theme var iframe = document.getElementById('tweet-2059512944497660320-402'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2059512944497660320&theme=dark" }

The stack: Next.js (App Router), Tiptap v3, Supabase, Gemini 2.5 Flash, Tailwind CSS, Upstash Redis.

Launching on Product Hunt on June 16 — 20% off Pro with code PH20OFF during launch week.

If you've built something similar or ran into the same iframe/streaming problem, I'd love to hear how you solved it. Drop a comment. And if you want to try it yourself — fluxerv.com