DEV Community: visiohex

Building a private tarot calculator with Astro and zero backend

visiohex — Fri, 07 Aug 2026 08:45:06 +0000

I recently built Meu Arcano Pessoal, a tarot calculator for Brazilian Portuguese users.

The site calculates a personal Major Arcana card from a birth date, with an optional name-based method. It also includes an annual Arcana calculator, relationship compatibility readings, and pages explaining all 22 Major Arcana cards.

The subject is tarot, but the project involved familiar web development questions:

How can an interactive calculator work without a backend?
How should personal inputs be handled without collecting them?
How can one calculator grow into a useful content site?
How do you present symbolic results without making false predictions?
How much JavaScript does the site need?

I built it with Astro, TypeScript, browser APIs, and Cloudflare Pages.

Why I kept the calculation in the browser

The calculator asks for a birth date. One optional calculation method can also use a name.

Neither input needs to leave the device. A server would add complexity and create a privacy problem without improving the result.

The calculation follows this flow:

The user enters a date.
The browser validates it.
TypeScript calculates a number between 1 and 22.
The corresponding Arcana appears on the page.
The input disappears when the page closes or reloads.

The site does not place birth dates or names in URLs, localStorage, cookies, analytics events, or network requests.

There is no account system, database, API route, or serverless function to maintain.

The reduction function

The site maps a number to one of the 22 Major Arcana cards. When a total is greater than 22, the calculator adds its digits again.

export function reduceToArcano(value: number): number {
  let result = Math.abs(Math.trunc(value));

  while (result > 22) {
    result = String(result)
      .split("")
      .reduce((sum, digit) => sum + Number(digit), 0);
  }

  return result;
}

For a personal Arcana calculation, the site adds the digits in the birth date before applying the reduction:

export function calculatePersonalArcano(date: Date): number {
  const digits = [
    date.getDate(),
    date.getMonth() + 1,
    date.getFullYear(),
  ]
    .join("")
    .split("")
    .map(Number);

  const total = digits.reduce((sum, digit) => sum + digit, 0);

  return reduceToArcano(total);
}

Input validation happens before this function runs. The form rejects impossible dates and future dates instead of letting JavaScript normalize them into another day.

For example, JavaScript can turn April 31 into a date in May. The calculator should not produce a result from a date the user never entered.

Handling tarot numbering differences

Tarot decks do not all use the same numbering.

In the Rider-Waite system, Strength is number 8 and Justice is number 11. Some traditions reverse those numbers. The Fool may appear as 0, 22, or remain unnumbered.

The site uses this sequence:

8  A Força
11 A Justiça
22 O Louco

I documented this decision on the methodology page instead of hiding it inside the calculation.

Two calculators can receive the same birth date and show different card names because they use different numbering systems. The formula may be working correctly in both cases.

Adding a name-based calculation

The optional name method uses a Pythagorean letter mapping.

Before assigning values, the browser normalizes the input:

export function normalizeName(value: string): string {
  return value
    .normalize("NFD")
    .replace(/[\u0300-\u036f]/g, "")
    .replace(/ç/gi, "c")
    .replace(/[^a-z]/gi, "")
    .toUpperCase();
}

This lets names containing á, ã, ê, or ç use the same mapping as their base Latin letters.

I kept the date-only method available because asking for a full name creates friction and changes the interpretation. The interface explains what each method uses before the user chooses one.

Annual Arcana without requesting a birth year

The annual calculator needs a birth day, birth month, and target year. It does not need the user’s birth year.

Requesting the full birth date would collect an extra piece of personal information for no reason.

The calculation looks like this:

export function calculateAnnualArcano(
  day: number,
  month: number,
  year: number
): number {
  return reduceToArcano(day + month + year);
}

A person born on September 14 calculating the result for 2026 gets:

14 + 9 + 2026 = 2049
2 + 0 + 4 + 9 = 15

The result is Arcana 15.

The annual tool supports 2026 and 2027. Each result includes prompts for relationships, work, change, and one practical action. It does not claim to predict a specific event.

Compatibility without fake precision

Relationship calculators often return scores such as “87% compatible.” I did not have a defensible way to calculate that number, so this tool does not produce one.

The compatibility page calculates two individual Arcana cards and describes:

what each person may bring to the relationship;
differences in communication;
what each person may need;
likely points of friction;
a question or exercise they can try together.

Users can select love, friendship, or work as the context.

Swapping the two birth dates changes the display order but not the shared interpretation. Equal Arcana results receive a combined explanation so the page does not repeat the same paragraph twice.

One data source for 22 pages

Each Arcana lives in a typed data object:

type Arcano = {
  number: number;
  name: string;
  slug: string;
  summary: string;
  love: string;
  work: string;
  strengths: string[];
  cautions: string[];
  related: number[];
  image: string;
};

Astro uses this data to generate the 22 detail pages at build time:

export function getStaticPaths() {
  return arcanos.map((arcano) => ({
    params: {
      slug: `${arcano.number}-${arcano.slug}`,
    },
    props: {
      arcano,
    },
  }));
}

The browser downloads no card database after the page loads. Search engines and visitors receive complete HTML.

The same data powers the calculator results, card directory, related-card links, metadata, and share images. Keeping those features attached to one source prevents card names and descriptions from drifting between pages.

Generating share cards with Canvas

Users can export their result as a 1080 by 1350 image. That size works well for vertical social posts.

The browser draws the card with the Canvas API:

const canvas = document.createElement("canvas");
canvas.width = 1080;
canvas.height = 1350;

const context = canvas.getContext("2d");

if (!context) {
  throw new Error("Canvas is not available");
}

context.fillStyle = "#0c0618";
context.fillRect(0, 0, canvas.width, canvas.height);

context.fillStyle = "#ead08b";
context.font = "48px serif";
context.fillText(result.name, 80, 1100);

The complete version also loads the Arcana image and adds a short meaning.

If the browser supports file sharing, the site uses the Web Share API. Otherwise, it downloads the PNG.

The image contains the result, but no name or birth date.

Analytics without personal inputs

I use Plausible to record a few product events:

calculo_concluido
resultado_aberto
compartilhamento

Events can include fixed categories such as the tool name, selected year, relationship mode, or sharing method.

They do not include:

names;
birth dates;
Arcana numbers;
generated interpretations;
form values.

I want to know whether visitors finish a calculation and whether the sharing tool works. I do not need to know what they entered.

Static deployment on Cloudflare

Astro builds the site into static files. Cloudflare Pages serves those files behind the production domain.

The deployment has no runtime application server. Cloudflare handles HTTPS, caching, DNS, response headers, and the redirect from www to the root domain.

The site also includes:

canonical URLs;
Open Graph metadata;
robots.txt;
sitemap.xml;
breadcrumb structured data;
FAQ structured data where the questions are visible;
an llms.txt file;
a privacy policy and methodology page.

Static generation does not remove the need for JavaScript. It limits JavaScript to the places where it earns its bytes: calculators, search, result interaction, and image sharing.

The part that took longer than the calculator

The formula was a small part of the project.

Writing useful interpretations for 22 cards took longer. Each page needed to answer the searches that brought someone there, including arcano 11, arcano pessoal 17, and significado do arcano 18.

The card illustrations also needed review. A polished image can still be wrong if it misses the symbols that identify a Rider-Waite card. I checked the characters, posture, objects, animals, background elements, and card-specific composition instead of treating the images as decoration.

The methodology page became another important part of the site. It explains why calculators disagree, how names are normalized, which numbering system the site uses, and what to do when an interpretation does not fit.

Those answers help users more than another paragraph filled with broad spiritual language.

What I would build next

I plan to watch which tools people use before adding more pages.

The current site covers personal, annual, and relationship calculations. A future addition should answer a recurring user question or improve an existing result. Publishing hundreds of thin combinations would increase the page count without making the site better.

You can try the project here:

https://meuarcanopessoal.net/

The methodology and formulas are available here:

https://meuarcanopessoal.net/metodologia/

How I Built a Source-Constrained Game Guide with Astro and Cloudflare Pages

visiohex — Fri, 07 Aug 2026 08:29:17 +0000

I recently built Ball Scratch Simulator Guide, an independent information site for an upcoming Steam game from 10ft Games.

The technical work was straightforward. The difficult part was deciding what the site should say when the game has not been released and much of the information people search for does not exist yet.

Instead of filling those gaps with guesses, I built the site around a simple editorial constraint:

Every factual claim must be traceable to an official public source. Anything that has not been announced must be described as unknown.

That decision shaped the content model, page structure, SEO setup, and deployment architecture.

The problem with covering an unreleased game

Searches for an upcoming game often appear before enough information exists to support a conventional guide.

Players may already be looking for:

The release date
The price
A playable demo
Controls
VR support
System requirements
Locations
Collectibles
Achievements
Codes

For Ball Scratch Simulator, the official Steam listing currently confirms several useful details:

It is a Windows game developed by 10ft Games.
Steam lists an August 2026 release window.
Desktop play is supported.
Seated PC VR is optional through OpenXR and SteamVR.
The game includes six public locations.
Cards, Chibis, high scores, and leaderboards are part of the progression system.

Other details remain unannounced, including the exact release day, launch price, demo availability, location names, and complete controls.

The site answers those questions directly. “Not announced” is more useful than a fabricated answer hidden inside a long article.

Why I launched with one indexable page

A common SEO approach is to create a page for every possible query:

/release-date/
/codes/
/controls/
/locations/
/collectibles/
/vr/
/system-requirements/

That structure would have created several thin pages containing the same limited facts. Some pages, such as codes or walkthroughs, would have no factual basis at all.

I chose one indexable homepage that covers the current search intent in depth. It includes release information, gameplay, progression, VR support, PC requirements, languages, content warnings, and frequently asked questions.

The site also has About, Privacy, Terms, Editorial Policy, and Disclaimer pages. Those pages are useful to visitors, but they are marked noindex,follow and excluded from the sitemap.

The sitemap therefore contains one URL:

<url>
  <loc>https://ballscratchsimulator.wiki/</loc>
</url>

More pages can be added after the game launches, when there is enough verified information for each page to serve a distinct purpose.

A small Astro architecture

The site uses Astro with static output. There is no client-side application framework, CMS, database, or runtime API.

The core configuration is deliberately small:

import { defineConfig } from "astro/config";
import sitemap from "@astrojs/sitemap";

const site = "https://ballscratchsimulator.wiki";

export default defineConfig({
  site,
  output: "static",
  trailingSlash: "always",
  integrations: [
    sitemap({
      filter: (url) => url === `${site}/`,
    }),
  ],
});

Static output makes the site easy to inspect. The main content, navigation, metadata, and links are present in the generated HTML without requiring JavaScript.

Keeping game facts in one typed object

Important identity data lives in a typed object instead of being repeated across templates:

export const game: GameIdentity = {
  name: "Ball Scratch Simulator",
  steamAppId: 4951590,
  developer: "10ft Games",
  publisher: "10ft Games",
  platform: "Windows",
  releaseStatus: "Upcoming",
  releaseWindow: "August 2026",
  verifiedAt: "August 7, 2026",
  vr: {
    required: false,
    mode: "Seated",
    runtimes: ["OpenXR", "SteamVR"],
  },
};

The page copy, metadata, calls to action, and VideoGame structured data read from this object.

This reduces the chance of publishing conflicting release windows or platform information in different parts of the site. When an official detail changes, there is one primary place to update it.

Canonical URLs and structured data

Every page receives a self-referencing canonical URL:

const canonical = new URL(Astro.url.pathname, SITE_ORIGIN).href;

The shared layout also creates Open Graph metadata, Twitter card metadata, WebSite structured data, and page-specific structured data.

The homepage includes a VideoGame JSON-LD object using the same identity data shown to visitors. I avoided adding review scores, prices, release dates, or offers that are not supported by the official sources.

Structured data should describe the visible page. It should not become a second, more optimistic version of the content.

Treating official information carefully

Source-constrained publishing still requires judgment.

The Steam system requirements, for example, currently list GPU recommendations in an order that may look surprising. It would be easy to “correct” them based on an assumption.

The site displays the values as Steam currently lists them and adds a short note explaining where they came from.

That preserves the source instead of silently rewriting it.

The same rule applies to the six confirmed locations. The site can explain that six public settings are planned, but it does not invent names for those locations.

Fixing promotional-image cropping

The first version placed official promotional art inside fixed-ratio containers using object-fit: cover.

That worked visually for generic photographs, but it cropped important parts of the game artwork. Titles and characters near the edges disappeared on wider screens.

The fix was native image sizing:

.hero-art {
  display: block;
  width: 100%;
  height: auto;
  border: 1px solid var(--line);
}

Preserving the image’s intrinsic aspect ratio was better than trying to find a universal crop position.

For artwork containing text, logos, or characters, cover often solves the container’s problem by creating an image-content problem.

Deploying to Cloudflare Pages

The generated site is deployed to Cloudflare Pages through Wrangler:

npm run build
npx wrangler pages deploy dist

The custom domain is:

https://ballscratchsimulator.wiki/

The www hostname redirects to the root domain with a permanent redirect. Cloudflare also serves the site’s security headers, including a Content Security Policy.

Because the site includes Google Analytics and Plausible, their external script origins must be explicitly allowed by the CSP. Adding analytics without updating the policy would cause the browser to block the scripts.

Verification before deployment

The project uses a small verification chain:

{
  "scripts": {
    "check": "astro check",
    "test": "node --test",
    "build": "astro build",
    "verify": "npm run check && npm test && npm run build"
  }
}

The tests check practical publishing requirements:

Every planned route exists.
Each page has one H1.
The homepage has a valid canonical URL.
Structured data matches visible game information.
Trust and legal pages use noindex.
The sitemap contains only the homepage.
Internal links resolve.
Core answers remain available without JavaScript.
Draft instructions and placeholder text do not leak into public pages.
External scripts are limited to known analytics providers.

I also check the generated robots.txt, sitemap.xml, and llms.txt instead of assuming the build integration produced the expected files.

What I learned

The strongest content decision was allowing “unknown” to be a complete answer.

If the price has not been announced, the page says so. If no demo is available, it does not offer a fake download button. If location names are unavailable, it does not turn speculation into a list.

Page count should also follow available evidence. A single useful page is a better starting point than ten pages repeating the same paragraph.

Static generation made these constraints easier to enforce. The final HTML can be tested directly, and the deployed output has fewer moving parts.

The site will expand when the game is released and official information supports dedicated guides. Until then, its job is narrower: collect the confirmed details, answer current questions, and make the boundaries clear.

You can see the finished site at ballscratchsimulator.wiki.

I would be interested in feedback on the source-constrained editorial model, the Astro implementation, or the decision to keep the initial sitemap to one page.

How I Built a Source-Tracked Roblox Wiki with Astro and No Database

visiohex — Tue, 21 Jul 2026 13:16:27 +0000

I built Anime Expeditions Wiki as an independent guide for the Roblox experience Anime Expeditions.

The site helps players find current codes, compare units, plan early progression, and verify that they are joining the correct Roblox experience. It now contains 47 indexable routes across seven languages.

The technical stack is small:

Astro and TypeScript
Static deployment on Cloudflare Pages
No database
No CMS
No server functions
No public API

The harder part was handling information that changes faster than the pages around it.

The maintenance problem: uncertainty

Game guides become outdated fast. Codes expire, updates change upgrade requirements, and community tier lists often disagree.

A page can show a recent publication date while its tables still describe an older game version. Copying the newest value into a database would not solve that problem. I needed to record where each claim came from and the conditions under which it was useful.

I treated changing gameplay claims as dated evidence records.

interface EvidenceRecord {
  sourceIds: readonly string[];
  evidenceLevel: EvidenceLevel;
  verifiedAt: string;
  status: "confirmed" | "reported" | "disputed" | "unknown";
  applicableVersion: string;
}

Each record answers five questions:

Which sources support this claim?
What kind of source supplied it?
When did someone check it?
Do current sources agree?
Which game version does it describe?

The public page displays this information beside the value. Readers do not have to search a general sources page to learn whether a code or recipe comes from an official record, a community guide, or conflicting reports.

Keeping disagreements visible

The code list shows why the status field matters.

At the July 21 snapshot, the wiki tracked 15 codes. Eight had matching reports that they were active. Seven had conflicting reports.

I kept the disputed codes visible and added notes describing which sources disagreed. Choosing one answer would hide useful information. Combining several reports into a new answer would create a claim that no source published.

Tier lists have the same problem. The wiki compares three public rankings side by side instead of calculating a new score.

If one publisher does not list a unit, the table displays “Not listed.” It does not convert the missing entry into the lowest grade.

The data model allows disagreement to remain a valid state. Editors can update a record later when stronger evidence appears.

One dataset for 47 routes

Gameplay records live in TypeScript data modules. Astro components decide how to present them.

The current dataset includes:

15 tracked codes
33 units
17 traits
Evolution recipes
Five story maps
Equipment and resource records
35 source entries

The static build produces 47 indexable routes. English has 17 pages. Spanish, Brazilian Portuguese, German, French, Japanese, and Korean each have five core pages:

Homepage
Codes
Beginner guide
Tier list
Official links

All seven languages share the same gameplay records. Only interface text and explanatory copy vary by locale.

When a code changes status, I update one record instead of editing seven tables. This also prevents a translated page from keeping an older reward after the English page changes.

Astro generates canonical URLs, hreflang links, metadata, and the sitemap from the route definitions. A missing locale route fails during verification instead of producing an orphaned page.

Verifying the correct Roblox experience

Roblox uses several identifiers for one experience. Anime Expeditions has a Place ID, Universe ID, and creator Group ID.

A title search cannot prove that a result belongs to the expected creator, especially when several experiences use similar names.

The project fixes these identifiers in its configuration:

Place ID: 84515722934860
Universe ID: 7613921865
Creator: Expeditions Entertainment
Group ID: 35929511

A synchronization script checks the Place-to-Universe relationship through Roblox. It finds the matching search record, verifies the creator, and confirms that approved promotional images belong to the expected universe.

The script stops without writing when an identity field does not match.

A changed title may be a legitimate update. A different creator or Universe ID means the automation may have found the wrong experience.

The site also keeps a small whitelist of official Roblox and YouTube destinations. A data update cannot introduce an unreviewed game, group, or media URL.

Automating stable facts

A daily GitHub Actions workflow checks official Roblox metadata.

It compares stable fields with a stored snapshot:

Name
Description
Canonical path
Content maturity
Age recommendation
Creator
Place and Universe IDs

The workflow ignores player counts, vote totals, promotion state, and thumbnail URLs. Those values change often and do not justify a content update.

The identity check passes its verified search result to the snapshot step. Reusing that result avoids calling Roblox’s rate-limited search endpoint twice during one workflow run.

When stable official metadata changes, the workflow can update the snapshot and deploy the static site.

It does not rewrite tier lists, code statuses, evolution recipes, or gameplay advice.

Community information still needs review. Two guides may disagree because one tested an older server version, one misunderstood a requirement, or both copied the same incorrect source. A script cannot settle that question from the published values alone.

Automation handles identity and stable platform metadata. A human reviews gameplay claims.

Why the site stays static

Astro is the project’s only application dependency. Cloudflare Pages serves the generated files.

A database would add another moving part without improving the evidence behind the content. The dataset remains small enough to review in Git, and the site rebuilds when a record changes.

Static output also makes verification easier. The build process can inspect the HTML that will reach production.

The validator checks:

Page titles and descriptions
Canonical URLs
Alternate language links
Internal links
Source references
Structured data
Local media
Security requirements

Browser JavaScript handles a short list of enhancements, including table search, filters, code copying, mobile navigation, and analytics consent.

Readers can still access the main content when those enhancements fail.

The official trailer uses a click-to-load YouTube embed. The browser does not contact YouTube until the visitor starts the video. Google Analytics also stays unloaded until a visitor opts in.

Testing content relationships

The test suite checks content assumptions that TypeScript cannot protect on its own.

It verifies that every source ID is unique and that every citation points to an existing source. It also checks that tier comparisons cover the known unit roster without inventing grades for omitted units.

Other tests protect the update and publishing workflow:

The official Roblox identity must remain fixed.
The update check must reuse verified records.
Roblox requests must back off after rate limits.
Failed identity checks must stop without writing.
Media must stay local and attributed.
YouTube and analytics must remain inactive until requested.

The current suite contains 13 tests. The Astro build generates 48 pages, including the 404 page, and the validator checks all 47 indexable routes.

A valid TypeScript object can still cite a missing source, publish the wrong canonical domain, or send a translated page to an English URL. These checks catch those mistakes before deployment.

Limits of this approach

The static workflow makes editorial changes slower than editing a database through an admin panel. Each change passes through the repository, tests, and deployment.

That cost fits the current project. A review step helps when one incorrect value could cause players to waste limited resources.

Only five core pages have complete translations. Translating all 17 English pages would add substantial review work. Shared gameplay data prevents values from drifting, but translated explanations still need language-specific review.

The evidence model also stays small. It records the source, status, date, and applicable version without calculating a confidence percentage.

A confidence score would suggest more precision than the source material supports. Showing that two current guides disagree gives readers clearer information than assigning the claim a score of 62 percent.

What I learned

Dates and versions belong beside changing claims. A site-wide “last updated” date says little about an individual code or recipe.

Source disagreement deserves its own state. Treating conflict as an error encourages maintainers to choose an answer before they have enough evidence.

Automation works best on facts with stable identifiers and clear failure conditions. Editorial judgment needs a review boundary.

The project remains a static Astro site because its current scale does not need more infrastructure. The useful part of the system is deciding what the build should refuse to publish.

You can explore the finished project at Anime Expeditions Wiki.

Anime Expeditions Wiki is an independent fan project and is not affiliated with Roblox, Expeditions Entertainment, or any anime rights holder.

Installing Verity Mod Safely: Java vs Bedrock Setup Guide

visiohex — Tue, 21 Jul 2026 13:14:16 +0000

Most Verity Mod installation problems begin before Minecraft even launches.

A player searches for “Verity Mod,” opens the first familiar-looking result, and installs it without checking the Minecraft edition, author, Project ID, loader, or game version.

That is risky because Verity is not one interchangeable download. There is a Java project, multiple Bedrock adaptations, modpacks, and unrelated projects using similar names.

This guide provides a practical way to identify the correct project and troubleshoot it without relying on unofficial file mirrors.

Project information in this article was last checked on July 21, 2026.

What is Verity Mod?

Verity is a Minecraft horror-companion concept associated with ThatMob’s video series.

Playable adaptations introduce a yellow helper character that can answer questions, interact with the player, and eventually produce unsettling behavior or horror events.

The important detail is that the Java and Bedrock versions are separate implementations.

They do not share the same:

File format
Mod loader
Dependencies
AI configuration
World settings
Connection method
Troubleshooting steps

A Java tutorial cannot safely be applied to a Bedrock add-on simply because both projects use the name Verity.

Identify the project before installing it

A project title is not a reliable identifier. Names and readable URL slugs can be copied, reused, or changed.

Before installing anything, record these five values:

Minecraft edition
Project author
Numeric Project ID
Exact Minecraft version
Loader or import method

These values work like a package identity. If one of them differs from the tutorial you are following, assume it is a different project until proven otherwise.

Projects checked for this guide

Edition	Project	Author	Project ID	Checked release
Java	Verity JE	VarmiteYT	`1591438`	`5.7.3` for Minecraft `1.20.1` with Forge
Bedrock	Verity BE	Undertaletalelover	`1574632`	`1.0.8` for Bedrock `26.30`
Bedrock	Verity - Bedrock Edition	PnTMC	`1575941`	`2.1.0` for Bedrock `26.30`

Always recheck the project page before installing. Releases and supported Minecraft versions can change after this article is published.

Choosing Java or Bedrock

Choose Java Edition if you play Minecraft Java on a desktop computer and can create a Forge or NeoForge profile.

Choose Bedrock Edition if you play the current Minecraft release on Android, iOS, or a compatible Windows Bedrock installation.

“Minecraft PE” is now commonly used as an informal name for Minecraft Bedrock on mobile. A Java mod file cannot be imported into Minecraft Bedrock or PE.

A more detailed edition comparison is available here:

Verity Mod: Java vs Bedrock

Installing Verity JE

The checked Java project is Verity JE by VarmiteYT, Project ID 1591438.

Its current main release is Verity JE 5.7.3 for Minecraft 1.20.1 with Forge.

The project also lists a Minecraft 1.21.1 NeoForge branch, but its project description warns that this branch is deprecated and has many bugs. A higher Minecraft version number does not automatically make it the better choice.

Recommended Java setup

Create a separate Minecraft 1.20.1 profile.
Install the correct Forge version for that profile.
Launch Minecraft once before adding any mods.
Close Minecraft and add Verity JE.
Add only the dependencies listed for the selected release.
Launch the small test profile before combining Verity with a larger modpack.
Configure one supported AI option.

The project supports an online Groq configuration and a local Ollama option.

Keep API keys private. Never place a key in:

Public screenshots
GitHub repositories
Blog comments
Discord messages
Shared configuration files
Support requests

If Minecraft fails before reaching the main menu, investigate the Minecraft version, Forge version, Java runtime, and dependencies before debugging the AI configuration.

Official Java project page:

Verity JE on CurseForge

Installing Verity on Bedrock

Bedrock users must make an additional choice because there is more than one maintained adaptation.

The two projects covered here are:

Verity BE by Undertaletalelover, Project ID 1574632
Verity - Bedrock Edition by PnTMC, Project ID 1575941

They are separate projects with different releases, gameplay behavior, and support instructions.

Recommended Bedrock setup

Choose one project by author and Project ID.
Confirm that its release matches your exact Bedrock build.
Import the add-on using Minecraft’s normal import process.
Create a new test world.
Activate the required behavior and resource packs.
Enable the experimental settings required by that project.
Follow the connection and interaction instructions from the same project page.

Do not copy a connection command from one Bedrock project into the other. Do not assume that a tutorial for Project ID 1574632 also applies to Project ID 1575941.

Official Bedrock project pages:

A simple troubleshooting decision tree

When Verity does not work, identify the first stage that fails.

Minecraft does not start

Check:

Minecraft version
Forge or NeoForge version
Java runtime
Required dependencies
Conflicting mods
The profile’s actual mod directory

Test with only Verity and its required dependencies before adding other mods.

Minecraft starts, but Verity does not appear

For Java, confirm that the mod is loaded in the correct profile.

For Bedrock, check that the behavior and resource packs are active in that world. Also confirm that the add-on supports the installed Bedrock version.

Verity appears but does not respond

For Java, verify the Groq or Ollama configuration.

For Bedrock, follow the connection instructions for the exact Project ID you installed. Check required experimental options and current service notices.

Verity only displays dots

This may indicate an incomplete connection step or a temporary project service problem.

Repeatedly reinstalling the same file usually does not solve a provider or backend issue. Check the project page and its official support channel before changing unrelated settings.

The complete troubleshooting checklist is available here:

Fix Verity Mod Not Responding

Avoid unsafe and incorrect downloads

Do not select a Verity file based only on its title, thumbnail, or download count.

Before installing, verify:

Author
Project ID
Minecraft edition
Exact game version
Loader
Release date
Changelog
Required dependencies

Avoid downloading mod files from:

Shared drives
URL shorteners
Chat attachments
Repost websites
Unknown mirrors
Comments claiming to preserve a removed version

A removed project is not automatically malicious. However, an untraceable copy has no reliable source, update history, or trustworthy relationship to the original author.

The following guide links to project pages instead of hosting mod files:

Verity Mod Download Sources

Back up important worlds

Horror mods and experimental add-ons may intentionally alter normal gameplay.

Before testing Verity:

Use a separate launcher profile for Java.
Create a new test world for Bedrock.
Back up any world you care about.
Do not test experimental releases on your only copy of a world.
Add other mods gradually after the base setup works.

A clean test environment is not only safer. It also makes troubleshooting much faster.

Final checklist

Before launching Verity, confirm that:

You selected Java or Bedrock correctly.
The author matches the project you intended to install.
The numeric Project ID matches your tutorial.
The exact Minecraft version is supported.
The loader or add-on import method is correct.
Required dependencies and world settings are enabled.
API keys remain private.
Important worlds are backed up.
The file came from the project page rather than a mirror.

Most Verity installation failures can be prevented by checking identity and compatibility before downloading anything.

For maintained comparisons, setup instructions, and safety notes, visit:

Verity Mod Guide

This is an independent, unofficial guide. It is not affiliated with Mojang, Microsoft, CurseForge, ThatMob, or the developers of the referenced Verity projects.

I built Img2Gen, a GPT Image 2 studio on Cloudflare Workers

visiohex — Fri, 05 Jun 2026 04:14:57 +0000

I recently built Img2Gen, a focused web studio for GPT Image 2 generation.

The idea was simple: I wanted something more practical than a single prompt box. For real creative work, I often need to try multiple aspect ratios, upload reference images, generate several variants, download the results, and keep a history of what worked.

So Img2Gen supports:

Text-to-image generation
Reference-image edits with up to 5 uploaded images
1, 2, or 4 outputs per request
Multiple aspect ratios
Low, medium, and high quality modes
Daily free generations
Credit-based paid usage
Generation history and downloads
Automatic refunds when a generation fails

The Stack

The app is built with:

TanStack Start
React 19
Cloudflare Workers
Cloudflare D1 with Drizzle ORM
Cloudflare R2 for generated image storage
Better Auth
Stripe / Creem for payments
A server-side GPT Image 2 generation provider

I wanted the whole thing to run close to the edge, avoid a traditional server, and keep the architecture small enough that I could iterate quickly.

Why Cloudflare Workers?

Image generation itself is slow compared with a normal web request, so the main app has to handle queued jobs, polling, persistence, and failures cleanly.

The flow looks roughly like this:

User submits a prompt and optional reference images
The server validates the request and checks moderation
Free daily usage or credits are reserved
A generation job is submitted to the provider
The client polls for status
Successful images are downloaded, moderated, and persisted to R2
The generation record is saved in D1
Credits are refunded if the job fails

The hardest part was not the UI. It was making the generation workflow feel reliable when the underlying job can take a while or fail halfway through.

Credit Handling

I ended up using a credit model because image quality and output count change the cost.

Currently:

Low quality: 1 credit per image
Medium quality: 4 credits per image
High quality: 16 credits per image

Free users get daily generations, and paid users can use monthly credits or credit packs.

One small detail I cared about: failed generations should not silently burn credits. If a job fails after credits are reserved, the system refunds them automatically.

Reference Images

Reference-image editing was one of the main reasons I built this.

Img2Gen accepts PNG, JPG, and WebP references, up to 5 images per request. This makes it useful for product shots, ad creatives, portraits, style exploration, and iterative edits where you want the output to stay anchored to existing visuals.

What I Learned

A few takeaways from building it:

AI image apps need good job recovery, not just good prompts.
Credit systems need to be boring and predictable.
Storing generated outputs matters because provider URLs are not always a long-term product experience.
A focused workflow can be more useful than exposing every possible model setting.
Edge/serverless architectures work well here, but long-running generation flows need careful state design.

Try It

You can try it here:

https://img2gen.com

I would love feedback from other builders, especially on:

Whether the generation flow feels clear
Whether the credit model is understandable
What reference-image workflows you would expect from a tool like this
Any architecture suggestions for long-running AI generation jobs on serverless platforms

I built a browser-only tool to remove visible Gemini watermarks

visiohex — Sat, 18 Apr 2026 14:13:22 +0000

I built a small tool called WatermarkZero to handle one specific case: the visible Gemini watermark that shows up in the bottom-right corner of supported Gemini-generated images.

Site: https://watermarkzero.org/

Repo: https://github.com/liuyan-wjy/watermarkzero

Most tools I found went in one of three directions:

they cropped the corner
they pushed the file through a remote server
they were vague about what they actually supported

I wanted something narrower and more explicit.

What WatermarkZero does

WatermarkZero runs in the browser and focuses on the visible Gemini mark only. You upload a JPG, PNG, or WebP image, preview the result, and download the cleaned version without sending the file to a backend.

That constraint shaped the whole project. I was not trying to build a general watermark remover. I wanted a tool with a clear boundary and a workflow that people could understand in a few seconds.

Why local processing mattered

Image tools often ask you to upload files before they explain anything. That works for some use cases, but it feels wrong for screenshots, drafts, or personal images that you do not want sitting on a third-party server.

So I kept the core flow local:

image selection happens in the browser
processing happens in the browser
downloading happens in the browser

That also forced me to keep the UX honest. If the restoration is weak on a certain image, you see it right away.

Scope matters more than hype

One thing I tried to avoid was pretending this works on everything.

WatermarkZero is built for:

the visible Gemini watermark
supported Gemini-generated images
cases where you want to keep the full frame instead of cropping the corner

It is not built for:

hidden watermarking systems like SynthID
every kind of logo or watermark on the internet
guaranteed success on every textured corner or gradient-heavy image

That narrower scope made the product better. It also made the copy easier to write, because I did not have to blur the edges.

What I shipped

The current version includes:

local browser processing
before/after examples
downloadable output
support for JPG, PNG, and WebP
a few support pages that explain how it works and where it fails

I also spent time on the boring parts:

mobile layout
simple analytics
Cloudflare deployment
clear FAQ and privacy pages

The harder cases

The hardest inputs are the ones you would expect:

fabric folds
leaves and plant textures
soft gradients
detailed corners where the visible mark overlaps real image detail

Those cases are useful because they tell you whether the result looks restored or just blurred over.

If you want to try it

The tool is here:

https://watermarkzero.org/

If you test it, I would love to hear where it breaks down. Failure cases are more useful than generic praise on a tool this narrow.

I built a spoiler-safe NYT Connections helper with Astro and Cloudflare

visiohex — Tue, 14 Apr 2026 09:14:09 +0000

I recently built Connections Hint Today, a spoiler-safe helper for NYT Connections.

The original idea was pretty simple: most Connections helper pages solve the wrong problem.

They are useful if you want the answer right now, but a lot of them jump straight to spoilers. That works for panic-click traffic, but it does not feel great if you still want to solve the board yourself. I wanted something that behaved more like a coach than an answer dump.

So I built a small site around that idea:

light hints first
stronger hints only if needed
archive pages for review
Sports Edition support
short explanation and trap notes for each group

The site is live here:

https://connections-hint.today/

And the repo is here:

https://github.com/liuyan-wjy/connections-coach

The product idea

The most important product decision was to treat “help” and “spoiler” as two different things.

If you play Connections regularly, you usually do not want a giant answer page. You want a nudge. Maybe you are stuck between two groupings. Maybe you know one category is structural but cannot see it yet. Maybe the purple group is clearly some kind of phrase pattern, but you are not sure which one.

That is a very different user need from “just show me the answer”.

So the site uses a layered model:

Light hint
Medium hint
Strong hint
Reveal answer and explanation

That sounds small, but it changes the whole tone of the product. Once I committed to that, the rest of the site became easier to shape: archive pages, strategy pages, and even the result analyzer all needed to support the same idea of helping without flattening the puzzle.

Why Astro + Cloudflare

This project is a pretty good fit for the Astro + Cloudflare stack.

I wanted:

static-first pages for SEO
fast page loads
simple deployment
low ops overhead
enough server-side logic to ingest and publish daily puzzle data automatically

Astro gave me a clean content-heavy frontend without dragging in a lot of complexity. Cloudflare gave me a surprisingly compact deployment model:

Cloudflare Pages for the site
Workers for the ingest pipeline
D1 for puzzle storage
Browser Rendering as a fallback for dynamic Sports Edition capture

That combination let me keep the public site lightweight while still handling the scheduled automation behind the scenes.

The ingestion problem

The most interesting part of the project turned out not to be the UI. It was the ingest pipeline.

The main Connections board and the Sports Edition do not behave the same way. The main edition was fairly straightforward once I found the right live daily endpoint. Sports was messier.

At first, I tried to capture Sports data through browser automation. That worked some of the time, but it was not stable enough for a daily publishing flow. The browser connection would occasionally time out, which is exactly the kind of failure you do not want in a project that is supposed to update on its own every day.

The fix was to change the ingestion strategy:

use a direct GraphQL request first
keep browser capture only as fallback
write both main and sports puzzles into D1
mark them as published only when the payload is valid

Once that was in place, daily publishing became much more reliable.

Rule-based copy generation

Another interesting challenge was content generation.

I did not want every puzzle page to say the same thing with a new date stamped on it. At the same time, I also did not want to rely on live AI generation for every daily update. That would increase cost, add latency, and make the output less predictable.

So I built a rule-based copy layer instead.

Right now the generation works more like a lightweight editorial engine:

detect whether a group is direct, structural, phrase-based, or sports-specific
generate different hint and explanation styles based on that category shape
vary summary copy by puzzle type
keep the tone consistent across the site

It is not trying to imitate a human writer perfectly. It is trying to be useful, stable, and a little less repetitive than a pure template system.

That tradeoff feels right for this stage of the project.

SEO and information architecture

Because this is a search-heavy product, structure mattered a lot from the start.

I did not want the site to be just a single /today page. That would make it too dependent on one expiring keyword pattern.

Instead, I split it into a few clear surfaces:

/today for fast daily usage
/puzzle/{id} as the canonical puzzle pages
/archive for review
/sports for Sports Edition
strategy pages for evergreen traffic

I also made /today noindex,follow and pointed canonical to the actual puzzle detail page. That gave the site a cleaner search shape and reduced duplication risk.

What I learned

A few things stood out while building this:

1. The real product is not the answer page

The answer page gets the initial traffic, but the real product is the habit loop around it.

If someone comes back for archive review, strategy pages, or Sports Edition, that is much more valuable than a one-time click for today’s board.

2. Small automation details matter more than flashy features

The site became meaningfully better once the daily ingest was reliable. That mattered more than adding another feature.

3. Distribution rules matter

Communities that seem like an obvious fit are not always friendly to direct links. Some puzzle communities treat any link to a current-board helper as a spoiler, even if the page is intentionally spoiler-safe.

That means the product and the distribution strategy have to be designed together.

4. AI is optional

A lot of projects like this immediately jump to “just use AI for the content”. I think that is often the wrong first move.

For this project, deterministic rules got me much farther than I expected. They are cheaper, easier to test, and easier to reason about when something goes wrong.

What is next

The next things I want to improve are:

better puzzle-specific commentary
more evergreen strategy content
stronger archive depth
clearer post-game analysis

I also want to keep refining the copy so it feels less like a generated system and more like a compact field guide for repeat players.

If you build content-heavy side projects, I would be curious how you think about this tradeoff:

When do you keep a site deterministic, and when do you add AI into the publishing path?

What Is AutoResearch by Andrej Karpathy? A Clearer Guide for First-Time Readers

visiohex — Wed, 25 Mar 2026 08:59:55 +0000

What Is AutoResearch by Andrej Karpathy? A Clearer Guide for First-Time Readers

Karpathy's autoresearch repository has been getting a lot of attention recently.

A lot of people are searching for:

autoresearch github
karpathy autoresearch
autoresearch ai

But if you're seeing the project for the first time, the raw GitHub repository can still feel a bit dense.

So I built a small unofficial guide site to make the project easier to understand before diving into the source code.

What AutoResearch Is

At a high level, AutoResearch is an open-source project that lets AI agents run repeated ML training experiments inside a compact codebase.

Instead of manually editing everything yourself, the idea is to let an agent:

modify training logic
run short experiments
compare results
iterate

That makes it interesting not just as a repo, but as a preview of a different way to do ML experimentation.

Why People Care About It

A few things make the project stand out:

it comes from Andrej Karpathy
it is small enough to inspect
it fits into the current wave of interest around coding agents
it creates a more readable “research loop” than a giant ML stack

For developers and AI builders, it is the kind of repo that becomes popular very quickly because it is both practical and conceptually interesting.

Why I Made a Separate Guide

A GitHub README is great if you already know what you're looking for.

But many searchers are not actually asking for source code first. They are asking:

what this repo does
where to start
whether it can run on smaller hardware
whether cloud GPUs make more sense
how it differs from similarly named projects

That is why I turned it into a small explainer site.

What I Published

I broke the topic into a few pages:

Homepage / overview: Open Repo Guide
GitHub explainer: AutoResearch GitHub Guide
Step-by-step tutorial: AutoResearch Tutorial
Hardware limitations: Run AutoResearch on Mac or Smaller GPUs
Neutral infra guide: Best GPU Cloud Options for AutoResearch

What I’m Testing

This is also a small experiment for me.

I’m exploring whether a simple content site can grow by taking fast-rising GitHub repositories and turning them into clearer, more beginner-friendly explainer pages.

Not official product sites.
More like independent project guides for people discovering these repos through search.

Feedback Welcome

If you’ve looked at autoresearch, I’d love to know:

what confused you most when you first saw it
whether this kind of explainer page is actually useful
which GitHub repos would be worth covering next

I Built a Free AI Instagram Bio Generator in 10 Days — Here's What I Learned

visiohex — Wed, 18 Mar 2026 02:10:44 +0000

I spent way too long staring at a blank Instagram bio box last month. 150 characters. How hard could it be?

Turns out, pretty hard. So I built a tool to solve it.

👉 SocialBioGen — generate 3–5 personalized, emoji-packed Instagram
bios in under 3 seconds. No signup required.

## The Problem

Writing a 150-character bio that:

Captures your personality or brand
Uses emoji tastefully
Actually makes people want to follow you

...is surprisingly difficult. Most people end up with either a generic "Coffee lover ☕ | NYC" or just
leave it blank.

I searched for tools and found mostly clunky, ad-heavy generators that required email signups just to
see results. So I built my own.

## How It Works

Choose your type — Personal, Business, or Creator
Describe yourself in a few words
Pick a vibe — Professional, Funny, Aesthetic, Minimalist, Bold, or Cute
Get 3–5 ready-to-copy bios in under 3 seconds

  Input:  "Travel lover, coffee addict, based in NYC"
  Vibe:   Funny
  Type:   Personal

  Output:
  → ✈️  Fueled by coffee & flight miles | NYC chaos survivor ☕
  → Professional napper between flights 🌍 NYC base, world playground
  → Lost in every city, found in every café ☕✈️  NYC HQ

## Tech Stack

Next.js 15 (App Router) — SSR + SSG for SEO
OpenRouter API — LLM calls (GPT-4o-mini, ~$0.001/request)
Neon PostgreSQL — rate limiting + user credits
PayPal SDK — one-time payments, no subscription complexity
Vercel — zero-ops deployment

Total infra cost: < $5/month at moderate traffic.

## The SEO Play: Programmatic Pages

Beyond the main generator, I built 50+ niche landing pages:

/instagram-bio-for/travel — Travel Instagram Bio Generator
/instagram-bio-for/fitness — Fitness Instagram Bio Generator
/instagram-bio-for/photographers — ...you get the idea

Each page has 20+ pre-generated bio examples + the live AI generator. Built with
generateStaticParams() in Next.js — the entire content cost < $1 in API calls to generate upfront.

One bug I hit: revalidate = 3600 (ISR) conflicted with next-intl's setRequestLocale, throwing
a DYNAMIC_SERVER_USAGE 500 error in production. Fixed by switching to dynamic = 'force-static' —
same pattern used in the Next.js docs pages.

## Monetization

Free tier: 5 generations/day, no signup.

Paid:
| Plan | Price | Credits |
|------|-------|---------|
| Starter | $4.99 | 100 |
| Pro | $9.99 | 300 |
| Lifetime | $19.99 | Unlimited |

Credits never expire. The Lifetime deal is the anchor — once you see $9.99 vs $19.99, unlimited forever
feels obvious.

## What I'd Do Differently

Start with the SEO pages, not the generator. The pSEO landing pages will drive organic traffic long-term. I built the generator first and the SEO layer second.
Ship earlier. I spent 2 extra days polishing the UI before launch. Nobody cares about perfect spacing on day 1.
Rate limit by browser fingerprint, not just IP. Shared IPs (offices, universities) can exhaust limits for unrelated users.

## Try It

🔗 https://www.socialbiogen.net

Free to use, no signup. Would love your feedback — especially on bio quality and edge cases where the
AI gives weird results.

What's your Instagram bio right now? Drop it in the comments 👇

I Built a DLSS 5 GPU Compatibility Checker with Next.js 14 (and what I learned about AI rendering)

visiohex — Wed, 18 Mar 2026 02:09:05 +0000

NVIDIA announced DLSS 5 at GTC on March 16, 2026 — and the internet immediately exploded with questions: "Does my GPU support it? Is my RTX 4090 going to be left out?"

I couldn't find a clean, reliable answer anywhere. So I built one.

👉 dlss5.net — a free GPU compatibility checker for DLSS 5

## What is DLSS 5, actually?

This tripped me up while building the site. A lot of sources were confusing DLSS 5 with Multi Frame Generation (MFG) — but they're completely different things:

| Version | Key Feature | Focus |
|---------|-------------|-------|
| DLSS 3 | Frame Generation (1 AI frame) | Performance |
| DLSS 4 | Multi Frame Generation 4X | Performance |
| DLSS 4.5 | Dynamic MFG 6X | Performance |
| DLSS 5 | Neural Rendering | Visual Fidelity |

DLSS 5's core feature is Real-time Neural Rendering — AI analyzes scene semantics (hair, skin, fabric, lighting) and generates photoreal material responses in real time. Jensen Huang called it "the GPT moment for graphics."

It runs on top of DLSS 4.5, not instead of it.

## What I built

The tool lets you type any GPU name and instantly see:

DLSS 5 status: Confirmed / Possible / Unlikely / Not Supported
Current DLSS 4/4.5 performance data (since DLSS 5 isn't out yet)
DLSS version comparison table
Upgrade recommendations if your GPU isn't confirmed

## Tech stack

Next.js 14 (App Router, fully static)
TypeScript + Tailwind CSS + shadcn/ui
Fuse.js for fuzzy GPU name search
Recharts for FPS benchmark charts
Deployed on Vercel

The GPU data lives in a JSON file — easy to update when NVIDIA releases
official specs closer to the Fall 2026 launch.

## Interesting data decisions

RTX 5060 / 5060 Ti: I initially marked these as "Confirmed" since they're
RTX 50 series. But the GTC demo ran DLSS 5 on two RTX 5090s — one for the game,
one dedicated to the AI model. The RTX 5060 has only 8GB VRAM. I changed both
to "Unlikely" until NVIDIA publishes official minimum specs.

Min. GPU requirement: NVIDIA's official FAQ literally says "Minimum GPU
specifications are pending model optimizations and will be provided closer to release."
So the table says TBD, not "RTX 50 confirmed."

RTX 20/30 series: These support DLSS 3.5 (Super Resolution + Ray Reconstruction),
not just Super Resolution. Ray Reconstruction shipped with DLSS 3.5 and is
backwards-compatible.

## What's next

DLSS 5 launches Fall 2026. I'll update the site as NVIDIA releases:

Official minimum GPU specs
Game support list updates
Actual benchmark data

The site also has a Portuguese version (dlss5.net/pt)
— "dlss 5 quais placas" turned out to be a trending search query, so Brazilian
gamers were clearly looking for this too.

If you're a gamer wondering about your GPU, check it out: dlss5.net

Feedback welcome — especially if you spot any data errors. DLSS versioning is
genuinely confusing and I want to keep this accurate.

I Built a Free Resume Bullet Rewriter for ATS (Action Verbs for Resume)

visiohex — Wed, 04 Mar 2026 08:28:21 +0000

I recently launched PowerVerb: resumeactionverbs.com

It’s a resume bullet rewriter focused on turning weak lines into stronger, ATS-friendly resume bullets using better action verbs for resume writing.

If you’re searching for resume action verbs, power verbs for resume, or a fast way to rewrite “Responsible for…” bullets, this tool is built for that exact use case.

Why I built a resume bullet rewriter

Most tools either over-generate or produce generic text.

I wanted a practical resume action verbs tool that is:

fast
cost-efficient
less likely to hallucinate
useful for real job applications

Core features

Rewrite one bullet into 3 ATS-friendly versions
Suggest better resume action verbs by role (engineering, product, marketing, sales)
Detect weak/repetitive wording
Save and reuse recent rewrites
Daily free quota + paid credits/subscription

Tech stack

Frontend: Next.js (App Router)
DB/Auth: Supabase
Rewrite engine: Rule engine + OpenRouter fallback
Payments: PayPal (orders + subscriptions + webhook idempotency)
Deploy: Vercel
DNS/CDN: Cloudflare

Why “rule-first + AI-assisted”?

Initially, I used AI for everything. It worked, but costs and latency were unstable, and weak-verb checks were overkill for LLMs.

So I split the system:

Deterministic rules for repetition checking + weak verb detection
AI only for rewrite generation (with strict constraints)

This reduced token usage and made UX feel much faster.

Output quality guardrails

The rewrite prompt enforces:

don’t invent numbers
don’t invent responsibilities
keep original facts
return strict JSON schema

Then I post-process:

dedupe variations
enforce exactly 3 outputs
fallback to local rule rewrite when model output is invalid

This combo dramatically improved consistency.

Credits/quota logic (important lesson)

One subtle bug I fixed: deduction order.

I originally deducted paid credits first, which felt wrong for users with daily free quota.

Now the order is:

daily free quota
subscription credits
purchased credits

That single logic change removed a lot of confusion and support issues.

UX fixes that mattered more than expected

Two tiny changes improved trust a lot:

Copy button feedback (Copy -> Copied)
Reuse Output auto-scrolls back to editor and shows Loaded

Without visible feedback, users think the app is broken—even when logic works.

SEO and launch notes

I shipped:

role-based long-tail landing pages
sitemap + robots
canonical + OG metadata
favicon + structured metadata cleanup

Then submitted sitemap to Google Search Console and started testing channels like HN Show.

What I’d improve next

JD-aware rewrite mode (align bullet to job description)
batch rewrite mode
better analytics mapping (GA4 event taxonomy + funnel reporting)
export formats (DOCX/Notion/JSON)

Final thought

If you’re building an AI writing product, my biggest takeaway is:

Put deterministic logic in front of AI whenever possible.

It makes your product cheaper, faster, and easier to trust.

If you want, I can share a follow-up post with my exact event taxonomy and payment webhook idempotency setup.

How I Built an AI-Powered APA Citation Generator with Next.js, Supabase, and PayPal

visiohex — Thu, 26 Feb 2026 08:12:24 +0000

If you have ever tried to cite random web pages in APA style, you know the pain:

missing authors
missing publication dates
inconsistent metadata
lots of manual fixing after "auto generation"

I built APA Citation Generator to solve that specific workflow:

accept a URL or DOI
extract metadata with rule-first parsing
use AI only for missing fields
output APA reference + in-text citation
clearly mark confidence and review warnings

Live demo: https://apacitationgenerator.online

Why I built this

Most citation tools work great on clean sources, but fail on real-world pages. In practice, users still need to:

open the page manually
find author/date by hand
patch placeholders like (n.d.)

My goal was not "generate everything with AI".
My goal was to build a fast, reviewable citation pipeline where users can trust what is extracted and quickly fix what is uncertain.

Tech stack

Frontend/App: Next.js 16 (App Router)
DB/Auth: Supabase (custom apa schema, Google OAuth)
AI: OpenRouter (Gemini model fallback chain)
Payments: PayPal (one-time credit packs + subscription)
Deploy: Vercel
Domain/DNS: Cloudflare

Core architecture

1) Input classification

User input is classified as either:

Anything else is rejected early with explicit errors.

2) Rule-first metadata extraction

For URLs, I first parse metadata from HTML:

og:title
og:site_name
article:published_time
common author/date tags

For DOI, I query Crossref.

3) AI completion only for missing fields

If critical fields are missing, I send a trimmed text snapshot to AI and ask for strict JSON output:

authors
publicationDate
title
containerTitle

This kept latency low and reduced hallucination risk versus full-AI generation.

4) APA formatter + confidence model

The formatter creates:

full reference
in-text citation

Then a confidence score is calculated from available fields and inference flags.
Low-confidence outputs are labeled Needs Review with specific warnings.

Monetization model

I used a mixed model:

free daily quota
paid credit packs
monthly Pro subscription

This works better than a hard paywall for utility tools.
Users can test value first, then upgrade for volume.

SEO strategy (early stage)

Primary keyword: "APA Citation Generator".

Then I added related landing pages and long-tail clusters:

no author citation
no date citation
DOI to APA
in-text citation guides

I also shipped:

sitemap
robots
metadata/canonical
structured data (FAQ/Breadcrumb/SoftwareApplication)

What I had to harden before launch

After initial release, I did a security pass and fixed a few important issues:

SSRF protections on URL fetch
block localhost/internal hosts/private IP ranges
restrict ports
safe redirect handling
OAuth callback open redirect
allow only internal next paths
Edit API authorization
verify auth + ownership before updating saved citation jobs
Quota/credit race conditions
switched to compare-and-set style updates for concurrent safety
CSP + security headers
nonce-based CSP
frame/content/referrer protections
Lead form anti-bot
honeypot + timing checks + per-IP daily limit
optional Cloudflare Turnstile support

Lessons learned

Rule-first + AI fallback beats AI-only for this use case.
Explain uncertainty in UI. Users accept imperfection when they can see why.
Monetization should follow workflow friction, not just pageviews.
Security hardening early saves painful migrations later.

Current limitations

still focused on URL + DOI flows
some edge cases need manual verification (as expected in citation work)
content and internal-link SEO still improving

What’s next

better source-specific parsing heuristics
export formats (BibTeX/Word)
stronger account history and saved references UX
deeper analytics for conversion and retention

If you build in the education/productivity SEO space, I’d love feedback on two things:

Which citation edge cases break most often in your experience?
Which growth loop would you prioritize first: browser extension, exports, or team collaboration?

I’m happy to share implementation details if anyone wants to replicate this architecture.