DEV Community: Oleksandr

Why Most Notion Templates Fail (And How to Actually Use Them)

Oleksandr — Sun, 01 Nov 2026 15:19:09 +0000

You downloaded a 47-database dashboard. It looked amazing on Twitter. You spent 20 minutes setting it up. You used it for exactly 3 days.

Now it sits in your sidebar collecting digital dust.

As developers, we love optimizing our tools. We build custom CI/CD pipelines, configure Neovim from scratch, and spend hours tweaking our terminal themes. But when it comes to personal productivity, we often fall into the same trap: Over-engineering the system instead of doing the actual work.

Here is why most Notion templates fail, and how to build a system that actually sticks.

The Problem: Cognitive Overload
Most templates fail because they are designed to look impressive, not to be used daily.

They have:

Too many databases (Tasks, Projects, Areas, Resources, CRM...)

Too many required properties (Status, Priority, Energy Level, Context...)

Too much friction.

When you open Notion and see a dashboard that requires you to fill out 5 different fields just to log a single task, your brain will do everything in its power to avoid opening it.

For developers (and especially for those of us with ADHD), friction is the enemy of consistency.

The Solution: The "3-Task" Rule
To fix this, we need to strip the system down to its bare minimum.

Instead of a massive "Life OS" with 50 interconnected databases, start with a single, flat database.

Limit your daily focus Your daily dashboard should only show you 3 tasks. Not 30. Not 10. Three.

Why 3? Because it forces you to prioritize. If you finish them early, you can pull from a "Backlog" or "Next" list. But waking up to a list of 40 tasks is a guaranteed recipe for decision paralysis.

Remove the properties Delete the "Energy Level" and "Context" fields. Keep only:

Task Name (Title)

Status (To Do, In Progress, Done)

Date (Optional, only if it has a hard deadline)

That’s it. If you need to add notes, put them in the page body, not in a new database property.

Automate the reset One of the biggest reasons people stop using a system is that it gets cluttered. You need a way to archive completed tasks automatically. In Notion, you can use a simple filter: Status is not Done for your daily view. The moment a task is checked off, it disappears.

How to make it stick
The perfect productivity system is the one you actually use. It doesn't need to look good on a screenshot; it needs to be fast.

If you are a developer, treat your Notion setup like a microservice. It should be:

Stateless: You can delete it and start over without losing your mind.

Decoupled: Your daily tasks shouldn't depend on your quarterly goals database being perfectly updated.

Fast: Opening your dashboard should take 0 mental effort.

What's next?
I recently wrote a deep dive on how to set up a minimalist Notion workspace that actually gets used, especially if you struggle with ADHD or burnout.

👉 Read the full guide on our blog: Why Most Notion Templates Fail

If you want a head start, we built a Minimalist ADHD Daily Planner that uses the 3-task rule. No fluff, no 47-databases. Just a clean, distraction-free interface to help you ship your tasks.

👉 Check out the ADHD Daily Planner here

What does your Notion setup look like? Do you prefer complex systems or minimalist lists? Let me know in the comments! 👇

How I Generated a 500-Page Localized Site Using Only PowerShell

Oleksandr — Wed, 28 Oct 2026 17:52:34 +0000

As developers, we have a bad habit of over-engineering everything.

When I decided to build jsonexlab.com to sell my focused Notion templates, my first instinct was to spin up a Next.js app. I thought: "I'll need a database for the products, i18n for the languages, and a CMS for the blog."

But then I looked at the requirements. I wasn't building a complex SaaS with user authentication. I was building a static catalog of digital products.

So, I did something crazy. I deleted the Node.js setup, opened PowerShell, and wrote a script to generate raw HTML. Here is how I did it, and why it works.

The "No Framework" Stack

Hosting: Cloudflare Pages (Free tier, unlimited bandwidth).
Generation: PowerShell scripts.
Styles: Plain CSS.
Payments: Suby (Crypto).
Email: Web3Forms + Make.com + Brevo.

The result? A site with 500+ pages in 28 languages, zero hydration errors, zero JS bundles, and load times measured in milliseconds.

The Challenge: Translating 28 Languages

I wanted to sell my templates in Europe, Asia, and South America. That meant 28 different languages.

Doing this manually in React would have been a nightmare of JSON translation files. Instead, I wrote a PowerShell script that took my base English HTML file and applied a dictionary of translations to it.

Here is a simplified version of how the localization script works:


powershell
$translations = @{
    "es" = @{
        "You might also like" = "También te puede gustar";
        "Get PDF" = "Obtener PDF";
    }
    "de" = @{
        "You might also like" = "Das könnte dir auch gefallen";
        "Get PDF" = "PDF erhalten";
    }
}

foreach ($lang in $translations.Keys) {
    $html = [System.IO.File]::ReadAllText("base-template.html")

    foreach ($key in $translations[$lang].Keys) {
        $html = $html -replace [regex]::Escape($key), $translations[$lang][$key]
    }

    # Save to /es/index.html, /de/index.html, etc.
    [System.IO.File]::WriteAllText("$lang/index.html", $html)
}
To make Google happy, I also had to inject proper hreflang tags for all 28 languages into every single page. A simple loop handled that too.

The Real Challenge: Keeping Track of 30 Products
While the technical generation was fast, the business side was a mess. I had 30 different products: Debt Simulators, Freelancer Invoices, ADHD Planners.

I was losing my mind trying to remember which product was linked to which blog post, or which language version needed updating.

I realized I was trying to build a system for my system. So, I built a simple Notion dashboard (ironically, using the same "anti-bloat" philosophy I sell).
I tracked:

Product Status: (Draft, Finished, Live)

The Link Tree: (Which blog post links to which product)

The Tech Checklist: (Does it have an OG image? Is it in the sitemap?)

The Results
Speed: Because it's just static HTML, Cloudflare serves it instantly. No React hydration, no API calls, no database queries.

Cost: $0/month.

SEO: Because I control the raw HTML, I could perfectly inject JSON-LD schema (Product, BreadcrumbList, BlogPosting) without fighting a framework.

When Should You Do This?
If you are building a complex app with user accounts and real-time data, do not use PowerShell. Use Next.js, Remix, or whatever makes you happy.

But if you are building a content site, a landing page, or a digital product catalog, try going back to basics. Write a script that generates raw HTML. You might be surprised at how fast and simple it is.

How I Generated a 500-Page Localized Site Using Only PowerShell

Oleksandr — Wed, 28 Oct 2026 06:47:42 +0000

As developers, we have a bad habit of over-engineering everything.

But then I looked at the requirements. I wasn't building a complex SaaS with user authentication. I was building a static catalog of digital products.

So, I did something crazy. I deleted the Node.js setup, opened PowerShell, and wrote a script to generate raw HTML. Here is how I did it, and why it works.

The "No Framework" Stack

Hosting: Cloudflare Pages (Free tier, unlimited bandwidth).
Generation: PowerShell scripts.
Styles: Plain CSS.
Payments: Suby (Crypto).
Email: Web3Forms + Make.com + Brevo.

The result? A site with 500+ pages in 28 languages, zero hydration errors, zero JS bundles, and load times measured in milliseconds.

The Challenge: Translating 28 Languages

I wanted to sell my templates in Europe, Asia, and South America. That meant 28 different languages.

Here is a simplified version of how the localization script works:


powershell
$translations = @{
    "es" = @{
        "You might also like" = "También te puede gustar";
        "Get PDF" = "Obtener PDF";
    }
    "de" = @{
        "You might also like" = "Das könnte dir auch gefallen";
        "Get PDF" = "PDF erhalten";
    }
}

foreach ($lang in $translations.Keys) {
    $html = [System.IO.File]::ReadAllText("base-template.html")

    foreach ($key in $translations[$lang].Keys) {
        $html = $html -replace [regex]::Escape($key), $translations[$lang][$key]
    }

    # Save to /es/index.html, /de/index.html, etc.
    [System.IO.File]::WriteAllText("$lang/index.html", $html)
}

Stop Building Massive 'Second Brain' Dashboards. Here’s the Anti-Bloat Approach.

Oleksandr — Tue, 27 Oct 2026 13:57:05 +0000

Let me guess what happened with your last Notion setup.

You watched a video about "the ultimate second brain." You downloaded a template with 47 databases, 12 relations, and a dashboard that looked like a NASA control panel. You were excited for two days. By day four, you had 300 unread items, you were anxious every time you opened it, and you quietly archived the whole thing.

As developers, we love over-engineering. We love building complex systems. But when it comes to managing our own lives, freelancing, or tracking our finances, complexity is the enemy.

The Problem with "Ultimate" Templates

Most productivity templates are built for the sake of the template, not the user. They give you more:

More databases ("so you can track everything")
More views ("switch between kanban, calendar, timeline, table")
More customization

But more is the opposite of what a busy brain needs. What it needs is less, but clearer.

The "Anti-Second Brain" Approach

I got so tired of this that I built my own collection of templates. I did the opposite of what the "Notion gurus" do.

I built 30 tiny, focused systems. Each one solves exactly one problem. No bloat. No 47 databases.

Here are the three rules I follow:

One problem per template. If it's an invoice system, it doesn't have a habit tracker attached. When you open it, you know exactly what to do.
It must fit on one screen. If you have to scroll to find the main view, the design has failed.
A clean "done" moment. When you finish using it, you should know you're done. Close the tab.

For Example: The Freelancer's Invoice System

Instead of an "Ultimate Life OS", I built a Client & Invoice System. It tracks clients, projects, and overdue invoices. Nothing else.

Every freelancer has the same problem: a client owes you $1,200 for work you finished two weeks ago, and you keep forgetting to send the follow-up email.

A focused system fixes this in one place. It replaces Bonsai or FreshBooks, and it saves 2–3 hours a week.

(If you're curious, you can see the exact system I use here: jsonexlab.com.)

The Tech Stack Behind the Site (Build in Public)

Since this is Dev.to, I want to share how I actually shipped this. I didn't use Next.js or React. I wanted raw speed.

Hosting: Cloudflare Pages (free tier).
Generation: The entire site (500+ pages across 28 languages) is generated using PowerShell scripts. Yes, raw HTML/CSS generation.
Localization: Automated hreflang injection and content translation using dictionary maps in scripts.
Payments: Currently using Suby (crypto). Working on getting fiat approval.
Automation: Webhooks -> Make.com -> Brevo for email delivery.

It's a monolith of static HTML files, and it loads in milliseconds. No build step, no hydration errors, just raw HTML. It's ugly and beautiful at the same time.

The Bottom Line

If you're a developer, stop trying to build a "second brain" with 47 databases. Build a few simple walls to keep yourself focused. Your future self will thank you.

Have you ever abandoned a complex Notion setup? What was the breaking point?

The ADHD-Friendly Notion Setup That Actually Works

Oleksandr — Mon, 26 Oct 2026 17:30:26 +0000

Let me guess what happened with your last Notion setup.

You watched a YouTube video about "the ultimate second brain." You downloaded a template with 47 databases, 12 relations, and a dashboard that looked like a NASA control panel. You were excited for two days. By day four, you had 300 unread items, you were anxious every time you opened it, and you quietly archived the whole thing.

If you have ADHD, this story is not an exception. It's the rule. And the problem is not you. The problem is the template.

Why most Notion templates fail ADHD brains

Notion is a blank canvas. ADHD brains hate a blank canvas. They need walls — clear boundaries, clear next steps, clear "you're done."

Most templates give you more: more databases, more views, more customization. More is the opposite of what an ADHD brain needs. What it needs is less, but clearer.

The 3-task rule

Every morning, you open Notion and you see exactly 3 tasks. Not 10. Not "all tasks due today." Three.

Why three?

It's achievable. You can finish 3 tasks in a day, even on a bad day. That means you win the day. Winning compounds.

It kills decision paralysis. You don't have to choose what to do. The system chose for you last night.

It creates a clean "done" moment. When the 3 are checked, you're done. Not "done for now." Done. That's a rare thing for ADHD brains.

How to set it up (10 minutes, not 10 hours)

Step 1 — One database, three fields. Create a Notion database called "Daily." Fields: Task, Date, Done. That's it. No tags, no priority, no "energy level." Every extra field is a decision you'll be forced to make 20 times a day.

Step 2 — One view, filtered to today. Filter: Date is Today AND Done is unchecked. This is the view you open every morning.

Step 3 — The night-before ritual. Before you close your laptop, add three tasks for tomorrow. Then close it. Don't add tasks during the day. If something urgent comes up, put it in a separate "Later" page.

What about the 100 other things you're tracking?

You don't track them. You park them. Have a "Later" page (one page, not a database). Whenever a thought pops up, write one line and move on. Once a week, scan and promote or delete.

The shutdown ritual

At end of each day: check off completed tasks, move incomplete ones to tomorrow, close the laptop. This is not productivity theater. This is the difference between a brain that stays "on" all night and a brain that can rest.

The one thing that kills these systems

It's not forgetting. It's rebuilding. At some point you'll think "I should add a project tracker." That's the moment it dies. If you need to track a project, use a separate page. Don't add it to the daily view.

If you're a Notion power user, this feels wrong. If you have ADHD, it feels like relief. That's the point.

How Cloudflare D1's Daily Write Limit Almost Broke My Sanctions App (and How I Fixed It)

Oleksandr — Mon, 26 Oct 2026 12:48:32 +0000

I built a compliance engine that checks names against global sanctions lists (OFAC, UK, EU, UN). It runs entirely on Cloudflare Workers and D1. It’s fast, cheap, and mostly runs itself.

Until I woke up to a completely dead ingestion pipeline.

Here is the exact error that greeted me in my GitHub Actions logs:

{
"success": false,
"errors": [{
"code": 7500,
"message": "Your account has exceeded D1's free tier daily row write limit. Upgrade to a paid plan or wait until tomorrow (midnight UTC) to continue."
}]
}
My first thought was a bug in my code. But the truth is simpler: D1's free tier allows 100,000 row writes per day, and my ingestion scripts ate through them before lunch.

Here is what happened, why it’s a common trap, and the architecture changes I made to fix it.

The Trap of "Just Upsert Everything"
My initial ingestion logic was naive. I used a standard INSERT ... ON CONFLICT DO UPDATE (upsert) to sync records from the UN, OFAC, and GLEIF lists into my D1 database.

I thought: "If the record hasn't changed, it won't cost me anything."

That's true for standard Postgres, but D1 charges you for the INSERT attempt, even if the ON CONFLICT clause ends up doing nothing.

When I pulled the UN consolidated list (about 2,000 records) and the GLEIF database (tens of thousands of entities), my script tried to upsert everything at once.

33,000+ sanctions records

Plus daily cron jobs for OFAC, PEP, and UK lists

Plus API search logs

Very quickly, I hit the 100,000 writes/day ceiling. D1 locked my database in read-only mode.

How to Fix It (The 3-Layer Approach)
To survive on the free tier, you have to treat D1 writes like gold. Here is how I refactored my ingestion pipeline.

The WHERE Clause is Your Best Friend
If you are doing an upsert, you should only actually write to the row if the data has changed. You can add a WHERE clause to your DO UPDATE statement.
INSERT INTO sanctions (
list_code, entity_id, name, name_normalized, programs
) VALUES (?, ?, ?, ?, ?)
ON CONFLICT(list_code, entity_id) DO UPDATE SET
name = excluded.name,
programs = excluded.programs
WHERE
sanctions.name != excluded.name OR
IFNULL(sanctions.programs, '') != IFNULL(excluded.programs, '');
By adding this WHERE clause, D1 skips the write if the row is identical. This alone saved me thousands of writes on daily runs where only 1% of the data actually changed.
Chunking and MAX_PAGES_PER_RUN
My second mistake was trying to ingest the whole world in one run. GitHub Actions have a 6-hour limit, but your D1 quota doesn't care about your workflow time; it cares about rows.

If you have a massive dataset (like GLEIF), you need an incremental cap. I added an environment variable to my workflow:
env:
MAX_PAGES_PER_RUN: '20' # Never ingest more than 20 pages in a single run
Then, in the script, I break the loop once the limit is reached, saving the offset for the next run. It’s slower to backfill, but it guarantees your database won't go offline.

Separate the "Read" and "Write" Phases Originally, I fetched data from the API and wrote it to D1 in the same loop. If the API rate-limited me halfway through, I’d have a half-written database.

Now, I use a two-step pipeline:

Fetch Phase: Download the raw XML/CSV to Cloudflare R2 (Object Storage). R2 has a very generous free tier (10GB/month).

Parse & Ingest Phase: Read the file from R2, parse it, and batch-write to D1.

This decoupling means if D1 hits a quota limit, the fetch phase still succeeds. Tomorrow, I can just run the parse phase against the data sitting in R2 without re-downloading it.

What If You Hit the Limit Today?
If you are already locked out, there is no magic bypass. You have to wait until 00:00 UTC.

But you can prepare. Here is the exact check I run in my terminal before triggering a heavy job:
npx wrangler d1 execute compliance-db --remote --command="SELECT COUNT(*) FROM sanctions"
If it's read-only, the command will fail with code 7500 or code 7403. Don't panic—it's just Cloudflare telling you to take a break.

Final Thoughts
Cloudflare D1 is incredible for read-heavy edge applications. It’s practically free and sits right next to your Workers. But it’s not a Postgres replacement for heavy ingestion pipelines.

If you are building a scraper or an ETL pipeline on D1, idempotent upserts and strict batch sizes are not optional. They are the difference between a running app and a dead one.

(If you're building compliance or data tools on Cloudflare and want to compare notes on D1 limits, feel free to drop a comment or reach out.)

10-MCP-Server Ecosystem in 3 Weeks

Oleksandr — Mon, 26 Oct 2026 09:27:20 +0000

AI agents are the new frontier, and the Model Context Protocol (MCP) is quickly becoming the standard for how they interact with the real world.

Over the last three weeks, I’ve been building JSONexLab — a suite of API tools and MCP servers for developers and AI agents. The idea was simple: build highly specific, fast, and reliable data pipelines (like HS codes classification, document parsing, and sanctions screening) and sell them via a pay-per-call model using x402 (USDC).

I’m writing this as a "build in public" post because I see a lot of tutorials on how to build an MCP server, but almost nothing on what happens when you try to take it to production.

Here are the real numbers, the architecture, and the things that broke.

The Stack

Hosting: Cloudflare Workers & Pages (for edge performance).
Database: Cloudflare D1 (SQLite at the edge).
Backend: Node.js (v22).
AI: GPT-4o-mini for classification and data extraction.
Payments: x402 (USDC on Base), Suby (crypto), and currently verifying with AgentaOS (fiat).

🏆 What Works (The Wins)

1,018 SEO Pages Generated: I built a custom static site generator that created 1,000+ landing pages (programmatic SEO) for specific HS codes and validators. It takes 12 minutes to build but generates massive organic surface area.
The MCP Servers: We have 10 active MCP servers (Document-to-JSON, HS Codes, Currency Exchange, etc.). They are lightweight, respond in milliseconds, and can be hooked directly into Claude Desktop or Cursor.
The Traffic: We are seeing ~300 MCP calls per day for the document-to-JSON server. Developers are actively using the free tier.
Dark Mode: I finally moved away from the standard "white SaaS" look. A dark, high-contrast UI (like Supabase or Vercel) instantly made the product look 10x more premium.

💥 What Broke (The Ugly Truth)

1. The Cloudflare D1 Daily Row Write Limit

Cloudflare D1 has a free tier limit of 100,000 row writes per day. In my naivety, I set up a GitHub Action to ingest the UN Sanctions list (956 records) and the GLEIF entity database (20,000+ records).
Within hours, the database completely locked up. The API was returning D1 API error 400: code 7500: Your account has exceeded D1's free tier daily row write limit.

The fix: I had to write a custom script to batch the writes, limit the GLEIF sync to just 20 pages (4,000 records) per run, and gracefully handle the quota exhaustion so the script doesn't crash.

2. The PowerShell UTF-8 Encoding Nightmare

When building a static site on a Windows machine, PowerShell is your worst enemy. Every time I injected a Python or JS script containing emojis (⚡, 🌍, 💳), PowerShell (or Notepad) saved the file in Windows-1251 (ANSI) encoding. The browser would read the UTF-8 file and display these horrid characters: ВљЎ, рџЊЌ.
The fix: I had to write a Node.js script using raw Unicode escape sequences (like \u26A1) to forcefully overwrite the file in UTF-8 without BOM (Byte Order Mark).

3. The "CNAME Cross-User Banned" DNS Error

When pointing my custom domain to Cloudflare Pages, I hit Error 1014. It turned out that a stale CNAME record was pointing to a different Cloudflare account, and the zone was locked. After hours of deleting and recreating DNS records, I had to flush the local Windows DNS cache (ipconfig /flushdns run as Administrator) just to see the changes.

4. Payment Gateways for a Ukrainian Founder

This is the biggest bottleneck. I wanted to monetize using Gumroad, but they do not support payouts to Ukraine. Polar also blocked Ukrainian accounts. I had to pivot to AgentaOS (which specializes in Ukrainian payouts) and Paddle (which is notoriously strict with merchant verification).

Note: If you are selling a service that even remotely touches compliance, you have to strip the word "License verification" from your pricing page, or Paddle will put your account on hold until you prove you are a licensed broker.

The Reality Check: $0 Revenue

Despite ~300 daily API calls and a fully functional site, I have made $0 in revenue. Why?
Because developers use the free tier (50 calls per day), and setting up crypto payments (USDC on Base) is still a massive friction point for mainstream users. The fiat gateway (credit cards) is currently blocked by merchant verification.

What's Next?

Waiting for AgentaOS/Paddle to approve the fiat payment gateway.
Expanding the x402 native payments (so AI agents can literally pay for their own API calls).
Continuing to build new MCP servers.

Building an AI-native API business is a marathon, not a sprint. If you are building in the MCP space right now, my advice is: don't underestimate the infrastructure quotas, and figure out your payment rails before you launch.

If you want to check out the tools or test the MCP servers, you can find them at jsonexlab.com. I'd love to hear your feedback on the architecture!

Debt Snowball vs Avalanche: Which Method is Actually Faster?

Oleksandr — Sun, 25 Oct 2026 10:21:27 +0000

If you're trying to get out of debt, you've probably heard of two main strategies: the Debt Snowball and the Debt Avalanche. Both work, but they use completely different psychology and math.

Here is a quick breakdown of how they work.

1. The Debt Snowball Method

With the Snowball method, you list your debts from smallest balance to largest. You pay the minimum on everything, and throw all your extra money at the smallest debt.

Pros: Quick psychological wins. You see accounts close fast, which keeps you motivated.
Cons: You might pay more in interest if your smallest debt has a high interest rate.

2. The Debt Avalanche Method

With the Avalanche method, you list your debts from highest interest rate to lowest. You pay the minimum on everything, and throw all your extra money at the highest-interest debt.

Pros: Mathematically, this saves you the most money on interest. You pay less overall.
Cons: It can take longer to close your first account, which can be demotivating.

Which one should you choose?

If you have a lot of small debts and need motivation, go with the Snowball.

If your highest-interest debt is massive (like a credit card at 25%), and you want to save money, go with the Avalanche.

Calculate your exact Debt-Free Date

Want to see exactly when you'll be debt-free? I built a free, interactive calculator. No signup, no email required.

👉 Try the Free Debt Payoff Calculator

(Or, if you want the full system to track every payment in Notion, check out the Debt-Free Date Simulator for $24.)

The "works on my machine" problem is now "works in my context window"

Oleksandr — Thu, 22 Oct 2026 14:29:03 +0000

I've been building AI agents for a while, and I keep hitting the same wall.

It's not the model hallucinating. It's not the API being slow. It's that the agent works perfectly in my test environment, with my 20-message context, and then fails in production with a 200-message context, a different tool chain, and a user who asks something I didn't anticipate.

The failure modes are different from traditional software:

The agent doesn't crash. It just makes a slightly worse decision.
The tests pass. The context window just got too big.
The demo works. The real user asks a question that's 5% different, and the whole chain breaks.

I wrote about this before ("retry loops are expensive"), but I'm curious about the broader problem. How do you test an agent for the "messy context" it'll see in production, without shipping it to production first?

What does your test suite look like for agents? Do you have a "context window full of noise" test, or is it still mostly happy-path?

How to connect a Currency API to your AI Agent (using MCP)

Oleksandr — Thu, 22 Oct 2026 06:51:48 +0000

AI agents (like Claude and ChatGPT) are powerful, but they often lack access to real-time data. If you ask an AI "What's the USD to UAH rate?", it might hallucinate a number or give you outdated data.

In this quick tutorial, I'll show you how to connect a real-time Currency Exchange API to your AI agent using MCP (Model Context Protocol).

What is MCP?

MCP is a standard that lets AI agents call external tools. Instead of giving the AI a huge context window, you give it a "tool" it can use when needed.

The API

We'll use a free API I built: https://currency-exchange-api.boring-saas-infra.workers.dev/rate?from=USD&to=UAH

It returns JSON like this:


json
{"success":true,"from":"USD","to":"UAH","rate":45.09}

The MCP Server
I've published an MCP server for this API on Glama. You can find it here: Currency Exchange MCP.

How to use it (with Claude Desktop)
Open your Claude Desktop config file (claude_desktop_config.json).

Add this block:
{
  "mcpServers": {
    "currency-exchange": {
      "command": "npx",
      "args": ["-y", "currency-exchange-mcp"]
    }
  }
}

Restart Claude.

Ask Claude: "What is the exchange rate from USD to UAH?"

Claude will now call your MCP server, which calls the API, and returns the real rate.

Try it yourself
All the code is open-source on GitHub. If you build something cool with it, let me know!

How I Built 3 MCP Servers in a Weekend (and what I learned)

Oleksandr — Thu, 22 Oct 2026 04:29:17 +0000

I've been building B2B APIs for a while, but recently I got into MCP (Model Context Protocol). It's a game-changer for AI agents.

In this post, I'll share how I built 3 MCP servers in a weekend — and what I learned.

What is MCP?

MCP is a protocol that allows AI agents (like Claude, ChatGPT) to call external tools. Instead of giving an AI a huge prompt, you give it a tool it can call. It's faster, cheaper, and more reliable.

The 3 MCP Servers

1. Currency Exchange MCP

What it does: Gets real-time exchange rates for 160+ currencies.

Why I built it: Most AI agents don't have access to live currency data. This fixes that.

GitHub: currency-exchange-mcp

2. Sanctions MCP

What it does: Screens entities against global sanctions lists (OFAC, UK, EU, UN).

Why I built it: Compliance is a huge pain for fintech. This makes it easy for AI agents to do it.

GitHub: sanctions-mcp

3. HS Codes MCP

What it does: Classifies any product into a Harmonized System (HS) code.

Why I built it: Importers and exporters need this. Now AI agents can do it in seconds.

GitHub: hs-codes-mcp

What I Learned

MCP is simple. The SDK is well-designed. You can build a server in ~30 lines of code.
Glama.ai is the best directory. They accepted my servers in minutes.
AI agents are the future. More and more people will use MCP to connect tools.

Try Them Out

All 3 servers are open-source and available on Glama.ai.

You can also check out my other APIs at jsonexlab.com.

What are you building with MCP? Let me know in the comments!

How we built a PEP Screening API with 19,408 records and x402 payments

Oleksandr — Sun, 18 Oct 2026 09:37:32 +0000

We recently launched a free PEP (Politically Exposed Persons) screening API. Here's how it works and what we learned.

The problem: Compliance teams need to screen names against PEP lists, but existing solutions are expensive and require enterprise contracts. We wanted to build something simple: a single API call that returns matches.

The data: We ingested 19,408 unique PEP records from Wikidata and OpenSanctions. The data covers politicians, judges, military officers, and state-owned enterprise executives.

The API: It's a simple GET request:

text
GET https://compliance-engine.boring-saas-infra.workers.dev/check/pep?q=Rosneft
The payment: We use x402 (HTTP 402) for pay-per-call. It's a new protocol that lets AI agents pay for API calls with USDC on Base. No signup, no API keys. Just send a request and pay 0.01 USDC per call.

The MCP server: We also built an MCP server that exposes the PEP screening as a tool for Claude and Cursor. You can find it on GitHub.

What we learned:

x402 is a game-changer for AI agents. They can pay for tools without human intervention.

MCP is becoming the standard for AI tool integration.

19K records is enough to cover most compliance use cases.

If you're building compliance tools, feel free to test our API. It's free for 50 requests/day.