DEV Community: Ibrahim Edhem Harbutlu

I'm not a software engineer, but I shipped an Obsidian plugin with zero servers and offline licensing

Ibrahim Edhem Harbutlu — Fri, 19 Jun 2026 18:36:32 +0000

I am an engineer by training, but not a software engineer. I have no coding background. Over the past months I have been building and shipping small commercial tools entirely with AI assistance, and the latest one is an Obsidian plugin. I want to write up the decisions that went into it, because a few of them go against how most paid AI plugins are built.

The problem I was solving for

I kept seeing the same complaint across reading and PKM communities: people sync hundreds of highlights from Readwise, Snipd, or Kindle into their vault, and then never open the folder again. The highlights pile up into a graveyard. The effort of saving them is spent, but nothing comes back out.

I am not a heavy highlighter myself. I found this pain through research, not from my own giant pile of notes. That distinction matters to me, so I am stating it plainly rather than inventing a personal origin story.

The plugin reads the whole folder and writes one synthesis note: a summary, the key claims, and a topic list per source, then the themes that recur across more than one source, with where sources agree and where they pull apart.

Decision 1: no server, at all

Most paid AI Obsidian plugins I looked at validate a subscription against a backend. A typical one runs a Cloudflare Worker, checks your license against the cloud, and bills monthly. That is a reasonable business model, but it means a server I have to run, a database, a recurring cost, and a place where user data could flow.

I went the other way: zero server, zero database, zero recurring cost. The plugin runs entirely on the user's device. There is nothing for me to operate and nothing to leak on my side.

Decision 2: bring your own key (BYOK)

The plugin uses the user's own API key for whichever provider they pick (Anthropic, OpenAI, OpenRouter, or any OpenAI-compatible endpoint). I never see their key and I never proxy their requests.

One honesty point I want to be clear about, because it is easy to oversell: BYOK does not mean the data stays on the device. To synthesize highlights, the plugin sends the highlight text to whatever model provider the user configured. So the accurate privacy claim is "no server, no account, no backend data collection on my side", not "your notes never leave your machine". I refuse to make the second claim because it is not true for any BYOK tool that calls a hosted model.

Decision 3: offline license verification with Ed25519

If there is no server, how do you sell a Pro license? I used offline signature verification. Each plugin has its own Ed25519 keypair. The private key lives only in my password manager. The public key is embedded in the plugin. A license key is a small signed payload: product id, email, issue date, plus a detached signature.

Verification is fully offline using tweetnacl:

import nacl from "tweetnacl";

// publicKey embedded in the plugin, payloadBytes + signature decoded from the license key
const ok = nacl.sign.detached.verify(payloadBytes, signature, publicKey);

If it verifies and the product id matches, Pro is active. No network call, no phone-home, works on a plane. A note for anyone trying this: @noble/ed25519 did not work in Obsidian's Electron environment for me, tweetnacl did.

The free tier is a lifetime cap, not a monthly reset

The free tier allows 3 syncs total, for the lifetime of the install, not 3 per month. A monthly reset lets people wait out the counter and never convert. A lifetime cap creates a real decision point. Generating the report from already-synced highlights stays free forever.

On building this without being a software engineer

The whole thing is TypeScript, and I wrote essentially none of it by hand. Claude wrote the code, I made the product and architecture decisions, tested every step in Obsidian, and pushed back when something was wrong. The parsing is deliberately defensive because highlight exports vary wildly between people's templates: callout blocks, heading-plus-bullet, block ids, or plain text all have to be read, with a whole-body fallback when no markers are found.

It is in the Obsidian community plugin directory now. If you have a highlight backlog like this, I would genuinely like to hear how you currently deal with it, by hand, with a Dataview query, or not at all.

GitHub: https://github.com/ibrh96-prog/obsidian-highlights-synthesizer

Obsidian directory: https://community.obsidian.md/plugins/highlight-inbox-synthesizer

I kept losing leads because I was too slow to check my inbox. So I automated it.

Ibrahim Edhem Harbutlu — Wed, 17 Jun 2026 21:16:59 +0000

For the last few months I was running everything through a basic contact form on a side project. Every time someone filled it out, I had to remember to check my email, copy their info into a spreadsheet, and reply manually. Half the time I forgot. A couple of leads went cold because I noticed the email two days late, which is annoying when you're the one who built the form in the first place.

So I built an n8n workflow to handle it instead of relying on my own memory.

What it actually does

Seven nodes, end to end:

A webhook catches the form submission
A Set node normalizes the fields (name, email, message, date) regardless of which form tool sent them
An IF node checks the email is present and contains an @; anything that fails gets dropped silently, so bot spam never touches my spreadsheet
Google Sheets appends the lead as a new row
Gmail sends me an internal notification
A second Gmail node sends the person an automatic "we got your message" reply
A NoOp node closes out the run

The whole thing fires the second someone hits submit. No checking inboxes, no copy-paste, no two-day delay.

The two things that actually took effort

Field name mapping. Every form tool sends data slightly differently. Tally, Jotform, Typeform, a raw HTML form, sometimes the fields show up nested under body, sometimes flat. I put all the mapping in one Set node early in the chain. If I switch form tools later I only update expressions in that one node instead of hunting through the whole thing.

Pulling data by node name instead of position. Both Gmail nodes reference the Set node directly, something like {{ $('Set').item.json.email }} rather than {{ $json.email }}. That way if I reorder nodes later, or stick something new in the middle, the emails don't quietly break because they were reading from whatever happened to run right before them.

The spam filter is also worth calling out. It's nothing clever, just "is the email field non-empty and does it contain an @ sign," but it cut a noticeable amount of junk before it ever touched my sheet.

Why I'm posting this here

A couple of people asked how I built it, so I cleaned it up, wrote a proper install guide, and packaged the whole thing as a template. I also just wanted to see whether a personal automation could hold up as an actual product, separate from the curiosity.

If you're dealing with the same problem, form submissions you have to manually track, the template is on Gumroad: https://ibrh96.gumroad.com/l/gqvnho. Credentials ship empty, you connect your own Google account, and it runs on n8n Cloud or self-hosted.

If you've built something similar, I'm curious how you handled spam filtering. Mine is intentionally basic (email present, contains an @, that's it) and I keep wondering if I'm missing an obvious next step.

Cloudflare Pages + Railway + Neon: deploying a self-hosted app for $0

Ibrahim Edhem Harbutlu — Sat, 06 Jun 2026 10:42:22 +0000

Cloudflare Pages + Railway + Neon: deploying a self-hosted app for $0

No software background. Built a license key manager called KeyMint with Cursor, deployed it across three free-tier services, and hit five errors I didn't see coming. Here's what they were.

The stack

Frontend on Cloudflare Pages, API on Railway, database on Neon. All free. React 19 + Vite on the frontend, Express 5 + TypeScript on the backend, standard PostgreSQL through Drizzle ORM.

Error 1: Railway free tier limit

Went to create a new Railway project for KeyMint. Railway said no — already at the limit with two existing projects.

Fix: don't create a new project. Add KeyMint as a new service inside the existing project. Railway lets you run multiple services under one project. I had just assumed each app needed its own. Two minutes to figure out, zero code changes.

Error 2: Supabase was full too

Free tier on Supabase is two projects. Both slots were taken.

I switched to Neon instead of deleting something. Same free-tier PostgreSQL, same pg driver, different connection string. Swapped the DATABASE_URL in Railway's env vars and moved on. No code changes.

If you're on free tiers, don't get attached to one database host. They're interchangeable.

Error 3: pg in the wrong package.json

API server deployed and immediately crashed on boot. Generic module resolution error, not helpful.

The actual problem: pg was a dependency of the shared lib/db package, not of @keymint/api-server directly. esbuild bundled the api-server, marked pg as external because it wasn't in that package's own dependencies, and at runtime Node couldn't find it.

Fix — add pg directly to the api-server's package.json:

{
  "dependencies": {
    "pg": "^8.11.0"
  }
}

Monorepo gotcha. esbuild doesn't crawl the whole workspace to figure out what you need at runtime. If a dep lives in a sibling package, it gets left out of the bundle.

Error 4: Wrong Cloudflare product

Cloudflare has Pages and Workers. They look similar in the dashboard. They are not the same thing.

I ended up in Workers first. Workers wants wrangler deploy, a config file, edge functions. That's not what I needed — I just wanted to host a Vite build.

Pages is the right product. Connect GitHub, set build command, set output directory, done.

Settings that worked for a pnpm monorepo:

Build command: pnpm install && pnpm --filter @keymint/web build
Output directory: artifacts/keymint/dist
Environment variable: NODE_VERSION=20

That last one matters. Cloudflare Pages defaults to an older Node version. Without setting it to 20, the build fails on syntax it doesn't recognize. Spent 15 minutes on that.

Error 5: wrangler deploy kept failing

Related to error 4 — while I was in the Workers section, the dashboard was telling me to run wrangler deploy. It kept failing because I had no wrangler.toml and wasn't writing a Worker.

Once I found the Pages section and used the GUI deploy flow instead, it worked.

This sounds obvious. It wasn't obvious when I was in it.

End result

KeyMint is live at keymint-rho.vercel.app. Database on Neon, free across the board.

Source code on GitHub: github.com/ibrh96-prog/keymint

Packaged it as a boilerplate if you want to skip the setup: ibrh96.gumroad.com/l/nvkfg — $49, one-time, full source.

Update: I've since moved the whole thing to a single Vercel project — Vite frontend and the Express API as one serverless function, same origin. The Cloudflare Pages + Railway split here still worked, but Railway's free credit runs down and the demo kept going to sleep. The migration had its own set of errors (including a great one where pnpm build:api died with "command not found" because of a stale root-directory setting). That's a separate post.

Built with Cursor. 0 sales so far — testing whether dev.to drives any.

I built a self-hosted license key manager for my Gumroad products (0 sales so far)

Ibrahim Edhem Harbutlu — Thu, 04 Jun 2026 23:16:40 +0000

I sell boilerplates on Gumroad. Source code, you download a ZIP, you run it. Over the last few months one thought kept nagging me: if I ever wanted to actually license one of these products, or sell a paid tool that checks a key when it runs, I would have to sign up for some license-key SaaS and pay monthly for the privilege. The cheap ones start around 20 a month. For a side project that makes nothing yet, that math is bad.
So I built the thing instead. It's called KeyMint, and it's a license key manager you host yourself.
Demo (with seeded data so it doesn't look like an empty shell): https://keymint.pages.dev
What it actually does
You create a product, generate a batch of keys, and hand them out. Then your own software checks a key with a single request:

const res = await fetch("https://your-keymint.app/api/validate", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ key, productSlug: "subsaver", activate: true }), }); const { valid } = await res.json();

That valid boolean is the whole point for most integrations. The response also tells you why a key failed (revoked, expired, activation limit hit, wrong product) and how many activations are left, so you can do seat limits or device limits without writing that logic yourself. Pass activate: true and the check also burns one activation.
The dashboard handles the boring side: bulk key generation, revoke, expiry dates, and an activity log that records every validation attempt with its result and IP. I added a 30-day trend chart mostly because an empty dashboard is depressing and a populated one sells the idea in two seconds.
The stack, and the part that fought back
React 19 and Vite on the front, Express 5 and Drizzle on the back, Postgres underneath, all in a pnpm monorepo. Nothing exotic.
Deploying it as a broke person was the interesting part. The frontend is static, so it went on Cloudflare Pages for free. The API went on Railway. Then I hit Railway's free-tier limit when I tried to add a second service, and my Supabase free projects were already full from two earlier apps. So the database ended up on Neon, which gives you a real Postgres instance on a free tier that doesn't expire. Three providers, zero dollars a month. The schema and a seed script are in the repo, so spinning up your own copy is a SQL paste and two deploys.
One gotcha worth writing down: I bundle the API with esbuild, and pg has to be listed as a direct dependency of the server package or the deployed bundle can't find it at runtime. It built fine locally and crashed on first boot until I caught that. Exactly the kind of thing that wastes an hour.
Honest status
Zero sales. The product went live today. I have done this enough times now (this is my fourth boilerplate) to know that "published on Gumroad" and "someone bought it" are very far apart, and the gap is distribution, not the product. Writing this post is part of closing that gap, which I am aware is a little circular.
It's 49 dollars, MIT licensed, you get the full source. What it does not do, on purpose: it does not take payments (it manages keys, not money), and the admin dashboard has no auth by default because it's meant to run privately. The README shows the roughly ten lines to gate it if you want to expose it. No bank integrations, no hosted version, no monthly anything.
Link, if you want it: https://ibrh96.gumroad.com/l/nvkfg
The other ones
If you're the type who buys boilerplates, these are the other three I've shipped, same stack, same idea of skipping the setup grind:

SubSaver, a subscription and savings tracker: https://ibrh96.gumroad.com/l/gytqdv
FreelanceFlow, a client, project and invoice tracker: https://ibrh96.gumroad.com/l/bcsufq
MetricMint, an MRR dashboard for indie hackers: https://ibrh96.gumroad.com/l/jwdmao

A real question
Two things I keep going back and forth on, and I'd take actual opinions:

For a tool like this, does keeping the admin side auth-free by default make it feel unfinished, or is "private by default, gate it yourself" the right call for a starter kit?
If you sell digital products, how do you handle licensing today? Do you bother at all, or just trust people? I genuinely can't tell if I built something useful or solved a problem only I have.

I Finally Shipped MetricMint — My MRR Dashboard for Indie Hackers (Built with GitHub Copilot)

Ibrahim Edhem Harbutlu — Tue, 02 Jun 2026 19:39:24 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

MetricMint is an MRR dashboard for indie hackers who want to track their revenue without signing up for another SaaS tool.

The idea had been sitting in a notes file for months. I build and sell web app boilerplates on Gumroad — things like subscription trackers and freelance project managers. And I kept hitting the same wall: I had no clean way to track my own monthly recurring revenue. Every MRR tool I found was either way too big for what I needed, expensive, or required connecting a payment processor before you could see anything useful.

So I wanted something simple. Paste your numbers in. See your trends. That's it.

Live demo: https://metricmint.vercel.app

GitHub: https://github.com/ibrh96-prog/metricmint

Features: MRR dashboard with month-over-month growth, manual revenue entry (no bank sync, no Stripe connect), 12-month area chart, churn tracking, dark/light mode, PostgreSQL + Drizzle ORM on the backend, mobile responsive.

Stack: React 19 + Vite, Tailwind CSS v4, shadcn/ui, Express 5 + TypeScript, Drizzle ORM, Recharts, deployed on Railway with Supabase.

Demo

Live: https://metricmint.vercel.app

Seeded with realistic data so you can explore everything right away.

The Comeback Story

Where it started

I started MetricMint on a weekend when I got annoyed enough to actually do something about not tracking my revenue. I scaffolded a React frontend, wrote a couple of API routes, and then... stopped. Something came up. The folder sat on my desktop for weeks.

When the Finish-Up-A-Thon came along I figured this was the one to revive.

Before:

Two broken React components, no routing
No database schema at all
One API route — a health check
No dark mode
No way to deploy it
No seed data, so the demo looked completely empty
No README

What changed

I committed to finishing it properly. Not just getting it to run, but shipping it to a standard where I could actually sell it.

After:

Full MRR dashboard with 5 metrics
PostgreSQL with Drizzle ORM, pushed to Supabase
8 REST endpoints, OpenAPI documented
12-month area chart
Dark / light mode
Mobile responsive
Railway deployment (API and frontend as separate services)
Seed data SQL so the demo looks like a real product in use
Full README with setup instructions and schema docs

My Experience with GitHub Copilot

I should be upfront about one thing: I'm not a software developer. No CS background, no formal training. I build web apps with AI assistance and sell the results as boilerplates on Gumroad. So I wasn't using Copilot to speed up code I already understood. I was using it to build things I genuinely couldn't have built alone.

The database layer was the clearest example. I described the schema in plain English and Copilot generated the Drizzle ORM schema, migration logic, and Zod validation schemas. I didn't write any of that by hand.

The API routes went the same way. I described what each endpoint should do and Copilot wrote the Express handlers, validation, and error handling. It also caught a bug I'd never have noticed on my own: the monthly trend aggregation was grouping entries incorrectly for records near midnight UTC.

The monorepo wiring was the hardest part. MetricMint uses pnpm workspaces with shared packages across the DB client, API spec, and generated React Query hooks. Getting those cross-package TypeScript imports to resolve in a Railway production build is genuinely tricky. Copilot figured out the problem (tsc not resolving workspace paths at build time) and suggested switching to esbuild with explicit bundle flags. Three minutes. I think that would have taken me a full day otherwise, if I figured it out at all.

What I had to manage myself:

Scope. Copilot kept suggesting things I didn't ask for — authentication, Stripe integration, CSV export. I had to be explicit every time: no auth, no payments, keep it simple.

Stack consistency. When I wasn't precise upfront, Copilot would sometimes drift toward Prisma instead of Drizzle, or axios instead of React Query. I learned to front-load the full stack spec at the start of every prompt.

The seed data also needed a second pass. The first version had round numbers and perfectly linear growth — it looked fake. I asked Copilot to add realistic variance: a couple of dips, one rough month, uneven growth. The demo is a lot more believable now.

Bottom line:

MetricMint went from a dead folder on my desktop to a live, deployed product in one session. That's what actually happened. I don't have a better way to describe it than that.

Update (June 2026): I've since moved MetricMint off Railway to a single Vercel project — Vite frontend and the Express API as one serverless function on the same origin. Railway's free credit runs down over time and the demo kept going to sleep, so the buyer's click sometimes landed on a cold or dead app. On Vercel the demo stays up. The DB is on Supabase's pooler, so I kept postgres.js (made serverless-safe with prepare:false and max:1) rather than swapping to a Neon-only driver. New live URL above.

I built a freelance client + invoice tracker in ~3 hours using Cursor — here's everything I shipped

Ibrahim Edhem Harbutlu — Sun, 31 May 2026 17:10:09 +0000

Three hours. That's roughly how long it took me to go from blank screen to a
working full-stack app with a real database.

I'm not a developer by background. I use Cursor as my main build tool and
Supabase for the database. No local PostgreSQL setup, no fighting with configs —
just a Transaction Pooler connection string and a prompt.

Here's what came out: FreelanceFlow, a client and project tracker built
specifically for freelancers who are tired of juggling invoices in spreadsheets.

What it does

Client management — add clients, track contact info, see all their projects in one place
Project tracking — status (active, on hold, completed), deadlines, linked to a client
Invoice generation — create invoices per project, mark them paid/unpaid, track totals
Dashboard — monthly revenue, outstanding amount, active project count, recent activity
12-month revenue chart built with Recharts
Dark/light mode, mobile responsive down to 375px

No bank sync. No Stripe. No OAuth. You install it, you own it, you run it
yourself. That was intentional — the simpler the setup, the more useful it
actually is.

The stack

React 19 + Vite, Express 5, TypeScript, PostgreSQL via Drizzle ORM,
Tailwind CSS v4 + shadcn/ui, Framer Motion, Recharts. pnpm workspaces
monorepo. The full API contract is defined in OpenAPI 3.1 and Recharts
handles the charts.

What Cursor handled

Honestly, most of it. The entire monorepo structure, all the API routes,
the Drizzle schema, the React Query hooks, the dashboard layout. I wrote
the initial prompt, reviewed the output, fixed two routing bugs, and
that was it.

The part I still had to think through: the invoice status logic and making
sure the revenue chart was pulling from real data, not placeholder seed data.
Those took an extra 20-30 minutes of iteration.

What I'm doing with it

I packaged it and put it on Gumroad for $49. The pitch is simple: if you're
a freelancer or developer who wants a working starting point instead of
spending 2-3 days on boilerplate, this is it.

Live demo: https://freelanceflow-flame-mu.vercel.app

Gumroad: https://ibrh96.gumroad.com/l/bcsufq

Honest take

Zero sales so far. I posted on Indie Hackers and got useful feedback —
the main note was that $39 was too cheap and the channel I was using
(IH) is better for feedback than for actual conversions. Both turned out
to be true. Price is now $49. Writing this post is me testing a different
channel.

I don't know if this will sell. But I do know the app works end-to-end,
the demo is populated with real data, and the code is clean enough that
a developer could extend it in an afternoon.

If you've built something similar or sold boilerplates before — what
actually drove your first sale?

Update (June 2026): I've moved the demo off Railway to a single Vercel project — Vite frontend and the Express API as one serverless function, same origin. Railway's free credit runs down and the demo kept going to sleep, so a click would sometimes land on a cold app. On Vercel it stays up. The DB is on Supabase's pooler, so I kept postgres.js made serverless-safe (prepare:false, max:1). New live URL above.