DEV Community: Mary Hill

I put a public graffiti wall on my SaaS homepage

Mary Hill — Mon, 03 Aug 2026 15:05:06 +0000

Somewhere below the hero, most SaaS homepages have the same section: a screenshot of the product, slightly angled, maybe in a browser mockup with fake traffic numbers. Everyone scrolls past it, because everyone knows screenshots are where marketing happens.

Our homepage section is literally titled "Proof, not promises," so a screenshot felt like self-parody. Instead we embedded the product itself: a public guestbook called Owners Were Here, built with Fugte (my widget builder), embedded on the homepage with the exact iframe snippet any customer gets. Anyone can sign it. The notes pile up into a wall. It is a graffiti wall with a submit button.

This post is the why, and then the three sharp edges you hit the moment you let strangers write to your landing page.

Why a guestbook, of all things

Two reasons, one honest and one sneaky.

The honest one: forms are the hardest widget to fake. A countdown timer in a screenshot proves nothing; anything can render a countdown. A form that visibly works proves the entire invisible half of the product: the submit endpoint, the spam screening, the storage, the fact that a random visitor on a third-party page can post data and it lands somewhere real. That invisible half is the actual product. So the demo had to be a form, and a contact form demo is boring because you can't show strangers each other's messages. A guestbook is a form whose submissions are meant to be public. The demo demos itself.

The sneaky one: a wall of real notes from real visitors is social proof that compounds while I sleep. Testimonial sections take months of collection and permission-asking. A graffiti wall fills itself, and its scrappiness is the charm. Even a wall with some junk on it says "people were here," which is more than a polished quote carousel says.

Edge 1: the endpoint is public, and there is no secret to hide

The widget is an iframe pointed at its hosted page. The instance id is right there in the URL. Anyone can read the JS. So the design constraint is brutal and clarifying:

The submit endpoint must be safe to expose to the entire internet, because it is.

There is no API key you can bury in client-side widget code; a "secret" shipped to the browser is a public value with extra steps. So the endpoint protects itself instead: Cloudflare Turnstile runs on every submission (the widget asks its host shell for a token over postMessage, and each token is single-use and origin-bound), rate limiting sits behind that, and the server validates submissions against the fields the widget's schema declares, with a hard size cap. Free-form JSON from an anonymous visitor never gets stored as-is.

If you are wiring up your own public form endpoint this is the checklist that matters: bot check, rate limit, schema validation, size cap. Any of the four missing, and the internet will find it.

Edge 2: you are now rendering strangers' text on your own homepage

A guestbook renders untrusted input, in an iframe, potentially forever. The classic mistake is building the wall with innerHTML because it is Tuesday and it works. Then someone signs your wall with a <script> tag and their note executes instead of displaying.

The rule is one sentence: untrusted text goes through textContent, never innerHTML. On this wall, a note containing <script>alert(1)</script> renders as exactly those characters, which honestly looks right at home on a graffiti wall. Street art, not code execution.

(Defense in depth still applies: the widget lives in a sandboxed iframe on a separate origin from the app, so even a mistake there does not run next to anyone's session. But the sandbox is the seatbelt, not the driving.)

Edge 3: the wall grows forever, your homepage should not

Fugte embeds auto-size: the hosted widget posts its rendered height to the parent page, keyed by widget id, and the embedding page applies it. Lovely for a pricing table. A disaster for a wall that gets taller with every note, because in six months the homepage would be 94% guestbook.

The fix is a viewport: cap the applied height and let the wall scroll inside its frame.

var MAX_HEIGHT = 640;
window.addEventListener('message', function (ev) {
  var d = ev.data;
  if (!d || d.source !== 'webdyi-widget' || d.type !== 'resize' || d.id !== id) return;
  var h = +d.height || 0;
  if (h > 0) frame.style.height = Math.min(h, MAX_HEIGHT) + 'px';
});

Below the cap, the frame hugs the content, so a young wall has no dead space. Past the cap, the frame stops growing and the wall scrolls internally, with an "open the full wall" link for anyone who wants the whole thing. Bonus: a capped iframe is also a layout-shift fix, since an embed that resizes itself mid-scroll is a CLS penalty you inflicted on yourself.

What I expect to go wrong

Public wall, public internet: some of it will be junk. Turnstile and rate limiting keep the bots out, but nothing stops a human from contributing "hi" seventeen times, and moderation means the worst entries need deleting by hand. I have made peace with this. A too-clean guestbook reads as fake anyway; the failure mode I actually care about (the wall becoming an attack surface) is handled by the three edges above.

There is also the possibility the wall just stays sparse and slightly embarrassing for a while. That is fine too. It is still a live form on a homepage, doing the one thing screenshots cannot: working.

Come vandalize it

The wall is on the Fugte homepage, or you can open the full wall directly. Sign it, try to break it politely, and if you find an edge I missed, the contact form (also a Fugte widget, naturally) works.

Want a wall of your own? The guestbook is a starter widget now, so you can put one on your own site and let your users sign it.

And if what you actually need is the boring version of this, a lead form with the submit path, spam screening, and inbox already attached, that starter is here.

The average SaaS now has fewer users, and that changes what you should build

Mary Hill — Mon, 27 Jul 2026 14:14:00 +0000

There is a chart going around that shows three lines from "past" to "present":

Users per SaaS: falling.
Global SaaS count: rising, steeply.
Solo builders and creators: rising with it.

The before/after panel underneath makes it concrete. The "before" column lists four products, Niche Finance, Legacy ERP, Specialized CAD, a niche code platform, each with a big block of users. The "today" column lists six, CRM, task manager, design platform, video tools, e-com store, community hub, each with two users or one.

You can argue with the axes. There are no numbers on them, and "scale" is
doing a lot of work. But the direction matches what anyone shipping software in the last few years has felt: the market is fragmenting into many more, much smaller products.

I want to talk about a specific, boring consequence of that, because it is the one that has eaten the most of my time.

Small products need the same furniture as big ones

When you were one of four SaaS products in a category, you had a team. Someone owned the marketing site. Someone owned the design system. The pricing page was a project with a ticket.

When you are one of four hundred, you are probably one person. And you still need:

A pricing table, because you charge money.
A waitlist or email capture, because you launched before you were ready..
A changelog or roadmap, because people ask what is shipping.
Some social proof, because nobody has heard of you.
A launch countdown, because you are doing a Product Hunt thing on Tuesday.

None of this is hard. That is what makes it insidious. Each piece is a two hour job that you will do at 11pm, hardcode, and then maintain forever. The pricing table has prices in it. The countdown has a date in it.

The fragmentation the chart describes means more people are hitting this
problem, each with less time to solve it. The absolute amount of pricing
table code being written by hand right now is probably at an all time high, which is a genuinely stupid thing for our industry to be spending time on.

The three ways this usually goes

You hardcode it. Fastest tonight. Now changing a price is a git commit, a build, and a deploy. You will postpone it. Your pricing page will be wrong for two weeks at some point, and you will find out from a customer.

You install a page builder. Now your landing page pulls 400KB of framework to render a countdown, your Lighthouse score drops, and the thing wants $19/month per feature.

You build a tiny CMS. You now maintain a CMS. You did not want to maintain a CMS. You wanted to change a price.

The real problem in all three: the content and the code have the same
lifecycle. A price changes monthly. The code that renders it changes almost never. Coupling them means every content edit pays the full cost of a code change.

Splitting the two lifecycles

The approach I ended up building around is to treat each of these pieces as a tiny hosted app with two layers:

A code layer written once, by you or by an AI.
A settings layer generated from a schema, that you edit later without touching the code.

Concretely, a widget is four files:

index.html    markup fragment, Liquid + HTML
style.css     styles, Liquid works here too
script.js     vanilla JS, no build step
schema.json   the settings that generate the edit form

The schema is the interesting part. It is what turns hardcoded values into
things you can change later:

{
  "name": "Launch countdown",
  "settings": [
    { "id": "heading", "type": "text", "label": "Heading", "default": "Launching in" },
    { "id": "date", "type": "date", "label": "Launch date", "default": "2026-09-01" },
    { "id": "accent", "type": "color", "label": "Accent", "default": "#0c6fd0" }
  ]
}

Reference them in the markup, and they become form fields:

<div class="countdown">
  <h2>{{ settings.heading | default: 'Launching in' }}</h2>
  <span id="t" style="color: {{ settings.accent }}"></span>
</div>

Now the launch date is a date picker, not a deploy. That is the entire idea.

A waitlist with no backend

The piece I reach for most is the form, because "collect emails" is where
solo projects usually give up and reach for a third party.

{% form "waitlist", success-message: "You're on the list." %}
  <input type="email" name="email" placeholder="you@example.com" required>
  <button type="submit">Join the waitlist</button>
  {{ form.success }}
  {{ form.error }}
{% endform %}

Plus a storage declaration in the schema:

{
  "storage": [
    {
      "id": "waitlist",
      "fields": [{ "id": "email", "type": "email", "required": true }]
    }
  ]
}

No endpoint, no database, no spam handling, no CAPTCHA wiring. Submissions
land in a dashboard you can export to CSV. For a project that might get 40
signups or might get 4,000, that is the right amount of infrastructure, which is to say almost none.

One design decision worth calling out, because it is the kind of thing that bites people: submissions are never public by default. If you want to show entries back on the widget, a testimonial wall or a public goal tracker, you tick specific fields to expose. Email and phone stay private unless you deliberately make them public. The failure mode of "we accidentally published everyone's email address" is common enough that the default should not be opt-out.

Where AI actually fits

The honest version: AI is very good at writing these small self-contained pieces, and it is the reason the "solo builders" line on that chart is going up at all. A countdown, an FAQ accordion, a pricing table are all well inside what a model writes correctly on the first try.

What models are not good at is guessing a platform's conventions. Ask any assistant for a widget in a format it has never seen and you get plausible code that fails validation: a raw <form> with its own fetch handler, a {% if settings.image %} that is true when the image is blank because empty strings are truthy in Liquid, a new Date() fed a formatted date string.

So we published the spec at fugte.com/docs/build, with a plain text mirror at /llms-build.txt. It opens with a primer you can paste into ChatGPT or Claude before asking for a widget. That is not a growth hack, it is the cheapest fix for the actual failure mode: the model was guessing, so give it the rules.

What I would actually take from the chart

If the trend is real, and I think the direction is even if the axes are decorative, then the interesting consequence is not "SaaS is dying" or "the market is saturated". It is that the fixed cost of shipping a product has to keep falling, because there are fewer users to amortise it over.

A product with 200 users cannot justify the same infrastructure as one with 200,000. The pricing table still has to exist. It just cannot cost a week anymore.

That is the bet behind what I build: the small pieces every product needs
should be something you assemble in an afternoon and edit in a form field
afterwards, not something you own forever.

Disclosure: I build Fugte, so read the middle section with that bias in mind. The problem it addresses is real whether or not my answer is the one you pick, and if you would rather hardcode a countdown and never think about it again, that is a completely defensible call. Free tier if you want to try it, and the widget format is documented in full at fugte.com/docs/build.

What is your split? Do you hardcode the small stuff and eat the edit cost, or do you build the settings layer up front?

Stop being the human CMS for a date field

Mary Hill — Tue, 21 Jul 2026 13:10:00 +0000

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.