날짜 필드에 대한 인간 CMS 되지 않기

A bakery owner pays a freelancer $120 to change the end date on a sale countdown. Not to build it. To change the date.

A freelancer builds their fifth FAQ accordion of the year, for the fifth client, from scratch, again.

Both of these people are losing. The owner is paying developer rates for a content edit. The developer is doing work that stopped being interesting four accordions ago, and now owns an informal support contract for every tiny widget they ever shipped.

I kept running into both sides of this, so I built Fugte to fix it. Disclosure up front: this is my product, so read with that bias in mind. But the problem is real whether or not my solution is the one you pick.

The widget treadmill

Almost every small business site needs the same handful of things:

• A countdown for the next sale or launch
• An FAQ accordion for the repeat questions (shipping, returns, opening hours)
• A pricing table
• A testimonial carousel
• A donation or goal tracker
• A newsletter signup or contact form

None of these are hard to build. That is exactly the problem. They are too small to justify a real project, too custom for a generic plugin, and too dynamic to hardcode. The countdown has a date in it. The pricing table has prices in it. The FAQ grows. Whoever builds it becomes the person who maintains it, forever, one “quick change” email at a time.

The usual outcomes:

1. The owner hires someone for every edit. The site stays accurate but every text change costs real money, so edits get postponed and the site quietly goes stale.
2. The owner installs a page builder plugin. Now the site loads 400 KB of widget framework to render a countdown, and the plugin wants $19/month per feature.
3. The developer hardcodes it. Fast to ship, and now a code deploy is required to change a price.

The approach: widgets as tiny hosted apps

The fix I landed on: treat each widget as a small hosted app with two layers.

• A code layer (HTML, CSS, JavaScript) that a developer or an AI writes once.
• A content layer (text, dates, prices, images, colors) that the owner edits through a form, with no access to the code.

The widget is published at a hosted URL, and the site embeds it with one iframe or link. When the owner changes the sale date, every embed updates. No deploy, no plugin, no email to the developer.

If you’re a developer or freelancer

You already write widget code like this:

<div class="countdown" data-ends="2026-08-01T00:00:00Z">
  <span class="days"></span> days left in our summer sale
</div>
<script>
  const el = document.querySelector('.countdown');
  const ends = new Date(el.dataset.ends);
  const tick = () => {
    const days = Math.max(0, Math.ceil((ends - Date.now()) / 86400000));
    el.querySelector('.days').textContent = days;
  };
  tick();
  setInterval(tick, 60000);
</script>

Enter fullscreen mode Exit fullscreen mode

The code is the easy part. The expensive part is everything around it: hosting it somewhere, and fielding the email three weeks later asking you to change 2026-08-01 to 2026-09-01.

In Fugte you paste (or write, or generate) that code once, then choose which parts are editable: the end date, the message, the colors. Those become safe settings your client can change through a simple form. They get knobs, not source code. You get one hosted, sandboxed embed URL you can reuse across client projects, and you stop being the human CMS for a date field.

For agency and freelance work this changes the handoff conversation. “Here is your widget, and here is where you edit it yourself” is a better deliverable than “email me when the sale changes.”

If you run a small business

You do not need the code layer at all. You describe what you want in a sentence:

a donation goal tracker for my bakery’s community fundraiser, warm colors

and the AI builds it. Or you start from a starter widget (countdown, FAQ, pricing table, testimonial carousel, spinning wheel, before/after slider, and so on) and change the content to yours. Either way, the parts you care about stay editable by you: the goal amount, the prices, the questions, the photos.

Then you copy one link or iframe into wherever your site lives. That includes the platforms that normally make custom code painful:

• Shopify (no theme editing)
• WordPress, Webflow, any custom site
• Notion pages
• Canva websites, which accept embeds but give you almost no way to run custom interactive code otherwise

That last one surprises people. If you built your site in Canva, an embed link is essentially your only path to a live countdown or FAQ, and it works well.

Honest limitations

Because this is dev.to and not a landing page:

• It’s an iframe. Embedded widget content is not part of your page’s DOM. For SEO-critical content, keep important text in your page itself and use widgets for the interactive parts.
• Iframes need sizing care. Fixed-height content is easy; very dynamic heights can take a little adjustment.
• The free tier shows Fugte branding on widgets. Free gives you unlimited widgets and views with 200 AI credits a month; removing the branding is on the $4.99/month plan.
• Live form submissions are limited by plan (1 on Free, 3 on Basic), so a contact form that gets heavy traffic needs the right tier.

Try it

The free tier needs no card: describe a widget at fugte.com and it is ready to embed in a couple of minutes. Developers can start from the docs or the developer page instead. And if you get stuck at any point, the Learn tab inside the app has short how-tos for the whole loop: creating a widget, choosing editable fields, handling form submissions, and publishing.

If you have fought the widget treadmill from either side, the freelancer side or the owner side, I would genuinely like to hear how you handled it. And if you try Fugte and something is rough, tell me that too. It is early, and that feedback is the useful kind.