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:
- 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.
- 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.
- 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>
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.
Top comments (3)
I like the distinction between the code layer and the content layer—that’s a much healthier handoff than asking clients to email a developer every time a date changes.
One trade-off I’d also consider is long-term ownership. Replacing a developer dependency with a hosted widget platform shifts the trust boundary rather than removing it. For many businesses that’s a perfectly reasonable trade, but I’d be interested in hearing how you think about exportability, migration, or a “what if Fugte disappeared tomorrow?” scenario. Clear portability often matters just as much as easy editing.
References:
Thank you, and you are right to push on this. The trust boundary framing is fair, I have not removed the dependency, I have moved it. So here is the honest exit story as it stands today.
The code layer is plain HTML, CSS, and JavaScript, and it stays visible and copyable in the editor. Nothing is compiled into a proprietary format or runtime. If Fugte disappeared tomorrow, you could copy your widget code out, host it anywhere as a static page, and point your site at the new URL. The widget itself does not need Fugte to run.
What you would genuinely lose is the layer around the code: the hosted URL, the no-code editing form that non-technical owners use, and hosted extras like form submission collection.
Where I agree there is real work, a one-click export of everything (code, media, submissions). Clear portability should be a feature, not a policy promise, and this is a fair nudge in that direction.
Thanks for the CNCF and Fowler links. CNCF link doesn't work btw.
I like this direction. I also think portability is more than exporting HTML/CSS/JS. The widget definition itself (editable fields, validation rules, AI metadata, assets, submissions, and configuration) should ideally be exportable as well. If those can be restored elsewhere with minimal effort, vendor lock-in becomes much less of a concern. In other words, code portability is great—but operational portability is what builds long-term trust.