DEV Community: Eugeniya Ivanova

My plugin passed every check. It still didn't work.

Eugeniya Ivanova — Tue, 13 Oct 2026 08:49:13 +0000

We built a WordPress plugin. The idea was simple: you publish a post on your blog, and a couple of minutes later an announcement goes out to your social networks automatically. Headline, image, link. About two thousand lines of code. A small project, I thought.

I should probably mention that I don't write the code myself. Claude does. My contribution is asking questions, testing things and occasionally refusing to accept an answer because something about it bothers me. This turned out to be one of those occasions.

Before submitting, we went through all the checks. phpcs against the WordPress coding standards: zero errors, zero warnings. The official Plugin Check: clean. WordPress directory review: approved. The plugin was published, and I was quite pleased with us.

Then I installed it on an actual WordPress site. It didn't work.

The green checkmarks were checking the wrong thing

Here's the embarrassing part: before submitting, we'd never actually run the plugin in WordPress. We'd tried, but our local environment wouldn't start. WP-CLI kept crashing with the latest PHP version, and instead of sorting that out, we carried on with static checks.

The WordPress directory review checks whether a plugin follows the rules and meets security requirements. It doesn't mean somebody has tested whether your particular publishing workflow works. I understood this perfectly well in theory. In practice, I saw all those green checkmarks and decided we were finished.

Eventually, we got the plugin running in WordPress Playground, which runs WordPress through WebAssembly without needing a traditional local server. It took one command to start. On the first proper test, we found two bugs.

Bug one: the Connect button led nowhere

You click Connect, expecting to reach the Publora sign-in page, and WordPress sends you straight back to the admin dashboard. No error, no warning. You're just back where you started.

The problem was wp_safe_redirect(). We'd used it because, well, it has safe in the name. Unfortunately, it also restricts redirects to approved hosts. Our sign-in page lives on another domain, so WordPress replaced the destination with the admin URL.

The function was doing exactly what it was supposed to do. We were the ones asking it to do the wrong thing.

The fix was to allow the Publora authentication host for that particular redirect:

add_filter('allowed_redirect_hosts', [$this, 'allow_auth_host']);
wp_safe_redirect($url, 302, 'Publora');

Nothing here looked suspicious to the static analyzer. The code was valid, the redirect was safe, and the Connect button was completely useless.

Bug two: the editor kept losing the image

The second problem was harder to spot. When publishing from Gutenberg, the social announcement sometimes went out without the featured image. It also ignored the post settings: whether to share the post at all, which networks to use, and so on.

We'd attached publishing to the transition_post_status hook. When a post changes to publish, send the announcement. That seemed reasonable.

Except Gutenberg doesn't necessarily save everything in one request. The post status can change before the featured image and some settings have finished saving. The old metabox can send its data separately too. Our hook fired, we read whatever was available at that moment, and sent it off to social. Which, often enough, was nothing.

The plugin wasn't losing the image. We were asking for it before it had arrived.

We moved the publishing logic to wp_after_insert_post, where we could work with the saved post data, and added a check to avoid sending an announcement when an already-published post was updated:

if ($post_before instanceof WP_Post && 'publish' === $post_before->post_status) return;

Neither bug had anything to do with syntax or coding standards. We needed to see how WordPress actually behaved: where it redirected users, when Gutenberg saved its data, and which hooks fired along the way.

And now, how we dug them up in the first place

This is probably my favourite part of the story, although I wasn't enjoying it quite so much at the time.

When we discovered the plugin wasn't working, Claude suggested contacting WordPress directory support. They know the platform, they could help us investigate, and we'd already passed review. A reasonable suggestion.

I didn't want to do that yet.

Partly because I hate waiting for support replies, and partly because we hadn't even managed to run the thing properly ourselves. It seemed a little early to ask somebody else why it was broken.

So I asked Claude to go back through the documentation and help me set up a working test environment. We opened Playground and started trying things. Publish with an image. Publish without one. Disable sharing. Select Mastodon only. Try the classic editor. Watch what happens, check the logs, change something and try again.

By the end of the evening, we'd found both bugs and fixed them. No support tickets, no waiting for somebody to investigate. Just us, WordPress and a rather overdue first proper test.

I still can't read PHP nearly as well as Claude. When it shows me a function, I often need an explanation of what I'm looking at. But I can tell when we're trying to get around a problem instead of understanding it. And sometimes I can be sufficiently stubborn about that to make us investigate.

This was one of those times. Claude did the technical work, and I contributed a firm refusal to send an email. An unexpectedly useful division of labour.

What I took from it

I knew static checks weren't the same as testing a working plugin. I really did. I just apparently needed to publish one before remembering.

The other thing that stayed with me was how close we came to asking support for help with two bugs we hadn't even tried to reproduce properly. There are plenty of problems where support is exactly what you need. This wasn't one of them.

And I'm glad I pushed back on Claude's suggestion. Not because Claude was wrong to offer it, but because I would have learned very little from sending that email and waiting for somebody else to find the problem.

If you're building a WordPress plugin, I'd recommend running it in Playground before submitting it. We spent longer getting our broken local environment to cooperate than it took to find both bugs once WordPress was actually running.

The plugin passed review. The Connect button still sent me back to the dashboard. I think I'll remember that particular combination for a while.

Anyone else had something pass every check and then fail the first time you actually used it?

A like is face-to-face. A follow is standing side by side. At least that's how it feels to me.

Eugeniya Ivanova — Wed, 07 Oct 2026 10:23:14 +0000

Fair warning: I'm not a physicist, sociologist or scientist of any kind. I found a couple of studies, they've been sitting in my head for a week, and apparently the only way to get them out is to write about them. So this is less "here's how it works" and more "look what I found."

It started with kids. Or, more precisely, with scientists putting radio tags on preschoolers.

Kids on a playground behave like a state of matter

A team at the University of Miami put high-precision radio tags on preschoolers and watched how they moved. Not where they ran or what they played, but how they arranged themselves relative to each other. This did not sound especially exciting to me at first.

Then I read what they found.

In the 2024 study, when the kids had plenty of room, they moved a bit like a gas: moving around, bumping into each other, separating again. Put them in a tighter space and they started forming small, more stable groups, closer to droplets of liquid. Some stayed together, others moved in and out. The researchers describe it as a phase transition. Except the particles are preschoolers and the container is a daycare room.

This isn't entirely new either. Physicists have been using similar models for crowds and pedestrians for decades. Back in 1992, pedestrian movement was already being described with a "gas-kinetic Boltzmann model." There is also a whole field called active matter, which studies things that use their own energy to move: bacteria, fish, birds and, depending on the paper you're reading, apparently us.

This was already enough to send me down a hole. Then I found the second paper.

Then they went and measured the distance

In a 2026 paper, the same team looked at orientation: not just where the children were, but which way they were facing.

At distances below roughly sixty-five centimeters, the children tended to stand side by side, facing in the same direction. Farther apart, they were more likely to face each other. The change was surprisingly sharp rather than gradual. The authors describe it as a phase transition, although the reviewers are a little more cautious about how much the data can support that language.

But the part that stayed with me was much simpler: someone had actually measured the distance.

There is a number, in centimeters, where the way these kids relate to each other changes. And I spend most of my day in a place where distance supposedly doesn't exist at all.

Except each of us has our own room

This is where the comparison starts becoming less convenient.

The kids have one physical room. Its walls are in the same place for everyone. A feed doesn't work like that. The algorithm builds a different version for each person. My Instagram and yours have the same logo at the top, but they're not really the same room.

We're all supposedly inside the same network while seeing different people, in a different order, at different frequencies. Even the size of the room changes depending on what the algorithm decides to put near you that day.

So the gas-in-a-flask comparison only gets me so far. The flask, at least, has the decency to stay put.

And with AI I've stopped understanding what I'm even made of

This is where I wandered quite a long way from the paper.

The physics works with a fairly useful assumption: one particle has one physical location. A molecule doesn't leave a second version of itself at the other end of the room while the original goes for lunch.

My online life has become less tidy.

A couple of years ago I didn't trust AI much at all. The mistakes were easy to see: six fingers, broken text, confidently ridiculous answers. In retrospect, there was something comfortable about that. Then it got better, I started using it for more things, and somewhere along the way it became my pocket techie. I write with it, build with it, research with it and publish through it.

So while reading about these children as particles, I started wondering what exactly counts as my particle now. Just me? Me plus an agent? It can publish something I prepared while I'm asleep. It can work across several services while I'm physically sitting in one chair doing something else. My body still has one location. My activity doesn't.

This is not, to be clear, my attempt to introduce a new state of matter. I have enough problems getting software through review without taking on physics.

But it did make something about feeds feel less mysterious to me. They can feel much more crowded without there necessarily being more people. One person can simply produce and appear in more places than they could before. Agents make that easier again.

So what distance is a follow, then?

Which brought me back to the sixty-five centimeters. If physical distance changes how the children orient toward each other, I started wondering what the equivalent distance might be online.

I have my own completely unmeasured version.

A like, a reaction or a quick comment feels face-to-face to me. I noticed you. For a moment my attention is pointed directly at you and whatever you just said.

A follow feels more like standing side by side. I'm not only looking at this one thing you did. I've decided I want to keep seeing what you're looking at next.

What amused me is that the order isn't completely unlike the playground observation. At a greater distance, the children are more often facing each other. Closer together, they're more often oriented in the same direction. My brain apparently decided that clicking Follow belongs somewhere in that second category.

There is absolutely no sixty-five-centimeter result for LinkedIn hiding in these papers. That's my part.

Although I could, of course, be making all of this up

And I probably am, at least partly. I haven't measured any of this. Maybe a like feels like standing beside someone to you: a small acknowledgment from somebody already on your side. Maybe following someone is more like sitting across from them because you want to watch what they do. The geometry could be completely different.

But now I really want somebody to measure it.

If children in a room have a distance where their orientation toward each other changes, I wonder whether online relationships have anything similar. Maybe it's a follow. Maybe the first DM. Maybe the first time you reply to somebody instead of just liking what they wrote.

I wrote this together with Claude: the philosophizing is mine, the structure and formatting are Claude's.

I don't know. But I'm curious how you'd arrange these if they were distances: a like, a comment, a repost, a follow, a DM. Which ones feel face-to-face to you, and which feel more like standing beside someone?

Notion's API almost never errors out. That's the hard part.

Eugeniya Ivanova — Tue, 06 Oct 2026 09:46:06 +0000

We were getting Publora into Notion: an integration that reads rows from your database and turns them into scheduled posts. Built it, tested it, submitted it. Somewhere along the way I noticed that most of my problems with the API didn't produce errors. The request would succeed, and then I'd discover that what happened wasn't quite what I thought I'd asked for.

Here are the ones that cost me time. If you're building on Notion, they might save you some.

Scopes that are easy to miss

On Notion's consent screen, you pick pages: share these, leave those alone. What isn't nearly as obvious is what the integration is actually allowed to do with them. Ours had extra permissions enabled by default: inserting content and reading users along with their emails.

I only noticed because I tried the things the integration wasn't supposed to be able to do with a live token:

GET /v1/users    → 200, users with emails
POST /v1/pages   → 200, page created

I trimmed the scopes down to Read + Update content and tried again:

GET /v1/users    → 403 restricted_resource
POST /v1/pages   → 403 restricted_resource

That's all we need. Publora has to read the row and write a status back to it; it doesn't need permission to create pages. The consent screen is much better at showing which pages you've shared than explaining exactly what the token can do with them, so I ended up checking the permissions with actual requests.

Related catch: changing the permissions doesn't change an existing token. I unticked the boxes in the dashboard, tested again and still had the old permissions. You need to disconnect completely and go through OAuth again.

Places where the API says "ok" and does nothing

It can't publish a page, and won't admit it. public_url is read-only. PATCH it and the request goes through without an error, but nothing changes. I spent twenty minutes changing the request body before discovering there was nothing wrong with my request. Share → Publish is a manual action; the API simply doesn't expose it.

It hands you icon: null, then refuses it back. Read a block and you can get icon: null. Send the same object back in a write and it fails. We ended up stripping empty fields before writes.

Views can't be created over the API. If you want a Calendar or Board view, you still have to switch the layout manually.

You can't move a block. There's no equivalent of "move this above that." You insert a copy with after: <block_id> and archive the old block. Not exactly moving, but the result looks moved, which apparently is enough.

The Skill flag can't be set over REST. The toggle exists in the UI. It exists in Notion's MCP tools. Plain REST doesn't have it.

The one everyone's tripping on right now

As of API version 2025-09-03, rows don't live directly under the database anymore. They belong to a data source. A database can now have several data sources, which means the old POST /v1/databases/{id}/query can fail with an error about multiple data sources not being supported.

The new path is: fetch the database, take data_sources[0].id, then call POST /v1/data_sources/{id}/query.

This one confused me because everything still looks like a database in Notion. From the API's point of view, though, there's now another thing in the middle.

A couple of process things

Access is granted page by page, and a token isn't enough. You have to connect each page through ••• → Connections. Otherwise /v1/search can quite correctly return zero results. I spent some time suspecting search before realizing we'd simply never given the integration the page.

Ten minutes for an OAuth round is too short. Our session key originally lived for 600 seconds. That's plenty if you know exactly which database you're looking for. It's less generous when you're scrolling through a long list trying to remember what you called it six months ago. We changed it to thirty minutes.

Bots get a captcha. I tried to take screenshots of our own public page automatically. Playwright got "Verify you are human" twice. I took the screenshots myself. Very advanced automation.

One nice surprise along the way: we map columns by synonyms. caption, text and message can all be the post text; platform and networks can identify the channels. While testing, I gave it a database with a typo in one of the column names. It matched anyway. So people don't have to rebuild their content calendar around our template, which was one thing I really didn't want to ask them to do.

What I'd take from it

After working with the Notion API for a while, I stopped treating a successful response as proof that I was finished. I check the actual result now: what permissions the token has, whether the write really changed the thing I meant to change, whether the integration can actually see the page.

This sounds obvious written down. It was apparently less obvious to me while I was spending twenty minutes trying to PATCH a field that couldn't be changed.

I wrote this with help from Claude.

Have you worked with an API where the request succeeds and you only find out later that it didn't quite do what you thought?

Figma let us in with one email. Canva took forty-seven days.

Eugeniya Ivanova — Wed, 30 Sep 2026 06:47:05 +0000

A couple of weeks ago I wrote about getting our plugin into Figma. They sent one email asking for a video, we sent it, and that was basically it. I remember being surprised by how calmly the whole thing went.

Canva was running in parallel. Canva was not calm.

Forty-seven days from submission to approval. Four rounds of review. Five versions of the app. This wasn't because we'd managed to do everything wrong. Canva has three review stages that happen in order, and design review alone can take up to two weeks and involve several people. One reviewer even warned me that most apps get notes and that getting them doesn't mean you're failing review. This was useful information somewhere around round two. By round four, less so.

A lot of what slowed us down wasn't code. It was figuring out what a review comment was actually asking us to fix. If you're submitting an app there, these are the things I wish I'd known before we started.

The requirement is called one thing, and the real issue is another

The title of a Canva review note isn't always a particularly good description of the problem. We learned to stop treating it as one.

The clearest example came in the third round. We got three different checklist items back. Under all three, the reviewer had attached essentially the same evidence: "even if you pick 'Add video,' the exported file is still a PNG." I saw three items and started looking for three problems. There was one.

The bug itself was in the format config, not Publora. I checked that first because blaming our own API is a habit I've developed. We had one format with a single slot for "image or video." Canva goes through the formats in order, that combined slot doesn't match a video page correctly, the fallback kicks in, and the video comes out as a freeze frame. We split it into two formats. To make sure we'd understood what was happening, we put video first and got the opposite bug: static pages started rendering as mp4. At least that was convincing.

Another review item was called "Buttons not full width." I went looking for buttons. In the attached screenshot, the problem was actually a narrow dropdown that said "In an hour." After that I started opening the screenshots before doing much with the title of the ticket. It saved time.

Then there was one where the documentation and the reviewer simply disagreed. The docs said the object panel on the featured image should be dark grey. The reviewer wanted it white. We made it white. At that point I was no longer interested in winning an argument with a PDF.

We did it not the way they asked, and it came out more honest

One request was harder because we couldn't implement it literally. Canva wanted an account block that was always visible, with the user's name and avatar.

Publora doesn't really have that concept in this part of the product. What matters is which social channels you're connected to and where the post is going. I still tried every endpoint name I could think of: me, user, account, profile. Four different ways to get a 404.

So we built the block from the information we actually have. We fetch the connected channels and show their names and platforms in the header. Instead of a generic user profile, you see the actual accounts you're about to publish to: this X account, this LinkedIn, this Instagram.

That ended up making more sense for Publora anyway. The reviewer wanted the user to have account context while publishing. We could provide that context; it just wasn't the name-and-avatar version described in the ticket.

A piece of technical luck I didn't earn

There was also one part I expected to be difficult that turned out not to be difficult at all.

We don't have to upload the media from Canva ourselves. Canva exports the design and gives us a link, then Publora downloads the file from that link. The separate upload flow I'd been expecting to build simply wasn't necessary.

Our OAuth was an even better surprise. At some point we discovered that we'd already rolled out what we needed and apparently forgotten about it. Our regular REST API accepted the token, so sign-in worked without any new code. I would like more integrations to be solved by discovering that we already did the work six months ago.

The Cloudflare shim ended up at about a hundred lines and stores nothing. It's there for CORS: our API only accepts browser requests from our own domains, while Canva naturally runs on Canva's.

A few things from off-screen, so you don't step on them

Design review is separate and, for us, was the longest stage. Our fourth round came back with six comments, all about the listing images. Nothing was wrong with the app itself. So if you're planning around the technical work only, leave some time for somebody to have opinions about screenshots.

You also can't keep changing things while the review is running. When they say, "Please hold off on making any changes while it's under review," they mean it. Fixes go into a new version, and not everything necessarily carries over, so we ended up checking each version again from the beginning.

A demo video is mandatory, although we didn't find it in the main checklist. The requirement appears next to the field itself: without a video link, you can't submit. We recorded three versions because the app changed after review rounds and the previous recording stopped matching it.

And then we nearly published TEST to a real LinkedIn account. During one recording, the post went quite happily into the real schedule for the next morning because the publishing control still said "Tomorrow, 9:00" instead of "Save as draft." Technically, everything worked. Unfortunately, that was the problem. We noticed it while checking the recording and deleted the post before morning. I've already written an entire article about checking publishing state, so naturally I had to demonstrate the problem again myself.

How it ended

On September 21, the status changed to Application Approved. After that, the listing text was translated into eighteen languages and we got an email saying the app was ready for release. I then waited for the release button to become active before realizing that nothing was going to happen until I actually pressed it myself. Forty-seven days had apparently trained me to wait for permission.

Publora is in Canva now. Publer, Metricool and a few other social tools have been there for a while. Our flow is a little different: instead of exporting the design to a media library and finishing the post in another dashboard, we use Canva's Content Publisher intent. You can take the design you're already working on and publish it to one of your connected networks without leaving the Canva editor.

Canva says more than 250 million people use the product each month. Some of them can now finish the job without downloading a picture, opening another tab and uploading the same picture again.

After five versions, I'll take that.

I wrote this one with Claude as well. I told it what happened over those forty-seven days, it drafted, and I cut anything that hadn't happened that way.

Have you ever spent a review round fixing the thing the ticket was named after, only to find the real problem was in the screenshot?

The portal said "Live." For a few hours the page kept saying the connector didn't exist.

Eugeniya Ivanova — Thu, 24 Sep 2026 07:49:57 +0000

I've submitted to just about every directory I could reach by now. Chrome, Firefox, Edge, Zapier, IFTTT, Figma, ChatGPT. Every time it's someone else's place: you show up, they check what you've brought, sometimes they send you back to fix it, sometimes they let you in. I've written enough about review rounds and strange submission rules by now.

And this week we submitted Publora to the official Claude connectors directory. For some reason I'd been preparing for this one longer than any of the others. Not technically. The work was done. Apparently I had some feelings left over.

Fifteen minutes I'd been walking toward the longest

The submission itself took about fifteen minutes. A form, a button, done. Submitted yesterday, in the directory today. Behind those fifteen minutes was a month and a half of work by the whole team: thirteen pages of Anthropic documentation, checking the server against fifteen requirements with live requests, and manually running all eighteen tools against production.

So why did the easiest submission bother me more than some of the genuinely horrible ones?

I think it's because all the previous directories felt like other people's territory. Claude doesn't. I'm not an engineer; my job is getting people to use our product, and almost everything I've built this year I've built with Claude somewhere next to me. It's my pocket techie: it writes the code, I lead, argue and make it redo things. Twenty articles, a dozen and a half integrations, all those submissions. And now Publora is sitting in Claude's own directory. That felt different.

That's enough sentiment. There were also several stupid things that cost us time, and those are probably more useful if you're submitting a connector yourself.

The portal says one thing, reality says another

The main thing I'd keep in mind: a green status in the portal doesn't necessarily mean the thing next to it is already working. We found that out in three different places.

"Live in the directory," and the page is empty. We hit publish and the portal immediately reported "live." The listing page, meanwhile, spent several hours returning "This connector doesn't exist." The View listing button went to the same page, and search found only our temporary connection. We'd already written a support email and, luckily, hadn't sent it yet. A few hours later the listing appeared on its own. If you see the same thing, give it some time before writing to support.

The portal decides the server is authless when it isn't. At the authorization step it checks tools/list. Ours returns the tool list without a token, so the portal announced: "Server requires no auth to list and call tools." The first half is true. The second isn't. You can see our tools without authorization, but you can't call any of them. We still had to select OAuth manually.

The docs disagreed with the live form in four places. The docs promised eleven steps; we got ten. The icon field was described as a file upload but turned out to want a URL. The best one was the listing address: the docs use claude.ai/directory/connectors/<slug>, while the actual listing is claude.ai/directory/<slug>. The old version even appeared in the approval email. We nearly copied it into our own documentation because apparently an email can still outrank the browser in my head.

The rake half the ecosystem steps on

One deserves its own section, because I went looking to see whether we'd done something stupid. This time, at least, we had company.

The portal flagged all eighteen of our tools as "missing a title." All eighteen had titles. The problem is that the MCP spec has two places for title: top-level Tool.title, added in summer 2025, and the older annotations.title. We used the newer field. The Claude directory was checking annotations.title.

This has caught other people too. A pull request to FastMCP describes the same problem: its titles were going only into the top-level field, so the Claude connectors directory saw the tools as nameless. If the portal says your tools are missing titles and you can clearly see the titles in the schema, check annotations.title before doing anything more dramatic. That string is also what users see in the confirmation dialog, so they get "Create post" instead of create_post.

A couple of smaller rakes, also worth taking with you

The form draft doesn't save. We went through all ten steps, clicked "Save and exit," and lost the lot. When we came back, the form was empty and the dashboard said we hadn't submitted any servers. "Draft saved in this tab" is apparently very literal. I'd do the form in one sitting.

The "Keep your personal account separate" checkbox when creating an organization. Without it, your personal subscription is cancelled and your chat history moves into the organization, with no way to move it back. It's an easy checkbox to skim past and not a particularly easy decision to undo.

About what I learned myself

Separately, because this part was my problem rather than Anthropic's. Along the way I put four things into our blockers: a network supposedly missing from the test account, a strange 403, dead tokens and a parameter I thought we had to change. None survived an actual live check. In several cases I'd looked at one field in the database, decided what it meant and promoted the guess to a problem.

There was a good example in the other direction too. At one point I entered the wrong plan, the one I thought was required for submission. Claude accepted that as a fact, built the rest of the reasoning around it and very confidently helped me proceed in the wrong direction. Which was fair enough. I had given it bad information and then asked it to reason from there.

I'm getting better at noticing this when we work together: when Claude has started building on an assumption, when it's doing something I didn't actually ask for, and when I need to stop and check the boring fact underneath all the reasoning. The same applies to me. My "I think there's a defect here" can become a blocker in a document surprisingly quickly. Claude's guess can do the same. Neither becomes more factual because it has been written down neatly.

What to do with this yourself

Publora is in the Claude directory now. You can connect it and create posts for ten social networks from the same chat where you're already working, instead of moving the text into another app afterward.

The part I'd still be careful with is delegation. I've written about this before, but it keeps coming up: vague instructions give Claude room to fill things in. If you want a post published, tell it what to publish, where and when. If you want a draft, say draft. I don't rely on Claude to guess which parts of a publishing decision I meant to leave unsaid.

Looking back at the things I've built this year, there's a slightly ridiculous amount of technical work for someone who still introduces herself by saying she's not an engineer. Claude has been involved in most of it. So seeing Publora in its directory was nice in a way I hadn't expected.

The actual submission took fifteen minutes. Getting to the point where those fifteen minutes were possible took considerably longer.

I wrote this one with Claude as well, which seemed only fair given where it ended up. I told it what happened, it drafted, and I cut whatever hadn't actually happened.

Have you ever spent months getting somewhere and then found the actual moment itself was almost suspiciously uneventful?

I was sure Figma would reject my cover art. The email asked about something else.

Eugeniya Ivanova — Mon, 21 Sep 2026 07:32:45 +0000

A few years ago, my Figma skills were roughly limited to whatever I could make from templates designer friends gave me. Sometimes I made silly pictures for colleagues. A normal user, basically: I can do a few things, and if I can't, I probably don't need to be there.

Then I changed jobs, and somehow this escalated. Sometimes I fix a layout myself, sometimes I make an agent do it because spending half an hour figuring out where Figma hid one particular effect is usually beyond both my time and my patience. And then I ended up in a fairly strange place: I wasn't just using other people's Figma plugins anymore. I'd made my own. It lets you send a design from Figma straight to your social accounts without exporting it and dragging it through three other apps first.

What a wonderful world. You never know where it'll take you.

Where I got stuck, and it wasn't where I expected

Writing the plugin wasn't the scary part. I got stuck on the pictures.

To publish a plugin, Figma asks for an icon, a cover and screenshots. The cover stopped me. Make it myself in Figma, where I am, let's put it gently, not very good? Give it to an agent? Do both and then spend ages choosing between things I'm not qualified to judge? I spent an embarrassing amount of time on this.

The problem was stupid, but real. I was about to submit a plugin to a platform full of designers. Actual designers. And here I come with my cover. People will look at it. People will know.

In the end, Claude made the cover. Simple, clean, no attempt on my part to demonstrate the designer apparently hiding somewhere inside me. I submitted the plugin and waited to be told what was wrong with the pictures.

The email came. About something else.

Figma's review was nothing like the others I'd been through. Chrome took two rounds. Adobe sent us back with changes too. Zapier had eight. By then I'd come to think of moderation as a kind of correspondence where somebody explains what you've done wrong and you write back when you've fixed it.

Figma said nothing. Then an email arrived: send us a video showing how the plugin works.

That was it.

Not "the cover is weak." Not "the icon needs work." Not even "who let you in here." They wanted to see that the plugin did what it was supposed to do.

We recorded the video and sent it. Silence again. Then the plugin appeared in the Community. It even has a couple of users already, which I particularly like because it means we're no longer the only people using the thing we made.

Only after that did I read Figma's review rules, which would obviously have been more useful before I started worrying. There's nothing in there about how the cover looks. They review whether the plugin is finished, whether it crashes, whether it does what the listing says, whether it's safe with someone's files. The only line that touches the pictures at all asks for an accurate description, screenshot, or previews, "so that the users will not be surprised by any hidden functionality." Not a good cover. An honest one.

So I'd spent several days worrying about a test nobody was planning to give me.

And this is where it gets a little strange

I didn't become a designer along the way. I didn't become an engineer either. But there's a plugin in the Figma Community now, and it has a perfectly decent cover.

A few years ago, "make a cover for a plugin" would have meant learning how to make covers first. Now I can explain what I need to an agent, get a few options, throw away the terrible ones and keep something decent. This does not make me a designer. It does, however, leave me with a cover.

I'm still not entirely sure what I think about that. Taste and a good eye obviously still matter: if you're given five bad options, somebody has to notice they're bad. But I also quite like living in a world where needing one particular effect doesn't automatically mean watching a forty-minute tutorial about it.

My actual job is getting people to use our product. I'm not a designer or an engineer. But somewhere in the Figma Community there's now our plugin, with a cover I couldn't have made myself.

Well. Apparently I can make Figma plugins now.

I wrote this one with Claude too, which feels about right for a post that's partly about not making things myself. I described what happened, it drafted, and I cut the parts that weren't true.

Has AI ever dropped you somewhere the old rules say you don't belong?

I didn't come to Claude through code. I came through a 10 a.m. routine.

Eugeniya Ivanova — Fri, 18 Sep 2026 07:28:48 +0000

Most people I know got to Claude through code, which is reasonable enough considering the name. I got there because at ten in the morning I wanted somebody else to check my numbers.

I'm not an engineer. My job is getting people to use our product, which means I spend a surprising amount of time looking at numbers, looking at people, and then looking at the numbers again because I no longer trust what I saw the first time. I started with Claude Desktop, then tried Cowork, and eventually found routines. I have three now. None is particularly impressive, which is probably why I actually use them.

The 10 a.m. check

The serious Publora analytics live in Claude Code in VSCode. That's where the keys are, the detailed data, revenue, and all the things capable of ruining an otherwise decent morning. I can go in there and dig properly, but the problem is that I can always dig properly. There is always another cohort to check, another strange number, another question that suddenly seems urgent because I've opened the file containing it. If I do that every morning, there goes the morning.

So at 10 a.m. Claude sends me a Publora brief: tasks, analytics, meetings, anything that looks unusual. I've normally been at my desk since eight, so by then I've had coffee, answered email and acquired enough emotional stability to look at analytics. If something moved, I open VSCode and investigate. If everything looks normal, I leave it alone. Before this routine, apparently I needed two hours of analysis every now and then to discover that everything was fine.

The file where future posts go to wait

The second routine runs Monday, Wednesday and Friday. It looks around my usual topics, finds two or three things worth writing about and puts them in content-backlog.md.

The file turned out to matter. At first I had Claude send me ideas, which produced a very nice list that I would read, approve of and never see again. Now the ideas accumulate in one place. By Friday there are several possible posts in there. Some are bad, some seemed good on Monday and make no sense by Friday, and usually a couple survive.

That's all I need from it. I don't want Claude writing my posts while I sleep. I want to sit down to write and not spend the first forty minutes discovering that apparently I have never had a thought in my life.

Hacker News without going to Hacker News

The third one is technically a scheduled task rather than a routine. It gives me a Hacker News digest twice a day. This exists because I know what happens when I tell myself I'll check the news when I have time: either I don't, or I open Hacker News to read one thing, then another, then somebody is wrong in the comments, and forty minutes later I'm extremely well informed about something I wasn't working on.

Now the digest arrives by itself. I skim it, open whatever actually looks useful and occasionally find something I want to comment on. I remain approximately aware of the world without having to visit quite so much of it.

My routines stop when I close the laptop

There is one limitation: these routines are local, so my computer has to be awake and online. Claude Code also has cloud Routines that can run while the laptop is closed, which means you can wake up and the work is already there. People quite reasonably describe this as an advantage.

I understand them intellectually. Personally, I'm an anxious person, and the idea that Claude has been awake since six doing things on my behalf while I was asleep does not relax me. I'd wake up wondering what it had done. Mine start working when I do. I'm at the desk, Claude is at the desk, and nobody has been getting creative overnight. This arrangement suits me.

What I actually gave it

None of these routines does anything spectacular. One checks whether something in the numbers needs my attention, one keeps a file of things I might write about, and one reads Hacker News so I don't accidentally spend forty minutes reading Hacker News myself.

I still make the decisions, which unfortunately seems to be most of my job. What disappeared was the need to remember to go and check all this stuff myself. And I set the whole thing up in plain English, without writing code, which is mildly funny considering how long the word "Code" made me assume this wasn't for me.

Now I'm much more interested in the boring things people put on routines than the impressive ones.

I wrote this one with Claude as well: I described what the three routines actually do, it drafted, and I cut the parts that weren't true. Which is more or less the arrangement everywhere else in this post.

What's the stupid recurring thing you got tired of doing yourself?

IFTTT accepted our service on the first try. The flow broke on the first redirect.

Eugeniya Ivanova — Wed, 16 Sep 2026 15:30:00 +0000

Last week I was bringing Publora onto IFTTT. Our server was already live, OAuth was working, and the API was there. I expected most of the work to be filling in their application and getting through review.

The application passed on the first try, in under a day instead of the estimated one to two weeks. The actual integration broke on the first authorization redirect.

Here's what I ran into.

The OAuth that didn't line up

The first problem showed up immediately.

IFTTT sends plain OAuth2: authorization code, no PKCE. Our authorization server requires PKCE. Their redirect arrives without a code_challenge, so our server rejects it.

I tried the request in exactly the format IFTTT sends:

GET https://mcp.publora.com/authorize
  ?client_id=...&response_type=code&scope=ifttt&state=...&redirect_uri=...

-> 302 ...?error=invalid_request
   "expected string, received undefined" on code_challenge

Add a code_challenge to the same request and it reaches the login screen normally. So there wasn't much mystery left: IFTTT doesn't send something our authorization server requires.

I could either make PKCE optional on our server for IFTTT or put something between the two. I went with the second option.

I added a small Cloudflare Worker between IFTTT and Publora. To IFTTT, it looks like the plain OAuth2 provider it expects: no PKCE and a non-expiring token. On the Publora side, the Worker runs the PKCE flow itself, generating the verifier and challenge before sending the request to our authorization server.

That also gave me somewhere to handle the rest of the differences between the two APIs. IFTTT expects endpoints and responses in its own format, while Publora already has its own API. The Worker translates between them.

Turning posts into an event feed

IFTTT treats a trigger as a feed rather than a current state: up to fifty recent events, newest first, each with its own meta.id and meta.timestamp in seconds.

For Publora that means one post group may need to become several events, one for each channel. Otherwise the meta.id isn't unique:

for (const post of posts) {
  for (const target of post.platforms ?? []) {
    items.push({
      content: post.content,
      account: label(connections, target.platformId),
      network: target.platform,
      occurred_at: at,
      meta: { id: `${post.postGroupId}:${target.platformId}`, timestamp: seconds(at) },
    });
  }
}

There's another requirement they test separately: every trigger needs to return at least three events during testing, so it behaves like a feed rather than a state sensor. An empty or short response doesn't pass.

I also replaced hourly polling with realtime notifications. A Publora webhook is created when the connection is set up, and when an event arrives the Worker calls IFTTT's Realtime API. It doesn't send the event data there; it just tells IFTTT there's something new, and IFTTT fetches the feed itself.

Five things I couldn't find in their docs

This is where I spent most of the time. If you're building an IFTTT service, these are worth knowing before you start running their tests.

The test/setup endpoint is required, but I couldn't find it in the docs. Their automated tests hit it second. There is a sample response in the dashboard under View scaffold JSON: it needs a queries section, and media_url can't be an empty string. The method isn't specified there, so ours accepts both GET and POST.

Ingredient slugs can double without showing it in the UI. The form generates a slug while you're typing the field name, and entering your own can leave you with things like contentcontent and occurred_atoccurred_at. The resulting slug isn't visible in the form. I only found it in the service export under Tools, Export. A good chunk of my failed tests came from this.

The UI didn't show me why tests were failing. I could expand the failed result row, but it was empty. The actual results were available through these endpoints:

POST /services/<slug>/publish/endpoint_session   -> session_id
GET  /services/<slug>/publish/endpoint_test_results?offset=N&session_id=...

The results come in chunks, with suite_end marking the end. That's where I eventually found the individual failed checks.

A request with no fields needs to return a proper 400. They test requests with triggerFields missing and with required keys missing inside it. The response needs an errors array. I initially supplied defaults in some of these cases, which made the tests fail.

The cursor is mandatory when results are limited. If you return only part of the feed because of a limit, the response also needs a cursor. Without it, the test fails.

Numbers

Their run has 535 checks. I eventually got it to zero failures, after spending considerably more time than I'd like to admit on doubled slugs and test results hidden behind an empty UI row.

There are also two launch requirements I hadn't found in the docs: twelve published applets and four service admins. You can submit the service without them, but you need them before launch.

I submitted on September 7 and the review passed on September 8, so under a day against the estimated one to two weeks.

The Worker ended up at about 700 lines of TypeScript and a 19.8 KB bundle.

What I'd check first next time

If you're doing an IFTTT integration, check the generated slugs in the service export rather than trusting the form. If an automated test fails without an explanation in the UI, look at endpoint_test_results. And before running the full suite, make sure you have test/setup, cursors on limited responses, and proper 400 responses for missing fields.

For OAuth, I was glad I didn't make PKCE optional in Publora just to accommodate this integration. The Worker was already needed to translate IFTTT's API format, so handling the OAuth difference there kept the change isolated too.

I built it with Claude: it wrote most of the TypeScript, while I tested the requests in IFTTT's format and worked out where the two sides disagreed. Most of the time went into finding those disagreements, especially the ones I couldn't see from the dashboard.

The listing is here: https://ifttt.com/publora

If you've integrated with IFTTT before and found another undocumented test, I'd like to know which one.

I gave an agent my posting history. It found a promise I never made.

Eugeniya Ivanova — Tue, 08 Sep 2026 07:10:41 +0000

Every social platform rewards the same thing, and it isn't a secret: showing up regularly. The hard part isn't writing. It's deciding what to say today, and on plenty of days there either isn't an answer or you don't feel like hunting for one.

Someone I was talking to on LinkedIn last week told me they stick with their scheduling tool mostly because of the post templates. When they run out of ideas, the templates give them somewhere to start. That surprised me. I would have guessed people got stuck on the writing, not on choosing the topic.

Asking an agent doesn't really fix that either, at least not in the usual setup. You say "write me a post," it gives you one draft based on its first guess, and if you're not convinced, there's often nothing specific to react to. You end up rewriting it yourself, which rather defeats the point.

So this week I built a small skill around one very narrow idea: don't give me a draft first. Give me three angles and let me pick. Three options I can answer with a number.

It works now. The first real run didn't. It failed three times before it gave me anything useful, and all three failures came from the same place: the agent was reading my own data and treating its interpretation as fact.

It read my test posts as things my audience saw

The skill starts by calling list_posts and reading the last twenty. It's looking for two things: topics I've already covered, so it doesn't suggest the same thing again, and threads I've left hanging. A launch with no follow-up. A question I asked and never came back to. Those are often more useful than inventing a new topic because the context already exists and I usually have the material.

It found one. Two posts on my LinkedIn from late July said Publora was coming to Zapier. Nothing after that. So it suggested: finish the thread, you promised this a month ago and never said how it turned out.

Except I hadn't promised anything.

Those posts were Zapier review artifacts. To submit an app there, you have to run every trigger and action inside a live Zap, switch it on, and leave a successful run in the history. That means my account contains posts with names like Zapier validation — update target. They look like normal posts in the same list, and the agent had no idea they weren't meant for an audience.

I added a filter: short posts, near-duplicates minutes apart, anything containing test or validation. But the more useful fix was a rule:

Never state an inference from history as a fact.

"You promised X and never followed up" sounds confident, but it's still an inference from a list that includes QA junk. The agent should say what it found and ask whether it understood it correctly. Once I corrected it, the whole session changed direction in one message. If I hadn't noticed, I could easily have published a post referring to a promise nobody ever saw.

It could only see what went through the product

Once we had the right angle, the skill asked for the one fact it couldn't know: what actually happened with Zapier. I told it we were live but still in beta.

What it didn't ask was whether I'd already written about it somewhere else. I had. That morning I'd published a four-minute Dev.to article with the eight rounds of review, the REST Hooks, and the JavaScript I ended up putting in a field labeled "label". None of that existed in Publora, so the skill had no way to know about it.

That limitation is obvious in theory: an agent only knows the data you give it. In practice, it's easy to forget until it starts repeating something you've already published elsewhere.

So now, whenever it asks for a missing fact, it also asks whether I've already written about the topic somewhere else: article, changelog, release notes, whatever.

The slop checker passed a draft that was still slop

I run every outgoing text through a script that flags machine-sounding writing: vocabulary, repeated structures, the usual tells that become easy to spot once you've collected enough of them.

The draft passed.

I showed it to a colleague anyway, and she said she could still see AI slop in it. She was right.

Three of the strongest lines had been lifted almost directly from my Dev.to article from that morning. "The requirement I reread three times, certain I'd misunderstood." Fine line on its own. Less fine when the same person has already seen it six hours earlier. No vocabulary checker is going to catch that.

The other problems were structural. A withheld hook: "with a Beta tag, which I'll get to." A neat paradox: "you have to prove the app is being used before it's allowed to exist." A three-item list whose last item worked mostly because of the rhythm. The word "literally". None of those is automatically bad. Together, in a short post, they started sounding very familiar.

The rewrite was 720 characters. The version that passed the script was 1198.

So I kept the checker, but moved it earlier in the process. It catches the things that exist inside the text. What it can't see is everything around the text: what I published yesterday, who is reading, or whether I've stacked too many individually reasonable choices into something that sounds generated.

I'd still put a checker somewhere between draft and publish. It costs very little once it exists, catches the obvious layer, and doesn't get tired at six in the evening. Build one, borrow one, or use a checklist. Just don't mistake it for the whole review.

What it looks like now

There are eight categories and forty angles. Every angle has a core: one fact that has to come from the person using the skill, whether that's the mistake, the number, or the tool name. The instructions repeat this in several places because inventing that core is the easiest way to produce something plausible and false under someone's name.

There are also four reference files behind the angles: what the first two lines need to do before the feed collapses the rest, how to infer voice from existing posts instead of asking someone to describe their own voice, the tells a script can't catch, and how the same angle changes between LinkedIn and X.

It stops at the draft. Nothing publishes automatically.

It's MIT, it works on its own, and connecting Publora lets it read your feed and schedule the result: publora-team/publora-post-ideas

For the record, I'm not an engineer. My job is getting people to use our product, and I built this with Claude: it wrote the code, I led, tested, and sent it back when it got things wrong. Most of the useful work ended up being in those three failures, because each one showed me a rule I hadn't written yet.

Has an agent ever been confidently wrong about your own data? I'm curious what it misunderstood, and what you changed after that.

My MCP integration got rejected. Almost nothing in the server had to change.

Eugeniya Ivanova — Mon, 07 Sep 2026 07:54:22 +0000

In July I set out to add our MCP server to the ChatGPT app directory. The server was already live, running in Claude and Cursor, with OAuth working. Submitting looked like a formality: describe what already exists, fill in the application, hit Submit.

A month and one rejection later, almost nothing had changed in the server itself. It had been working the whole time. What we ended up fixing was everything around it: how ChatGPT discovers the tools, what the scanner expects, what we'd written in the descriptions, and whether a reviewer could actually log in.

Here's what caught me.

The tool list that freezes solid

The first problem came before submission. I connected the server to ChatGPT — the connector was created, but it showed "no actions available." Zero tools. In Claude and Cursor the same tools loaded fine.

I spent a while looking at SSE and caching. Neither was the problem. ChatGPT reads the tool list when the app is created, and if the server returns zero at that point, the app can get stuck there. "Refresh" is disabled at zero and "Save" is greyed out. In my case, the way out was to delete the app and create it again.

The server returned zero because it required a token for tools/list itself. Claude logs in first and fetches the list afterwards, which is why we'd never seen the problem there. ChatGPT fetches the list before authorization, gets nothing, and turns to stone. So now I check one thing before doing anything else: tools/list needs to return 200 with the tools and no token.

Annotations the scanner demands and the spec doesn't

Next, OpenAI's scanner went through every tool and required explicit readOnlyHint, openWorldHint and destructiveHint values. Four read-only tools didn't have destructiveHint, which made sense according to the MCP spec: it only matters when readOnlyHint: false.

The scanner wanted it anyway. We added destructiveHint: false to those tools and wrote justifications for forty-odd annotation values. The tools themselves didn't change. We just had to make explicit something the spec allowed us to leave implied.

The domain challenge that wants a bare string and lives forever

A small one that's easy to waste time on: OpenAI's domain verification expects the endpoint to return a bare token string. No JSON, no quotes. Return {"token": "..."} and it fails.

It also isn't a one-time verification endpoint. It has to stay there in production, answering the same way afterwards. So we now have a tiny endpoint with one permanent job: return a string when OpenAI asks.

The drift I caught on myself

Then I found something that actually was our mistake.

Our public mcp-server repo defines 18 tools, four of them for LinkedIn analytics: post stats, account stats, followers and profile summary. The live server exposes 16, and none of those analytics tools are among them. They exist in the REST API, but aren't exposed through MCP.

The public repo had fallen behind the live server, and the app description was based on the repo. So we were describing analytics that someone using MCP couldn't actually access. I removed them from the description and release notes.

Then I found the same old description in two more places: the README for the Zed extension and the PR for the Docker MCP Catalog. The Zed PR was also pointing at a commit from before the correction, so merging it would have put the outdated claim into another catalog. We'd updated the product and missed a few places where we'd described it. Easy enough to do when those descriptions live in different repos and submissions.

The rejection that wasn't about the code

Submitted August 5, every wizard step completed in one pass. Rejected August 24.

The message was: "We're unable to complete your sign-in or OAuth flow… ensure valid, working credentials… no additional setup or verification."

Before changing anything, I walked through the flow again. Dynamic client registration returned 201. /authorize sent me to our consent screen. The sign-in page in a clean browser was a normal email-and-password form with no captcha. tools/list without a key returned the tools. API and MCP access were enabled on every plan, including free. Everything worked.

Then we looked at the account we'd given the reviewer.

Our own accounts use Google sign-in. A reviewer can't use our Google account, and even if they tried, the second factor would land on our phone. We'd managed to give them credentials for an account they had no way to get into.

Even worse, Canva had rejected us for the same reason before. Twice was enough to stop calling it bad luck. We simply didn't have "can a stranger actually use these credentials?" on our submission checklist.

What actually fixed it

We created a separate reviewer account: email and password, email confirmed ahead of time, a couple of channels connected, with some posts and drafts already there. We also included eight test cases — five positive and three negative.

The most useful one was a full write-path test through publora-playground. It's a fake publishing target: it validates the post against the same rules as a real one and returns the same kind of response, but throws the request away at the end instead of publishing it anywhere. A reviewer can go through the whole publishing flow without putting a test post on someone's actual timeline.

It took about thirty lines and ended up being one of the most useful things we added for the submission. The reviewer could finally test writes without needing a disposable social account.

We resubmitted on the evening of August 24. Approved September 4.

What I wrote down for next time

The main addition to my submission checklist is pretty basic: go through the product as the reviewer, not as yourself.

The server worked in Claude and Cursor. It followed the spec. OAuth worked when we tested it. But ChatGPT asked for the tool list in a different order, its scanner expected metadata we hadn't needed elsewhere, and the reviewer needed a login that didn't depend on being us. Those were the things that took the month.

I did this with Claude — it wrote the code and configs, while I checked what was happening and decided what needed changing. The funny part is that almost none of those decisions involved changing the server itself. Most of the work ended up being metadata, descriptions and access.

What's gotten your product bounced from a platform review — something actually broken, or something you never thought a reviewer would run into?

I sell social media automation. My survey says people want the opposite.

Eugeniya Ivanova — Thu, 03 Sep 2026 08:07:39 +0000

I work at Publora — an API and MCP for publishing to social networks from one place, including through an AI agent. So, in a sense, my job is selling automation for posting. Which made the answers I started getting from actual people a little awkward.

I've been doing a small study — nothing fancy, just messaging people directly and asking: what do you use to post, and why do you do it that way? No pitch, no setup. It's an ongoing thing, reaching out to people across different niches one by one, so this isn't a clean statistic — more a pile of honest answers I'm still adding to. A few hundred replies in, and I'm still going.

The answers are all over the place, but one thing keeps coming up. People aren't asking for more automation. Quite a lot of them want to keep the final step for themselves.

A few answers, anonymized.

One person told me: "I use AI rarely, do the core work myself. Sometimes I go into ChatGPT or Gemini as a 'second brain' — when I'm out of ideas or a deadline's closing in. But at the end of the day it's still just a machine."

So AI is useful to think with. That doesn't mean they want it doing everything.

Another: "I use Claude, but not for posting — it sort of sets me up, and I publish myself."

And a third was very direct: "I'm wary of AI tools having access to my account. LinkedIn isn't forgiving about it."

That one wasn't really about whether AI-written posts sound authentic. They simply didn't want another tool having that much access to their account.

Then there was this: "I like hitting publish myself. In a world where everything's polished, it makes the content feel a little more alive."

Different reasons: sometimes security, sometimes control, sometimes just liking the fact that there's still a person involved. But I kept hearing versions of the same thing. Draft for me, help me think, prepare it — fine. I'll publish it.

Nobody was dreaming about an agent happily posting all day while they went for coffee.

At first this was slightly uncomfortable to hear, considering what I do for a living. But the more replies I read, the less it sounded like an objection to automation. It sounded more like people being quite specific about which parts they actually want automated.

Where that caution stops being a quirk

One answer stood out because it came from someone managing several brands rather than just their own account.

They prefer tools with integrations because content and reporting are easier there than doing everything natively. The problem is that not every platform has the integrations they need, and the more channels a brand uses, the messier the whole setup gets.

That changes the problem quite a bit.

Being cautious about giving AI access to your own LinkedIn account is one thing. Being an agency responsible for ten clients' accounts is another. Now you're dealing with reputations that aren't yours, client credentials, several calendars, approvals living somewhere in email, and the possibility of someone putting one client's post on another client's account.

At that point, automating everything sounds terrifying. Doing everything manually isn't much better. Ten clients still have to fit into the same working day.

So you need something in between.

What that looks like in practice

After reading the replies, I kept coming back to three things.

The first is keeping clients separate. Each one needs their own connections, content and calendar, without the possibility of a post quietly ending up on somebody else's account. A posting mistake on your own account is embarrassing. Doing it to a client's account can get expensive.

The second is passwords. Ideally, an agency shouldn't have them at all. The client connects their account through an OAuth link, and the team can work with it without ever knowing the login. The person who told me they were wary of tools having access to their account wasn't being paranoid. That's a perfectly reasonable thing to worry about.

And then there's approval. An agent can draft a post. It can prepare it, schedule it, do the repetitive bits. But publishing can still wait for a person to approve it. In a team, that can also mean the person who wrote the post isn't the person who approves it.

It's basically the same habit I kept seeing in the survey, only with more people involved.

We build this at Publora — it's our workspace for agencies, and the API is documented here. I won't turn this into a tour of the product; if that's what you're looking for, the links are there.

What's been more interesting for me is realizing that some of the things we'd been thinking about as product features map almost exactly to things people told me they were worried about.

What I took from it

Automation is usually sold as: let the machine do this for you.

But after reading these replies, I think there's a pretty big group of people asking for something slightly different: help me do it, just don't take the whole thing away from me.

For someone posting to their own account, that might simply mean wanting to hit Publish themselves. For an agency, the same instinct turns into much more practical requirements: keep clients separate, don't pass passwords around, and make sure a person approves what goes out.

I find it slightly funny that it took working inside an automation company to make me think harder about what shouldn't be automated.

And for the record, I wrote this with AI. It helped me sort through material and clean up the draft. Deciding what was interesting in a few hundred replies was still my job.

I'm keeping that bit.

Where do you draw the line? What are you happy to hand to an agent, and what do you still want to do yourself?

I published our app on Zapier. The no-code platform made me write code.

Eugeniya Ivanova — Mon, 31 Aug 2026 06:29:04 +0000

Publora is in the Zapier app directory now. I didn't do it to tick a box on some distribution list. My job is making our product easy to live with, and if a user has an agent that can wire us in deeper so they don't have to build the plumbing themselves, I'll go make that happen. Zapier is exactly that case: it connects Publora to thousands of other apps, so nobody has to hand-roll the integration.

Worth it. I'd just add that "a no-code platform" and "publishing your own app on a no-code platform" turn out to be two very different Zapiers.

Prove it works for users who don't exist yet

Here's the requirement I reread three times, sure I'd misunderstood.

To submit an app for review, every trigger, every action, and every search has to be tested inside a live Zap, turned on, with at least one successful run in the history. You can't delete those Zaps; the reviewer can ask to see them.

So the logic goes like this. You want to publish an app so people can start using it. But to publish it, you first have to prove it's already being used. Run every component for real, as if you had the users you're publishing it to attract. The app isn't in the directory yet, and a history of real use already has to exist.

You end up standing in for your own users who aren't there yet. You build the Zaps, run each one, make sure every one has a green run, and don't touch them afterward.

A routine task you run like a rocket launch

The second surprise. My tasks here are the plain ones: schedule a post, publish a post, delete a post. This isn't a satellite launch. It's what our API does a thousand times a day over one line of code.

As a Zapier app, each of those ordinary tasks has to be wrapped, configured, and run live on its own. Create Post, Update Post, Delete Post, two triggers, two searches, each with its own test run under the validator's eye. Scheduling a post is something I can describe in one sentence. Here it became a component with a run history.

Then the small surprises a "no-code" promise doesn't quite imply. The connection label, the line that tells the user which account they connected, couldn't just read a field. {{connections.0.username}} doesn't work, because Zapier won't follow a path into an array. So the label needs actual JavaScript:

const connections = bundle.inputData.connections || [];
const first = connections[0] || {};
return { label: first.username || 'Publora' };

That's in a box labeled "label." On a no-code platform.

The triggers are the other place the word stretches. These aren't polling. They're REST Hooks on our own webhooks, which means subscribing and unsubscribing are API calls you define by hand:

// subscribe
const options = {
  url: 'https://api.publora.com/api/v1/webhooks',
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Accept': 'application/json',
    'x-publora-key': bundle.authData.api_key,
  },
  body: {
    name: 'Zapier - Post Published',
    url: bundle.targetUrl,
    events: ['post.published'],
  },
};

return z.request(options).then((response) => {
  response.throwForStatus();
  return response.json.webhook;
});

What subscribe returns is not incidental. Zapier hands it back to you as bundle.subscribeData, and unsubscribe reads the webhook id out of it to call DELETE /webhooks/{id}. Return the wrong shape and the Zap turns on cleanly, then never cleans up after itself.

A few more edges, for anyone about to do this. A field's type and key are locked after you create it, and if you get the shape of a step wrong and you don't fix it, you recreate it from scratch. The first published version gets locked for editing once real people are on it, so you clone it into a new one and make changes there. And the editor session expires with a cheerful failed csrf; you reload, and the code you just wrote is gone.

None of it is fatal. I just walked in with a one-line task and walked out with versioning, user migrations, and a chunk of JavaScript in a field called "label."

Where it landed

The app passed review after eight rounds of reviewer notes, then out into the directory with a Beta tag. Zapier's beta runs ninety days, and you leave it one of two ways: pull in enough active users, or embed their widget inside your own product. Familiar shape. The platform holds you at "not quite yet," and the key out is either bring it an audience or let it inside your product.

I don't regret the trip. The directory listing genuinely lowers the effort for anyone who wants to post from whatever workflow they already live in, and I wrote them a separate tutorial for that. But the "no-code" part I left somewhere around the halfway mark. For the user assembling a Zap out of ready-made blocks, sure, no code. For the person making those blocks, no-code ends exactly where anything past a single step begins.

For the record, I'm not an engineer. My job is getting people to use our product, and I built this with Claude: it wrote the code, I led, tested, and sent it back to redo. Which is maybe the honest shape of "no-code" in 2026 anyway. The code didn't disappear. It just moved to someone else, or something else.

Did your no-code platforms keep the promise when you went past a single step? Or did you end up opening the code editor too?