HearthGuard

• 

  welcome screen and website information collection

• 

  second results screen

• 

  first results screen

Inspiration

The candle maker on Etsy. The bookkeeper running QuickBooks out of a spare bedroom. The photographer with a Squarespace site and a Stripe account. These are the people most exposed to modern internet attacks, and the cybersecurity tools market does almost nothing for them. Enterprise products are priced for IT teams with budgets and built around dashboards full of jargon. Consumer antivirus addresses only a small slice of the actual exposure. Free single‑purpose checkers exist (an SSL test, a DMARC lookup, a breach lookup) and synthesize the results in language they have never been taught.

The few solo operators who do find the existing cyber tools tend to be left worse off, not better, because findings are surfaced without context or remediation. Telling a person who runs a flower shop out of her garage that her DMARC record is missing, with no explanation of what DMARC is or what to do about it, only breeds fear. The result is the worst possible outcome: an operator who knows they have a problem and does nothing about it.

I built HearthGuard because that gap is real, the audience is enormous, and nobody is filling it.

What it does

HearthGuard runs a comprehensive cybersecurity audit of a sole proprietor's home business in under a minute, using only three pieces of information they already know: a domain, a business email, and one storefront URL. The audit covers five pillars. Transport security checks the SSL certificate and HSTS configuration. Email authentication checks SPF, DKIM, and DMARC records on the operator's email domain. Breach exposure checks the operator's email addresses against the Have I Been Pwned breach corpus. Brand impersonation searches for typosquatted domains and lookalike accounts. Storefront privacy checks for the presence and quality of the operator's privacy policy.

Each finding is delivered in a fixed four‑sentence shape, namely a one‑sentence statement of the situation, a one‑sentence translation of the technical concept, a one‑sentence statement of the consequence to the operator's business, and one specific recommended action with a realistic time estimate. Findings are ranked by severity using a deterministic rule, not an LLM judgment, into three buckets called "Do these first," "Worth doing soon," and "Worth doing when you have time." Pillars that found nothing render as soft "all clear" reassurance cards, because an audit that silently omits clean pillars is less trustworthy than one that explicitly tells the operator what was checked.

When the audit detects a brand impersonation, the operator clicks one button and the product drafts a platform‑appropriate report message, ready to copy into Instagram's reporting form, Meta's intellectual property report, or the registrar's abuse desk, in the calm professional voice that abuse teams respond to fastest. The operator stays in the driver's seat; the product makes the work easy.

Audit history is saved, so returning operators see a "what changed since last audit" banner showing how many findings have been resolved and how many are new. The product collects no information beyond the operator's email address for the optional monthly reminder, and there is no signup wall before the first audit.

How I built it

The whole product was built in a single MeDo conversation, structured as a deliberate sequence of focused turns rather than a stream of consciousness. The opening turn was a roughly two‑thousand‑word brief that loaded the project context, the audience persona, the voice rule, the five‑pillar audit architecture, the deterministic severity model, the four plugin contracts, the two ERNIE prompts, the five‑table data model, the three screens, the visual style, and the deployment shape.

Critically, the opening turn ended by asking MeDo to return a project plan back for review before generating any code. That checkpoint was the most valuable single moment in the build, because correcting MeDo's understanding before generation was dramatically cheaper than correcting it afterward.

Subsequent turns each had one focused goal. Three turns generated the three screens, namely the landing page, the report page, and the saved‑report return page with its diff banner. Four turns wired each of the four plugins. Two turns embedded the ERNIE system prompts. Two turns ran the visual polish pass and the voice review pass. A final turn deployed and smoke‑tested. MeDo's full‑stack generation produced seven Edge Functions and a five‑table relational database in a single deployment, accessible at one public URL with no signup.

The most important discipline I imposed on the build was a single‑sentence voice rule, written on a sticky note above the work, namely "write the way a calm older sibling explains a problem to someone they love." That rule was repeated in the system prompt for every ERNIE call, in the visual polish pass, and in the final voice review where every static string in the product was checked against it. Voice is the product as much as the audit is, and the rule is what kept the build from drifting into the standard cybersecurity tone of red banners and jargon.

How plugins and ERNIE were used (the technical depth section)

Four real external plugins supply the live audit data. The DNS lookup plugin queries SPF, DKIM, DMARC, and SSL certificate metadata directly from authoritative DNS. The breach lookup plugin queries Have I Been Pwned for matches against the operator's email addresses. The impersonation discovery plugin generates near‑match domain candidates using a small set of typosquat patterns (single character substitution, single character omission, single character insertion, adjacent character transposition, and common homoglyphs), then checks each candidate via Cloudflare DNS‑over‑HTTPS for active registration. The storefront fetch plugin retrieves the operator's storefront page with a polite user‑agent and an eight‑second timeout, extracts a brand voice sample from the page's body copy, and detects any linked privacy policy URL.

Every plugin call has graceful degradation. If a plugin fails or times out, its pillar reports as "we could not check this on this audit, we will try again next time," rather than failing the whole report or quietly omitting the pillar. The orchestrator persists a per‑pillar status (finding, clear, or could not check) on every audit, so the saved‑report return page can render the same shape from history.

ERNIE Bot from Baidu is used for two distinct generative tasks, both bounded by a tightly scoped system prompt rather than an open prompt. The first is the finding rewrite, which receives a structured finding object (the pillar, the deterministic condition, the severity, the verifiable facts from the plugin output, and a small brand voice sample from the operator's storefront) and returns the four‑sentence finding text in the product voice. The second is the takedown letter drafting, which receives an impersonation finding plus a target platform and returns a subject line, a body, and a one‑sentence note to the operator about what to expect after sending. The two prompts use different temperature settings (low for findings, slightly higher for letters) and different voice instructions (calm older sibling for the report, calm professional for the abuse desk).

ERNIE is deliberately kept away from the audit logic itself. The decision of whether DMARC is present, whether a breach match exists, whether an SSL certificate is expiring, is made by deterministic plugin output, not by an LLM. This separation is intentional. The cost of a wrong finding (telling an operator they have an exposure when they do not, or vice versa) is high enough to undermine the whole product. ERNIE's job is voice, not truth.

The most impressive feature MeDo helped produce

The takedown letter drafting workflow. When the audit detects a brand impersonation, the operator clicks one button and ERNIE drafts the platform‑appropriate report message, completed with the operator's brand name, the impersonating handle or domain, and the apparent date of impersonation, in the calm professional voice that trust and safety teams respond to fastest. The draft is editable in place before sending, and the send action is a copy‑and‑paste handoff to the operator's email or the platform's report form, rather than an automated submission, because automated submissions risk false positives and platform retaliation against the operator's legitimate account.

What makes this feature impressive in MeDo specifically is the combination it required, namely a real impersonation discovery plugin generating typosquat candidates and checking them against live DNS, a structured finding object propagating through the orchestrator, a separate ERNIE system prompt with platform‑specific reporting conventions, a modal interface with copy‑to‑clipboard, and persistence to the takedown_drafts table for replay on the saved‑report return page. MeDo produced all of that across a few focused turns, and the resulting feature feels like a polished product feature rather than a hackathon proof of concept.

Challenges I ran into

The biggest challenge was that the build looked complete from the outside well before it actually was. Early audits returned exactly one finding regardless of the input domain, and the temptation was to ship and call it done. A diagnostic turn (asking MeDo to print the plugin outputs and orchestrator logic for a recent audit) revealed something different from what I had assumed. The plugins worked, ERNIE worked, but four orchestrator bugs prevented three of the five pillars from working correctly. Three of the bugs were data shape mismatches between what the plugins returned and what the orchestrator read, and one was a hardcoded fake finding on the storefront privacy pillar. The lesson was that "deployed and operational" is not the same as "returning meaningful output." Every claim that a feature worked needed verification against real plugin output, and that verification was faster than rework. A second challenge was the voice. ERNIE is primarily trained on Chinese‑language data, and producing the calm older‑sibling register in English required several iterations on the system prompt, including three positive examples and three negative examples in the prompt itself, before the output stabilized. The investment paid off, but the iteration cycles were a real consumer of build time.

A third challenge was scope discipline. Sole‑proprietor cybersecurity is a deep problem space and the temptation to add a sixth pillar, a seventh, an eighth, was constant. I held the line at five pillars because the value of the product is that the operator can complete the full audit and the recommended actions in under thirty minutes, and a longer report would defeat the purpose.

Accomplishments I'm proud of

The voice. Every line of copy in HearthGuard, from the form labels to the severity headers to the recommended actions to the takedown letters to the error messages, follows a single rule. Write the way a calm older sibling explains a problem to someone they love. The voice is the product as much as the audit is, and it is what distinguishes HearthGuard from every other cybersecurity tool the audience has ever encountered.

The other accomplishment I am proud of is the discipline of keeping ERNIE away from the audit logic. The temptation in a hackathon is to put an LLM in charge of everything, because LLMs are impressive and they make for good demos. HearthGuard treats the LLM as a voice layer over a deterministic audit. Findings are produced by hard rules over real plugin output. ERNIE writes them up. That separation is what makes the audit trustworthy.

What I learned

Two specific things stand out. The first is the value of structured prompting over conversational prompting. The opening MeDo prompt was roughly two thousand words long, with explicit numbered sections for each piece of context. That structure produced dramatically cleaner generation than I would have gotten by chatting features into existence one at a time. The second is the value of diagnostic discipline. Before fixing anything I thought was broken, I asked the platform to tell me exactly what was happening. Most of the time, the truth was different from what I assumed, and the diagnostic was faster than the guess.

A third, smaller thing. The audience drives every design decision. Every time I had to choose between two implementations, I asked which one Maya, the persona at the center of the brief, would actually use at nine‑thirty at night between dinner and her kids' bedtime. That single question resolved most of the design debates faster than any other heuristic.

What's next for HearthGuard

The thirty‑day roadmap focuses on retention, namely tightening the diff feature on return audits, adding the monthly reminder email properly, and instrumenting the funnel from first audit to saved report. The ninety‑day roadmap adds two more pillars, one for payment processor account hygiene (Stripe and PayPal) and one for storefront platform hygiene (Etsy, Shopify, Gumroad). The six‑month exploration is whether HearthGuard becomes a standalone small‑business product priced in the five‑to‑fifteen dollar per month range, or a feature inside a larger platform (a small‑business banking provider, a payments platform, a small‑business insurer) that wants to differentiate on care rather than price. Both paths are real outcomes.

The product is not a venture‑scale business, and pretending otherwise would undermine the credibility of the work. It is a useful, defensible small business of its own, built for an audience that has been ignored by the cybersecurity tools market for a long time. That is enough.

Built with The application was built end to end on MeDo, using its full‑stack code generation, multi‑turn iteration, plugin integration, one‑click deployment, and ERNIE Bot integration. The four external services wired through MeDo's plugin layer are live DNS queries for transport and email authentication checks, the Have I Been Pwned API for breach exposure, Cloudflare DNS‑over‑HTTPS for impersonation discovery, and direct HTTP fetches for storefront and privacy policy retrieval. Baidu's ERNIE Bot powers the two generative features, namely the finding rewrite and the takedown letter drafting.

Built With

• ai
• and-direct-http-fetches-for-storefront-and-privacy-policy-retrieval.-baidu's-ernie-bot-powers-the-two-generative-features
• and-ernie-bot-integration.-the-four-external-services-wired-through-medo's-plugin-layer-are-live-dns-queries-for-transport-and-email-authentication-checks
• baidu-ai-studio
• cloudflare
• cloudflare-dns?over?https-for-impersonation-discovery
• cybersecurity
• dns
• dns-over-https
• edge-functions
• ernie-bot
• generative-ai
• haveibeenpwned
• http
• javascript
• json
• llm
• medo
• multi?turn-iteration
• natural-language-processing
• one?click-deployment
• plugin-integration
• rest-api
• the-have-i-been-pwned-api-for-breach-exposure
• typescript
• using-its-full?stack-code-generation