DEV Community: Bao Ngo

When the tool breaking is the only thing that makes you take a break

Bao Ngo — Tue, 14 Apr 2026 15:21:28 +0000

"Don't stop me now, I'm having such a good time, I'm having a ball"

11pm. Fourth worktree. Everything merging clean. Prompt, approve, ship, prompt, approve, ship. Freddie Mercury starts making sense. You're in the zone. You're a supersonic man. The PRs are green. You're floating around in ecstasy.

Then you realize — that song is about a guy who cannot stop. "Don't stop me, don't stop me, don't stop me." It's not a celebration. It's a confession. He's asking you not to interrupt because if he stops he'll have to feel something.

I barely write code anymore. The AI does 95% of it. I type a sentence, adjust a word, approve, ship. Next worktree. Merge. Next. And I'm more tired than when I did everything myself.

Make that make sense.

The dumbest contradiction

By every metric, my life got easier. The AI is genuinely good — I trust it, I built the systems around it, it ships real work. So why am I cooked by 3pm?

Because it's never one session. The AI is so fast that "done" and "what's next" are the same moment. No gap. No friction. You think "this will only take 5 minutes" — and that thought loops for 9 hours.

When I coded everything myself, debugging was secretly rest. Waiting for builds was meditation. The friction was load-bearing and I didn't know it.

Doomscrolling but productive

Each click is nothing. Each approval is nothing. You never hit the wall where your body says stop. AI-assisted shipping is the doomscrolling of engineering — except you actually ship stuff. Which makes it worse. Because at least with doomscrolling you feel guilty enough to stop.

Your GitHub graph is green. You're shipping. You haven't had an original thought in 3 days but hey — the PR got merged.

So what

Mrinank Sharma ran Anthropic's safeguards research. Last project was studying how AI makes us less human. Quit to write poetry. I'm not saying I get it. I'm saying after my 60th approve-merge-next loop, I don't not get it. (Weakkkkkkk)

We optimized away every reason to stop. Compile times, deploy queues, human bottlenecks — we called them inefficiencies. Turns out they were walls. And walls hold things up.

Credits just ran out. Going for a walk.

Best manager I ever had isn't a person. It's a rate limit.

AI gets you — it just can't remember your API field names

Bao Ngo — Sun, 12 Apr 2026 17:44:39 +0000

What can I do anyway...

AI is scary good, duh. Like, I describe a workflow in plain English — "check this spreadsheet, send a Slack if the number's off, log it to the database" — and it just... gets it? The intent, the order, the edge cases. That part still blows my mind every time. 🤯

But then. BUT THEN.

It writes channelId instead of channel_id. Or messages.write instead of chat:write. Or nests the JSON one level too deep. And your workflow 403s at 3am and you wake up to an angry Slack thread. Fun times. 😅

It's not like this happens everywhere. AI writes Python, SQL, whole apps — and it's terrifyingly accurate. But some things are just... arbitrary strings. An API field name isn't something you can reason about. It's channel_id because someone at Slack decided it's channel_id. No amount of intelligence helps you guess that.

When work depends on you, "close enough" isn't

And this is the key part — it's not about AI being bad. AI is incredible. But there's a difference between "AI helps me write code and I review it" versus "AI generates a plan that runs autonomously while I sleep."

One of those can be 95% right and you're fine. The other one... you need the API contract to be exactly right or nothing works.

Will future models fix this? Honestly, probably yeah. Claude 4.7, GPT-5.5, whatever's next — I wouldn't be surprised if they nail exact field names way more consistently. Maybe this post ages like someone complaining about dial-up. 🙈

But I'm shipping today. "Wait for the next model" isn't really a strategy when you have users.

So here's what I did

In CFFBRW, when you write a workflow and the AI compiles it — we don't ask it to get every parameter name perfect. That's asking it to be a database. Instead, we let it describe what it wants to do. Natural language. Its comfort zone.

Then we have this thing called the Resolver that maps that to reality.

AI says:       "Send a message to #alerts in Slack"
Resolver maps:  slack.send_message → { channel: "#alerts" }
                (exact slug, exact param keys, from a real catalog)

The AI describes intent. The Resolver enforces the contract. It matches against a catalog of real actions and real field names — handles typos, handles naming drift, produces exact output. No AI involved in this step. Just code doing what code is good at.

The full pipeline (quick version)

This Resolver is stage 4 of 5. Every workflow compilation goes through:

Enrich — load context and best practices into the AI prompt
Screen — AI sanity-checks the markdown before compiling
Compile — AI generates the execution plan (retries if validation catches stuff)
Resolve — deterministic mapping to real API catalogs ← this one
Validate — structural and semantic checks, contract enforcement and re-try, following Instructor.

AI handles 1-3. Stages 4-5 are pure logic. The plan that actually hits your APIs has been verified by code, not vibes.

And honestly — even when models get perfect at remembering field names, having a verification layer before you execute against real APIs with real credentials is just... good practice? Like, I don't think you ever want to skip that step. The Resolver isn't a hack for today's AI limitations. It's the design.

Anyway — if you want to see how this works end-to-end, the whole platform is exposed as an MCP server so any AI agent can compile and run workflows through this pipeline. The Resolver is invisible to the caller. It just works.

Building CFFBRW at cffbrw.com. Still learning as I go — would love feedback. ✌️

Every SaaS Is Already an MCP. Every Chrome Is an Agent.

Bao Ngo — Sat, 11 Apr 2026 16:42:18 +0000

Warning: Naive.
A couple weeks ago I AI-wrote to myself about the "SaaS is dead" panic — $285 billion wiped, everyone freaking out. The reality: SaaS isn't dead, but value is getting sucked upward into the agent layer and downward into the data layer. The thin UI middle is getting crushed.

Then MCP and WebMCP show up as the buoy. MCP standardizes how agents talk to servers. WebMCP lets websites publish "tool contracts" for agents. Together they tell SaaS vendors: "expose a structured interface and agents can still use you."

APIs, REST, GraphQL, webhooks — those aren't going anywhere. That's backend-to-frontend, system-to-system. No human needed. Fine.

But there's a layer above all of that. Where you're logged into 12 SaaS tabs copying data between them like an animal. That layer is about to get a new runtime.

Chrome as MCP

Here's the thought.

MCP lets agents talk to servers. WebMCP lets agents talk to websites. But what if Chrome itself becomes an MCP? Not one website. Not one server. The whole browser — every tab, every session, every logged-in SaaS tool — as one unified agent surface.

Today you tell an agent "send Q1 numbers to finance." It needs an MCP server/connection for your spreadsheet, another for email, OAuth for both, someone to wire it together. CFFBRW somehow support this.

Tomorrow: the spreadsheet is tab 3, Gmail is tab 7. You're already logged in. The agent reads the DOM, grabs the data, switches tabs, composes the email. Done. No API. No OAuth. No integration. Because the human already did all the integration work — by logging in.

This isn't Selenium with extra steps. Old automation works outside-in — an external program guessing at buttons. This works inside-out — the agent lives in the page, reads structured DOM text, inherits your session. And the LLM closes the gap — "click submit" works whether the button says "Submit", "Send", or "Confirm."

Is it as reliable as a typed API? No. But it covers a surface APIs never will — the millions of internal tools, admin panels, government portals that will never get an API.

SaaS Gets a New User

SaaS doesn't die. It just gets a non-human user.

The agent doesn't need the vendor's cooperation. It needs the UI to exist. If a human can do it in a browser, an agent can do it in a browser. Your SaaS stays in the loop — not as a tool the human clicks, but as a tool surface the agent operates.

Counterpoint to myself: this only works if the UI is agent-friendly. Poorly structured DOMs, no semantic HTML, aggressive bot detection — those break it. So there's a new competitive advantage: agent-friendliness. SaaS tools that make their UI easy for agents win. The rest get routed around. I even tried to build a skill called Retrofit SaaS for Agent; I make sure CFFBRW support BYOModel.

Where CFFBRW Fits

This is where I get hopeful. Because CFFBRW is built for exactly this future, or at least as I see it.

CFFBRW compiles markdown workflows into execution plans. Today those plans run steps against MCP servers (this is the hard part) and typed connectors — structured, reliable, deterministic. That handles the backend layer. APIs, data, system-to-system.

But the Chrome-as-agent layer? That's a new connector type waiting to happen. Imagine a CFFBRW workflow step that doesn't call an API — it instructs an agent in the user's browser. "Fill in the expense report." "Approve the PR." "Download the invoice from that vendor portal that hasn't had an API since 2019."

The workflow orchestrates. Chrome executes. The user's logged-in state is the auth layer.

Markdown workflow (CFFBRW)
  ↓ compiles to
Execution plan
  ↓ steps run against
┌─────────────────────────────────────┐
│ MCP servers     → structured APIs   │
│ Connectors      → typed integrations│
│ Chrome agent    → browser UI layer  │ ← new
└─────────────────────────────────────┘

Three tiers of reach. MCP for structured tools. Connectors for typed APIs. Chrome agent for everything else — the long tail nobody will ever build an integration for. CFFBRW becomes the orchestration layer that ties them all together.

That's the vision. Markdown in, results out, regardless of whether the step hits an API or clicks a button in tab 4.

Or maybe CFFBRW is worth no more than a AI-touch-grass.

What Happens Next

Chrome ships an agent API. Not "if" but "when." WebMCP is already in Chrome Canary. Someone will build a Chrome-native MCP that exposes all open tabs as tools.

SaaS vendors adapt or get routed around. Smart ones go agent-friendly. Stubborn ones add CAPTCHAs. Market decides.

Orchestration becomes the real product. Individual tools matter less. The thing that coordinates across all of them — across APIs AND browser UIs — that's where the value concentrates. That's CFFBRW's bet.

I could be wrong about the timeline. But MCP gave agents hands for servers. WebMCP gave agents hands for websites. Chrome-as-agent gives agents hands for everything.

SaaS was drowning. MCP threw it a buoy. Chrome-as-agent rebuilds the boat. And CFFBRW wants to be, just, a... I don't know yet.

Signal: PageAgent (github.com/alibaba/page-agent) — MIT, Alibaba

CFFBRW went from drag-and-drop to "hey AI, just deploy this for me"

Bao Ngo — Sat, 28 Mar 2026 17:52:27 +0000

Hey! So if you've been following CFFBRW since the Blockly days (DOUBT IT!), things have... changed a lot. Like, "I threw away the entire visual editor" level of change. 😅

Remember when I was all excited about snapping blocks together like LEGO? Turns out, when AI agents can write code better than I can drag blocks around, maybe the blocks aren't the product anymore.

What happened

So I've been reading a lot about the whole "SaaS is dead" thing (I wrote some research notes about it). The basic idea: value is moving UP to the agent layer and DOWN to the data layer. The middle — dashboards, drag-and-drop UIs, per-seat pricing — is getting crushed.

And I looked at CFFBRW and thought... wait. My visual builder IS the middle layer. 🙈

So I rebuilt the whole thing around one idea: what if you just write what you want in plain English, and AI compiles it into a workflow?

Before:  Drag blocks → Configure each one → Deploy
Now:     Write markdown → AI compiles → Deploy

The markdown is the source of truth. Not a config file, not YAML, not blocks.

The AI compiler runs once per workflow version, caches the result, and then execution is fully deterministic. No AI involved at runtime = fast and cheap.

The part I'm most excited about: BYOM MCP Server

BYOM = Bring Your Own Model. I exposed the entire platform as an MCP server at /mcp. Any AI — Claude, Gemini, whatever — can compile, validate, deploy, and run workflows. Not through the dashboard. Through MCP tools.

This is... kind of the whole point? If agents are the future users, the MCP server IS the product. The dashboard is just nice-to-have.

Here's what the MCP server gives you:

Resources (so the AI understands the system before acting):

cffbrw://schema/execution-plan — the JSON format it needs to generate
cffbrw://schema/step-types — all 9 step types (http_request, ai_call, transform, conditional, loop, etc.)
cffbrw://tools/available — what external MCP tools you've registered
cffbrw://examples/plans — examples from simple to complex

Tools (what the AI can actually do):

validate_plan — submit JSON, get errors or a validated plan
deploy_workflow / update_workflow — create or update workflows
run_workflow — execute, get back a run ID and WebSocket URL
get_run_status — poll until it's done
Plus get_workflow, list_runs, list_workflows

There's also a compile prompt that tells the AI "read the resources, take this markdown, give me valid JSON." But honestly the resources contain everything — the prompt is optional.

The auth model (learned this the hard way)

Remember the voucher race condition? Yeah, I've gotten more careful about security since then.

Two access levels:

wfk_ API keys — scoped to ONE specific workflow. Can read, update, and run it (only if published). Cannot see other workflows or create new ones. If this key leaks, damage is contained.
Clerk JWT — full workspace access. Everything works. For the dashboard and admin stuff.

So a CI/CD key can trigger your workflow but can't create arbitrary new ones. That felt important after the voucher incident taught me that "it'll probably be fine" is not a security strategy 😄

Expression eval: because `eval()` doesn't work on Cloudflare (not any more)

This was a fun rabbit hole. Workflows need to evaluate expressions — like referencing a previous step's output or doing a conditional check. But Cloudflare Workers blocks eval() and new Function(). Just... doesn't work. I learned this the hard way (as I learn most things).

So I built a three-tier system:

Tier A — Simple string templates like "Hello ${steps.step_0.name}". Parsed by an AST walker (jsep). Under 1ms. Handles most cases.
Tier B — More complex expressions. Tries the AST walker first, falls back to a Dynamic Worker sandbox if it's too gnarly. ~10-30ms for the fallback. And I cannot stress this enough Dynamic Worker is a game-changer. So try it.
Tier C — Full JavaScript code blocks in a Dynamic Worker. Network blocked by default. The escape hatch. And I cannot stress this enough Dynamic Worker is a game-changer. So try it.

The AI compiler is told to prefer Tier A/B. Only use complex JS when you actually need multi-statement logic. Because honestly, most workflow expressions are just "get this value from the previous step."

The stack (for the curious)

Everything runs on Cloudflare:

API: Hono
Validation: Zod everywhere — schemas are the single source of truth, TypeScript types derived from them.
AI: Claude (primary) + Gemini (fallback). Strategy pattern, so they're swappable.
Storage: D1 for workflows/runs, KV for compilation cache, R2 for artifacts
Real-time: Cloudflare Agents SDK — NotebookAgent for WebSocket streaming, WorkflowRunner for durable execution. They talk via RPC.
Dashboard: TanStack Start + React Flow for DAG visualization
Auth: Clerk with organizations for multi-tenant

The Agents SDK was... an experience. The TypeScript types are incomplete, routeAgentRequest() doesn't work with custom URL patterns, and you need a magic x-partykit-room header that isn't documented anywhere. I ended up reading node_modules/agents/dist/index.js more than the actual docs. Classic Cloudflare beta experience 😅

So where's the value now?

🤖 Agent Layer    → BYOM MCP server (any AI can use it)
🔌 Protocol Layer → 8 tools + 4 resources + compile prompt
🖥️ UI Layer       → Dashboard (nice but not the moat)
🗄️ Data Layer     → Run history, step logs, compilation cache (the actual moat)

The dashboard looks cool. But an AI agent talking to the MCP server can do literally everything the dashboard does. The data — workflow definitions, historical runs, step-level logs — is what compounds over time. That's what no agent can replicate from the outside.

Still building. Still learning. If you want to try the MCP server or have thoughts on how agent-native products should work, I'd love to hear it.

And I believe any builder should use Gstack from Garry Tan. Old news I know, but for people who live under a rock like I do.

So cheers! ☕

Just another simple file sharing

Bao Ngo — Thu, 17 Jul 2025 08:06:01 +0000

Sometimes, all I want when sharing files is "Just" sharing files. Don't ask me to sign-in or provide emails.

And sometimes your company policy just blocks file-sharing websites so...

Of course everyone needs to eat but... come on. Maybe this will help a few folks out there, at least until I either run out of money or figure out a sane way to sustain it reasonably.

Inspired by publicnote.com (check it out), I whipped up plcfile.com.

Here’s how it works:

You type in a folder title.
Upload your files.
The files are encrypted using the title and stored at a hashed version of it. The only thing you need to access your files later is that unique title. Don’t lose it — I can't even find it.

Please upvote if you can, it would help:
https://www.producthunt.com/products/public-file

On driving

Bao Ngo — Thu, 19 Jun 2025 16:25:17 +0000

If you come to Malaysa you know the speed limits are like for show right?
People drive how fast they think is still Okay.

And if it is any builder is doing right now. AI helps us to move fast but how fast you are willing to go.

MCP, A2A, PaaIP what any of those really mean?

I am looking for people to build CFFBRW with me, or someone to say that I am wrong and wasting my time.

What dev is it this post anyway?

TODAY I LEARNED: Race Conditions (Literally 💸)

Bao Ngo — Thu, 12 Jun 2025 17:28:17 +0000

Hey devs! Remember when I said I'd keep my project CFFBRW simple? Well, turns out distributed systems don't care about your feelings.

So I built this global variable feature - basically Redis but worse (I'm kidding... mostly). Users wanted to share state between API workflows, and I thought "how hard could it be?" Famous last words.

The Fun Before The WHAT-THE-HELL

So a friend wanted a gamification banner - "Wheel of fortune, only 10 '20% off' vouchers available daily!" Simple enough. I whipped up an API workflow in 15 minutes:

Check inventory
If voucher stock is available, return wheel config
Deploy for ⚡ SPEED ⚡

It was beautiful. It was fast. It was also giving vouchers to 47 users because race conditions don't care about your business logic.

How I Burned Through Vouchers Faster Than My Free-Tier Credits

Picture this:

10:00:01 - User 1st: "Vouchers available: 10?" Yes! (Chance to win = 50%)
10:01:15 - User 10th: "Vouchers available: 7?" Yes! (Chance to win = 50%)
10:02:38 - User 20th: "Vouchers available: 5?" Yes! (Chance to win = 50%)
... 
10:05:0... - User 47th: "I deserve a voucher! Because I won."

And then the banner was paused.

By the time the writes reconciled, we'd given away 37 extra vouchers. My friend was... not thrilled. 😅

So demo failed. Too early, yes, but he is my friend, so... Teehee!

I know that there are technologies/products to address this. But I hold back myself from adding things so that CFFBRW can be as cheap and light and fast to run as possible.

And when you limit your options, you rack your brains. After some frantic Googling and some "vibe-asking", I discovered some reconciliation strategies for the component.

The 4 Reconciliation Strategies That Could've Saved My Sanity

1. `last-write-wins` (The YOLO Strategy)

The default. Whatever wrote last is the truth. Great for settings, but BEWARE: Not for anything critical.

Use case: User preferences, feature flags

2. `sum-increments` (The "Actually Count Everything" Strategy)

Instead of setting values, you track increments. All increments get summed during reconciliation.

Use case: Page views, API calls, VOUCHER COUNTERS (😭)
My case: Would've correctly counted all 47 winners. Demo saved.

3. `merge-objects` (The "Keep Everything" Strategy)

For JSON objects, merge all updates together. Conflicts on same field? Usually last-write-wins per field.

Use case: User profiles, shopping carts, collaborative data
My case: Not applicable, but imagine if there were multiple vouchers with different winning chances...

4. `max-value` (The "Only Up" Strategy)

Always keep the highest value seen. Like a high score that never goes down.

Use case: Versioning, sequence numbers, "highest bid" scenarios
My case: Would've jumped straight to 47, at least I'd know the damage immediately

What I Actually Actually Learned

Default settings are defaults, not solutions - Last-write-wins is fine until it's not. And a big Beware/Caution is needed.
Test with concurrency - My demo with one request at a time? Adorable. Be more test-driven, especially with vibe.
Math > Vibes - "It'll probably be fine" is not a reconciliation strategy. As anyone knows, I've been learning to code for the last two years in my free time. And more than ever, you need to spend time to actually learn.
Edge computing is fast - Fast enough to create race conditions you didn't know existed, and cheap enough to get you hooked and locked in.

The fix was simple - switched to sum-increments for anything involving counting. But I don't think it actually addresses all the issues. It only gives me a good enough solution.

Current Status

Still shipping, still learning. The gamification banner now works perfectly.

Building in public means learning in public, admitting your limitations in public, regretting a bit in private, and learning more.

P.S. - If you're like me and don't know these things, I hope we can learn something new. Set up your reconciliation strategy BEFORE deploying to production. Your wallet will thank you. And if you already know this, guide me some.

P.P.S. - Now my motto is "Move fast but scale correctly."

Now you can build API like LEGO

Bao Ngo — Sat, 31 May 2025 17:52:14 +0000

Hey again devs! Quick update on CFFBRW (my visual API builder I posted about earlier).

So I got some feedback that the workflow builder felt... well, kinda basic while being overwhelming (I am confused!). One dev literally said "this looks like my nephew's Scratch project" 😅 Fair point. The drag-and-drop Sortable was functional but not exactly inspiring confidence for production use.

Two big updates that I have implemented over the week:
1. Rebuilt the whole visual editor with Google Blockly
I know, I know - Blockly is what they use to teach kids programming. But hear me out. After wrestling with custom drag-and-drop for weeks, I realized Blockly is actually perfect for this use case. It handles all the connection logic, validation, and visual feedback I was struggling to build, by actually making it look more like a Scratch project 🤣

Now workflows snap together like LEGO blocks. You can see the data flow, nest components properly, and it actually feels solid. Plus, Blockly is battle-tested by millions of students worldwide - if it can survive middle schoolers, it can handle my API workflows.

2. Added a Python runtime component (!)
This was the #1 request - "can I just write some Python for complex logic?"
So I spun up a shared Python runtime (sandboxed, don't worry) that you can drop into any workflow. It's literally a component called "Code" where you write Python, and it executes inline with your other components.
Example - I needed to calculate some custom metrics from API data:

import pandas as pd
import numpy as np

df = pd.DataFrame(responsedData)

df['Price'] = pd.to_numeric(df['Price'], errors='coerce')

if df['Price'].isna().any():
    print(f"Warning: {df['Price'].isna().sum()} price values could not be converted")
    df = df.dropna(subset=['Price'])  # Remove rows with invalid prices

summary_stats = {
    'total_records': len(df),
    'average_price': round(df['Price'].mean(), 2),
    'price_range': {
        'min': float(df['Price'].min()),
        'max': float(df['Price'].max())
    }
}

output_data = {
    'transformed_data': df.to_dict('records'),
    'summary': summary_stats,
    'columns': list(df.columns),
    'data_types': df.dtypes.astype(str).to_dict(),
}

Just dropped this between my Fetch and Response components. No server setup, no Docker, no Lambda configs. Just... Python that runs.

Currently it's a shared instance (so be nice, don't mine Bitcoin 😄), but working on multiple runtimes. The tricky part is keeping it fast - nobody wants to wait 5 seconds for a cold start on their API.
Real use case from this week:
Client needed an API that:

Fetches data from their Shopify store
Runs some pandas transformations (inventory calculations)
Formats it for their warehouse system
Forward it to one or fan-out to multiple API endpoints

Instead of my usual "let me set up a FastAPI server" dance, I just:

Drag Request block → Code block (30 lines of Python) → Transform block
Deploy It was done in 15 minutes. I am not saying building your own API is a waste of time, but you need to do something more important for now.

The Python code handles all the weird business logic that would be painful to express in visual components. Best of both worlds - visual for the flow, code for the complexity.

What's next:

New Python environments (soon™)
Packages support (so you're not limited to standard library)
Better error handling (currently it just... fails silently 🙈)
Shareable workflow templates

Still learning as I go. The Blockly integration was humbling - spent days building a custom solution when a "kids' tool" was perfect all along. And the Python runtime? Total hack job with exec() and prayer, but it works!

And if anyone has experience with sandboxing Python execution at scale, please share your wisdom. I am sure someone will find a way to break out (and break my bank)
Keep shipping! 🚀

P.S. - I do need to do something more important now.

Built my own visual API builder because I needed more than mock endpoints

Bao Ngo — Mon, 26 May 2025 16:39:45 +0000

Hey devs,
So I've been building side projects for a while, and I kept hitting this annoying pattern. I'd need a quick backend API - nothing fancy, just something to transform data, chain a few API calls, maybe query a data table.

But every time, I'd end up writing the same boilerplate: set up Express, add auth, handle errors, deploy somewhere, configure rate limiting... you know the drill.

I was using Beeceptor for mocking APIs during development (great tool btw), but I kept thinking "what if this could actually run real logic?" Like, what if I could just drag some components together and have a production API ready in minutes?

I am a novice builder, so my code is basically a combination of a few reusable code blocks I copy-paste from one file to another.

That's how I ended up building CFFBRW (www.cffbrw.com). Started as a weekend project to scratch my own itch.

Here's what it does - you drag components (Fetch, Filter, Loop, Aggregate, etc.) into a workflow, configure them, and boom - you get a real API endpoint. No servers to manage, auth, and rate limiting (😉 cannot get Cloudflare Ratelimit to work) built in.

Example: I needed an API that fetches crypto prices and calculates average changes. Instead of spinning up a Node server, I just:

Dragged a Fetch component, pointed it to CoinGecko API
Added an Aggregate component to calculate averages
Hit deploy

And got this endpoint in ~2 minutes:
curl -X POST 'https://api.cffbrw.com/v1/trigger/opensocialforall591b/averagePriceAndMarketcapChangePercentage24hTop5Cryptos'

Another one I use daily - filtering product catalogs from CSV:
curl -X POST "https://api.cffbrw.com/v1/trigger/opensocialforall591b/filterCatalogByCategory?category={{category}}"

The workflow is just: CSV component → Filter component. That's it. I also add JSONata to make it more flexible.

I've been using it for all sorts of random stuff:

Quick data transformations for client projects
Webhook receivers that actually process data
API aggregators (hitting multiple endpoints and combining results)
CSV to JSON APIs for static data query for my minisite.

Is it perfect? Nah. Still working on error handling, better debugging, and few more components. But it's been super useful for getting MVPs out fast. No more "let me just set up a quick Express server" that takes 2 hours.

If you're tired of writing boilerplate for simple APIs, give it a try. Would love feedback from other devs - what components would you want? What workflows would you build?

Currently free while I figure things out. Just trying to make something useful for developers like me who want to ship fast without the DevOps overhead.
Cheers!
P/S: oh maybe join me! I am nothing but a "vibe" (oh I hate this word) learner.