DEV Community: visiohex

Why I Kept My AI Video Tool to One Scene

visiohex — Sun, 11 Oct 2026 12:27:00 +0000

I built Bulin 47 AI, a small browser tool that takes one portrait and makes a version of the Bulin 47 freestyle clip.

The result is a 10-second vertical video. The portrait guides the main rapper’s appearance, while a fixed reference video guides the performance and surrounding scene. The reference soundtrack is included.

The main product decision was to keep it to that one scene.

Deciding what the user actually needs to choose

A general video generator needs room for prompts, model selection, reference footage, duration and output settings. For this particular clip, most of those choices can be made ahead of time.

I’ve already prepared the reference clip, prompt and audio. The person using the site mainly needs to decide who should appear in the video.

That makes the upload form smaller, but it also sets a clear boundary. The tool doesn’t offer custom choreography or a library of different performances. If you want a different scene, this isn’t the right tool for it.

The photo and video reference have separate jobs. A clear portrait helps with appearance; the reference supplies the movement. There’s no need to record yourself performing or upload a full-body shot.

A small form still needs to explain the result

The flow is straightforward: watch the reference, sign in with Google, upload a portrait and submit a generation. You can follow its progress in My videos, then download the finished MP4.

The output is fixed at 720p, 10 seconds and a 9:16 aspect ratio. Those details belong near the upload form, because they affect whether the result will work for someone’s intended use.

There are less tidy details to explain too. A face can look convincing in the first frame and change when the person turns. Hands and timing need checking. The model creates new frames, so appearance and motion can vary between generations.

A completed job doesn’t necessarily mean the person will like the result. That matters when explaining credits: confirmed failed generations return the credit, while a completed video with an unsatisfying likeness is a different situation.

Keeping the examples honest

The homepage includes the reference and trend examples so people can see the scene before paying. Those gallery clips come from outside creators, are credited on the site and weren’t generated by this service.

That distinction needs to be visible. A reference clip shows what the tool is aiming for; it doesn’t prove what every generation will look like.

Making a video requires a paid credit. There are no free generations at the moment. Credits are sold in one-time packs, with no subscription or automatic renewal. The current options are on the pricing page.

A few limits worth stating upfront

Photos are kept for up to seven days and finished videos for 30 days. Download any result you want to keep. Get permission before using someone else’s portrait, and label shared clips as AI-generated.

Keeping the scope small gives me a specific workflow to improve: one portrait, one scene, one downloadable result. I’m interested in whether that constraint makes the process easier to understand, and where the form still leaves people guessing.

You can see it at bulin47.online. If you take a look, I’d appreciate feedback on the upload flow and how clearly it explains what you’ll get.

AI Raindance: make a 15-second music video from one or two portraits

visiohex — Sun, 11 Oct 2026 04:21:33 +0000

I built AI Raindance, a web app that puts people from your photos into a short video inspired by Dave and Tems' Raindance music video.

You choose who appears in the scene. The app supplies the reference, the waterfront setting and the original audio. There's no prompt to write: upload one or two portraits, choose the roles, and generate a 15-second MP4.

Here's how it works, and what to check before spending a video credit.

Start with the cast

There are two modes:

Mode	Photos	Who appears
Solo	One portrait	The person in your photo becomes the singer; the companion is removed.
Duo	Two separate portraits	Photo 1 is the companion, and photo 2 is the singer.

For Duo, you don't need a picture of both people together. Use a separate portrait for each person. If you've put the singer in the first slot, use Swap roles before generating.

Both modes cost one video credit. Adding a second person doesn't cost extra.

Choose a photo where the face is easy to see

A front-facing portrait or a slight angle is a good starting point. Keep the face large enough to see clearly, with even lighting and no sunglasses or heavy filters. Group shots and faces far from the camera are harder to work with.

The app accepts JPEG, PNG and WebP files, up to 10 MB per photo. Use your own photos, or photos you have permission to use with the subject's consent.

Sign in before selecting them. The uploaded photos aren't saved as an unfinished draft, so leaving the page before submitting can lose your selection.

Make and download the video

Sign in with Google. If your balance is empty, buy a one-time video pack.
Choose Solo or Duo, add your portraits and check the role labels.
Click Generate to submit the task and use one credit.
Open My videos to follow its progress, play the result and download the MP4.

Once you've submitted the task, you can close the page. Return with the same Google account to find it again. You don't need to keep a browser tab open throughout generation.

The finished video is 15 seconds, 768P, in a 4:3 frame, with the original reference audio included. Your portrait changes the person on screen; it doesn't turn your voice into the song.

Watch the whole clip before sharing it. Facial details, expressions and singing timing can vary between AI results.

Look at the sample before buying

The examples page separates the original reference footage from a generated Solo sample.

That sample is a short 4.5-second clip made from a fictional AI portrait, with its model-generated soundtrack. It isn't a full preview of a purchased video. Purchased videos use the fixed 15-second template and original Raindance audio.

The template is deliberately specific: you can choose the portraits and roles, but you can't change the song, scene or duration.

Cost and file storage

Generation is paid. The current packs are $9.99 for one video, $24.99 for three, or $69.99 for ten. There is no subscription, and purchased credits don't expire. If a task is confirmed as failed, its credit is returned automatically.

Photos are kept for seven days and finished videos for thirty days. Download the MP4 while it's available. Uploads and finished videos stay in your account; they aren't automatically added to the public examples page.

AI Raindance is an independent project, with no affiliation with Dave or Tems.

You can try the flow at airaindance.online. I'd welcome feedback on the Solo/Duo controls, especially whether the companion and singer roles are clear before you upload.

I built a one-photo Burning Bridges video generator

visiohex — Sun, 11 Oct 2026 03:59:51 +0000

I built Drake Burning Bridges AI, a small web app that takes one portrait and generates a personal version of the Burning Bridges party scene.

You choose the main character with your photo. I’ve configured the video reference and prompt, so you don’t have to write scene instructions. The output is a 20-second, 720p, landscape MP4 with the supplied soundtrack.

For this post, I wanted to share the implementation choices behind that short upload flow.

Keeping the input small

The studio accepts one portrait. The photo provides the appearance reference for the main subject; the video reference guides the party setting, gestures and camera movement.

I kept the scene and output settings fixed. Users can choose who appears in the foreground, but they can’t cast each guest or change the duration. That limits what you can make, and it gives the upload page a clear job: help you choose a usable photo and understand the expected result.

The server checks file size, image type and dimensions. A file extension or a browser-provided MIME type alone isn’t enough to validate an upload.

The stack

I’m using React and TanStack Start for the app, with Better Auth for authentication. The application runs on Cloudflare Workers. I store task and credit records in D1, and uploaded photos and finished videos in R2.

The app calls an external video generation service. Workers handle the application flow rather than running video inference themselves.

Treating generation as a saved job

A video request needs to survive the user leaving the page. I store the job before processing it and track its progress through these states:

queued → processing → composing → saving → succeeded

The composition step adds the supplied soundtrack. I mark a task as successful after saving the finished video, rather than when the generation provider first reports success.

Users can return to My videos to check an existing task. The browser doesn’t have to stay open for the whole operation.

Handling retries and credits

Each generation uses one credit. I use a request ID to connect a submission to its job. If the same user sends the same request again, the application returns the existing job. Reusing that ID with different input is rejected.

In the database, I connect job creation to the credit debit with a trigger. If the debit can’t complete, the job insert rolls back. I also give failed-job credit returns a unique ledger reference, so processing the same failure again doesn’t add another credit.

The less obvious case is a timeout while submitting to the video provider. The provider might have accepted the job even though my application didn’t receive its response. Submitting a fresh request at that point could create a second paid generation.

I record that submission attempt and keep an uncertain outcome for reconciliation. A confirmed failure returns the credit; a missing response needs more investigation. This leaves some cases requiring support review, but avoids treating an unknown result as permission to submit again.

Setting expectations for the video

AI can change facial details or hands as the person moves. A completed job means the user received a video, not that the model preserved their appearance in every frame.

I’ve included examples so visitors can inspect the intended scene. Those are supplied 480p samples, not evidence of a paid generation through the app. The configured output is 720p.

The site is an independent project with no affiliation with Drake. Users should upload photos they have permission to use, with the subject’s consent.

You can see the project at drakeburningbridgesai.video. I’d welcome feedback on the upload flow, or how you handle uncertain provider responses in apps that charge per task.

I built AI Zombie: two photos, a 15-second zombie love story

visiohex — Sun, 11 Oct 2026 03:55:02 +0000

I built AI Zombie, a web app that turns two photos into a 15-second zombie love story with sound.

The story starts with a survivor facing someone they care about who has become a zombie. Instead of shooting, the survivor lowers the weapon and opens their arms. The zombie approaches, they embrace, and the scene cuts to a warm memory of them together.

You can use photos of two people, or make your dog or cat the zombie and keep yourself as the human survivor.

How it works

Upload a photo of the person or pet who becomes the zombie.
Upload a photo of the human survivor.
Choose a cabin, city, or chapel setting, and a portrait or landscape format.
Start the generation, then watch and download the finished video from My videos.

The output is a 15-second, 720p MP4 with audio. The homepage includes example videos if you want to see the style before creating one. Generation uses paid video credits.

Giving the model a specific story

I kept the generator focused on one short narrative. You choose the characters and setting; the app supplies the sequence of shots.

In the implementation, I build the video prompt around timed story beats: recognition, the survivor's decision, the approach, the embrace, and the memory. The transition is the part I care about most. I ask the model to keep the characters in the same positions across the cut, so the embrace connects the present to the memory.

The pet version needs different instructions. I ask for a natural four-legged trot and a short jump that fits the animal's size. The prompt also specifies that the model should preserve the pet's markings and species rather than give it human limbs or gestures.

These are instructions to the model, rather than guarantees. Faces, motion, and sound can vary between generations, and the model may miss a detail in the intended sequence.

A few implementation details

I built the app with TanStack Start and React, running on Cloudflare Workers. I use D1 for generation records and R2 for media storage. The video generation itself runs through an external API.

A generation takes longer than a normal page request, so I store it as a job. The UI shows its status while the backend handles submission and completion. Users can return to their video history to find the result.

I also use a request ID to handle repeated submissions. If a user retries the same request, the backend returns the existing job instead of creating another one. That matters when each generation consumes a paid credit.

I'd like your feedback

You can see the examples and try the generator at aizombie.online.

I'm interested in whether the story makes sense when you watch it, and whether the upload flow makes the two character roles clear. If you're building an image-to-video app, I'd also like to hear how you handle continuity between shots.

PhotoCraft Online: trying an open-source image editor in the browser

visiohex — Sat, 10 Oct 2026 10:05:31 +0000

I put together PhotoCraft Online as a place to try PhotoCraft in a browser and read through a few editing guides. You can open the editor without installing an application or creating an account. Basic editing is free.

The editor itself comes from storytold/photocraft. The upstream team and contributors built it; I host the web build and maintain the surrounding website. PhotoCraft Online is an independent site, and the version hosted here is v0.5.0.

For this post, I want to show the small checks behind the guides. A feature list gives you less to go on than an image that was opened, changed, and exported.

Starting with a small PNG

The first test used a 640 × 400 PNG: a cream background with an amber rectangle. It is a boring image on purpose. There are few places for an editing mistake to hide.

In the browser build, the check covered adding English text, undo and redo, cropping, and a brightness adjustment. The PNG export downloaded and displayed the edited image. These checks ran on macOS in Chromium with a 1280 × 720 viewport.

If you have used a layered image editor, you will recognize the arrangement: tools on the left, the document in the middle, and layers on the right. For a first try, open a copy of an image, add a short line of text, then download a PNG and open it outside the editor.

One detail matters at export time. The PNG download is a flattened image. You can use it as the finished picture, but you cannot reopen that PNG and expect to recover the text layer.

A PSD check that needed a correction

The next sample was a synthetic PSD with two raster layers named Background and Amber card.

Both layers appeared in the editor, and the visibility controls worked. The initial stacking order differed from the PSD's embedded composite, though: the background covered the amber rectangle. Moving Amber card above Background restored the expected view.

That is a useful result, with a limit. The check established that this sample could be opened and its layers manipulated. It did not establish why the initial order differed. The sample encoding and the importer both need investigation. Saving the PSD and reopening it was outside this test.

I would check my own file before relying on it for a handoff. In particular, these small samples tell us little about a document with smart objects, masks, or fonts that the browser cannot find. I have put the test details and the relevant upstream documentation in the PSD compatibility guide.

Save before you close the tab

The editor processes the images you open in the browser. PhotoCraft Online does not provide cloud document storage, so download your work before reloading or closing the tab. Keep the original file as well.

The website has English and Chinese guides. That refers to the site and its articles; I have not verified Chinese text rendering inside the editor. PhotoCraft remains in early alpha, and the upstream developers warn against treating it as a replacement for daily professional Photoshop work.

You can open the editor here. The tutorial follows a small editing workflow if you want somewhere to start.

If you try a PSD and something looks wrong, a useful report includes the browser, document dimensions, layer count, and the change you expected to see. That gives me something concrete to reproduce without asking you to share the original file.

I built CompressGIF: local GIF compression, plus REST and MCP APIs

visiohex — Sat, 03 Oct 2026 03:12:44 +0000

A GIF can be useful in a README, bug report, or product demo—and still be too large to attach. Getting it below an upload limit often means trying compression settings, checking the animation, and trying again.

I’m sharing CompressGIF, a tool I built for that workflow. It has a browser compressor for local files and a separate cloud API for automation.

Start with the browser tool

The free browser tool processes your GIF on your device without uploading the file for compression. It keeps the output as an animated GIF and adds no watermark.

There are three modes:

Quality first: start with conservative compression and inspect the result.
Size first: try stronger palette and lossy settings when a smaller file matters more than fine detail.
Target size: try to get under a specific limit, with free presets for 100KB, 512KB, and 1MB.

Free usage supports three files per batch, up to 10MB per file. Pro adds larger batches, custom target sizes, and ZIP downloads.

A target is a goal, not a guarantee

CompressGIF uses Gifsicle. The useful tradeoff depends on the content: small UI text, flat illustrations, and video-like animations do not respond to compression in the same way.

By default, the tool preserves dimensions, animation duration, and loop behavior rather than silently dropping motion frames or resizing. Resizing is an explicit choice.

If a target cannot be reached, the tool says so. It keeps the smallest valid candidate, including the original when compression cannot improve it. I’d rather show a missed target than imply that every GIF can become 100KB without a visible tradeoff.

When checking a result, look beyond the byte count: inspect text, gradients, transparent edges, and playback timing.

Automate it with REST

For scripts and integrations, there is an asynchronous compression API. Unlike the browser tool, this is cloud processing: you upload a file or provide a public HTTPS GIF URL.

Here is an upload request targeting 1MB (1,000,000 bytes):

curl -X POST https://compressgif.net/api/v1/compressions \
  -H "Authorization: Bearer $COMPRESSGIF_API_KEY" \
  -H "Idempotency-Key: demo-upload-001" \
  -F "file=@animation.gif" \
  -F 'options={"mode":"target","targetBytes":1000000}'

Keep the API key in a protected environment variable, not client-side code. Use a new idempotency key for each new file-and-options request, and reuse that key when retrying the same request after an uncertain response.

The response includes a top-level job id. Poll GET /api/v1/compressions/{id} every few seconds. Once the status is succeeded, read result.downloadUrl and check targetMet. A completed job can still miss the requested size. Stop polling on failed or canceled and inspect the error.

Or connect an MCP client

The Streamable HTTP endpoint at https://compressgif.net/api/mcp exposes three tools:

compress_gif
get_compression
get_usage

It uses the same API key and credit pool as REST. MCP accepts public HTTPS GIF URLs; local files should be uploaded through REST. A successful tool call starts a job—it does not mean compression has finished.

Free API access currently provides 500 credits per UTC calendar month after activation with a verified Gmail-based Google sign-in and a security check. It is subject to shared monthly compute capacity; target-size jobs cost more credits than quality/size jobs. The API documentation covers activation, limits, retention, and examples.

Privacy distinction: local browser compression keeps the GIF on your device. REST and MCP process it in the cloud, where file access expires after 24 hours. Importing a URL in the browser also contacts the image’s host.

If you work with GIFs in documentation or developer workflows, I’d appreciate feedback: which matters most to you—readable UI text, predictable file size, or batch automation?

Try CompressGIF · REST and MCP docs

PDF to Markdown: local conversion, cloud OCR, and the trade-offs

visiohex — Thu, 10 Sep 2026 13:37:43 +0000

Getting text out of a PDF is easy to demonstrate and surprisingly difficult to get right.

A document can look perfectly readable while producing broken paragraphs, scrambled columns, or a table that turns into a wall of text. Scanned PDFs add another problem: there may be no text layer to extract at all.

I'm Leo, the maker of PDF to MD. It converts documents into editable Markdown, with local browser processing for text documents and a separate cloud OCR mode for scans.

Here's how the workflow works, and where it still needs human review.

Start by distinguishing text PDFs from scans

Before choosing a conversion method, try selecting a sentence in your PDF.

If you can select individual words, the document probably has a text layer. Local extraction is a reasonable starting point, though an existing text layer doesn't guarantee correct reading order.

If each page behaves like a single image, you'll generally need OCR.

Some PDFs contain both types of pages, so it's worth checking more than the first page.

Local conversion for text documents

PDF to MD can convert text-based PDFs, DOCX files, and HTML locally in the browser, without uploading file contents.

The workflow is:

Choose your documents.
Convert them to Markdown.
Review and edit the output.
Copy the Markdown, download individual files, or export a batch as a ZIP.

Local conversion is free. It's useful when you want to turn a document into notes, documentation, or text you can work with in another tool.

For example, an Obsidian workflow is to download the .md file, place it in your vault, and add your own links and annotations. This is a file-based workflow; PDF to MD is a web app, not an Obsidian plugin.

Cloud OCR for scanned documents

Scanned PDFs and images need a different processing path.

PDF to MD offers an optional cloud OCR mode for those files. Unlike local conversion, this mode uploads the document for processing.

The distinction matters: a tool offering local processing does not mean every feature runs locally. Choose the mode based on both the document type and whether you're comfortable uploading it.

Cloud features use account quotas, with paid plans and OCR packs available for additional usage.

Markdown still needs a review step

A PDF describes a page layout. Markdown describes document structure. Converting between them involves interpretation.

These are the areas I would check before using the output:

Reading order: Do paragraphs from separate columns appear in the right sequence?
Headings: Did section titles become headings, or just isolated lines?
Tables: Are values still associated with the correct row and column?
Formulas: Are symbols and relationships preserved accurately?
Repeated content: Did page headers and footers end up inside the body?

Complex tables, formulas, and multi-column layouts can still need manual correction. Local PDF conversion also does not extract embedded images.

A Markdown file that renders successfully can still contain extraction errors. For technical or research material, compare important passages against the original.

Using the output in automated workflows

For repeated document processing, PDF to MD also provides a REST API and a remote MCP endpoint.

These offer another way to access conversion from scripts and compatible AI tools. They are separate from the free local browser workflow and use service quotas.

You can find the integration details in the developer documentation.

Whether the output goes into a notes app, documentation system, or AI workflow, checking the extracted text first is still worthwhile. A downstream tool cannot reliably recover a table whose columns were mixed up during conversion.

Try it with a document you know well

The easiest way to evaluate a converter is with a document whose contents you already understand. Start with a short text PDF, inspect the Markdown, and then try a more demanding layout.

You can try PDF to MD here. Free local conversion is available alongside optional cloud features.

I'd appreciate feedback from people moving documents into Markdown: which causes you the most cleanup work—tables, reading order, scanned pages, or something else?

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