Compare the three common choices

The local workbook is deliberately narrower: it does not sync a bank, predict local taxes or replace an accountant. In exchange, every formula is visible, the assumptions are editable and the file can be regenerated from Python.

Minimum fields that prevent surprises

Use one row per event, rather than one tab per client:

• Income: date, client, invoice status and gross amount.
• Expenses: date, category and amount.
• Setup: tax reserve rate, monthly baseline salary, opening buffer and warning runway.
• Dashboard: gross income, tax reserve, net cash, expenses, ending buffer and runway months.

For monthly totals, use a half-open interval (>= first day and < first day of next month). That keeps a payment at 23:59 on the last day in the correct month and avoids hidden time-of-day bugs.

Five-minute verification before you rely on it

1. Enter one $2,000 invoice on the 5th and one $500 expense on the 12th.
2. With a 25% tax reserve, confirm tax reserve is $500 and net invoice cash is $1,500.
3. Add a $300 expense dated in the next month; confirm only the next month changes.
4. Change the reserve to 30%; confirm the dashboard changes by $100 without editing a formula.
5. Set baseline salary to $1,000; confirm runway equals ending buffer divided by $1,000.

These checks test timing, assumptions and formula transparency. If one fails, fix the workbook before adding historical transactions.

Printable six-check smoke test

Copy this compact checklist into a note or print the page before importing historical data. It turns the five checks above into a repeatable handoff for a client, bookkeeper or future you.

• One invoice is entered with the expected date, client and gross amount.
• One current-month expense changes this month only.
• One next-month expense lands in the next month, not the current month.
• Tax reserve changes by the expected amount when the rate is edited.
• Baseline spending is editable without changing a formula.
• Runway equals ending buffer divided by the current baseline.

If any box fails, fix the workbook before adding historical transactions.

If a check fails, isolate the cause

Use the failing check to narrow the problem before changing formulas:

Save a copy of the workbook before correcting a formula. After the correction, rerun all six checks and remove the demo rows. This gives a clear before/after record without mixing test data into real cash flow.

Copyable starter rows

If you want a reproducible first run, paste these rows into the income and expenses sheets before importing real history. They are deliberately small enough to audit by eye:

sheet,date,description,amount
income,2026-11-05,Demo invoice,2000
expenses,2026-11-12,Demo current-month expense,500
expenses,2026-12-02,Demo next-month expense,300

With a 25% reserve and a $1,000 monthly baseline, the expected checks are: $500 tax reserve on the invoice, $1,500 net invoice cash, the $500 expense in November only, the $300 expense in December only, and runway based on the ending buffer divided by $1,000. Delete the demo rows after the smoke test so they cannot be mistaken for real transactions.

Reproducible starter file

The exact three-row smoke-test input is also kept as 50_devto/assets/freelance_cashflow_starter_rows.csv. Copy it into the income and expenses sheets, run the six checks, then delete the demo rows before adding real history. Keeping the CSV beside the article prevents transcription differences when a client or bookkeeper repeats the handoff.

A ready-to-use starting point

The freelancer cash-flow dashboard tutorial includes the four-sheet layout and openpyxl formulas. For a finished editable bundle, see the Budget & Bookkeeping Toolkit. You can also sanity-check allocations in the free 50/30/20 calculator.

The goal is a repeatable decision: record events, reserve tax money, pay the baseline and watch runway. A spreadsheet cannot make an uncertain invoice arrive, but it can show the gap early enough to act.

Quick decision guide

Choose the local workbook if you need to inspect every formula, keep bank credentials out of the workflow, or change the reserve rate for a specific contract. Choose Tiller if automatic transaction import is the deciding feature. Choose YNAB if guided category assignment and goal prompts matter more than an editable workbook. Choose Vertex42 if a free, general template is enough and irregular invoice timing is not the main problem.

FAQ: freelance cash-flow spreadsheets

Is this a replacement for accounting software? No. It is a small cash-flow view for timing, reserves and runway. Keep tax filings and statutory records in the system required by your accountant or jurisdiction.

Can I use it without connecting my bank? Yes. Enter invoice and expense events manually. That keeps the inputs reviewable, but it also means the result is only as complete as the entries you add.

What should I test first? Use one invoice, one current-month expense and one next-month expense. Then change the tax reserve rate. The dashboard should change only in the expected month and the runway should use the updated reserve and baseline assumptions.

Why use a half-open month (>= start and < next start)? It includes every timestamp on the first day and excludes the next month cleanly, so a late-night payment on the last day is not dropped or double-counted.

This post covers the formula logic of the four sheets: an irregular-income budget for freelancers, a snowball-vs-avalanche debt planner, a bookkeeping sheet whose P&L fills itself in, and a printable binder. You can copy the formulas into your own sheets. If you'd rather not, the finished files are linked at the end.

Status, so nobody is misled: the templates are on Gumroad. I have no sales numbers worth sharing yet, so this post is about the build, not revenue. AI tools helped me draft and double-check some formulas. I tested every sheet by hand in Excel and Google Sheets.

Where this toolkit fits (compared with the popular options)

Before choosing a template, decide whether you need bank sync or a repeatable workbook you own. Tiller is the strongest spreadsheet-first option when automatic daily bank feeds matter; YNAB is the stronger app when zero-based planning and one-tap assigning are the priority; Vertex42 is the simplest free, manual template for a general household budget. This toolkit sits between those three: no bank connection, no subscription, and more specialised sheets for irregular freelance income, debt payoff, bookkeeping P&L and print.

That positioning also sets the right expectation: this is a transparent workbook for people who want to inspect and change formulas, not an account-syncing app.

Five-minute smoke test

1. Open the free 50/30/20 sheet and replace the three sample income/expense values.
2. Open the debt planner and change one balance and APR; confirm the priority and payoff month change.
3. Open the browser calculators first if you want to test the method without downloading anything.
4. Only then decide whether the four-sheet bundle saves enough setup time for your workflow.

Why generate spreadsheets with code?

• One source of truth. Column letters, ranges and number formats come from helper functions, so a renamed sheet can't silently break a formula three tabs away.
• Big pre-built ranges. The income log has 500 formula rows and the debt schedule has 360 months. Nobody wants to drag-fill those by hand, and nobody wants to check that someone did.
• Formulas, not values. openpyxl writes formulas as strings and Excel or Google Sheets calculates them on open. Buyers get a live sheet, not a static report.

A cell is just this:

ws.cell(row=r, column=4, value=f'=IF(C{r}="","",C{r}*Setup!$B$5)').number_format = MONEY

1. Irregular income: pay yourself a fixed salary out of a buffer

Freelance income arrives in lumps. The fix is to stop treating each payment as spending money:

1. Every payment goes into a buffer (a separate account).
2. A fixed share of each payment is set aside for tax (25% by default, editable).
3. Once a month you pay yourself a baseline salary equal to your must-pay costs.
4. The buffer carries you through the lean months. Runway = buffer ÷ salary.

On the Setup tab you list your must-pay costs (rent, utilities, insurance, debt minimums, savings goal…). The salary is simply their sum:

Baseline salary  = SUM(Setup!B9:B24)

Each row in the Income Log splits a payment into tax and net:

Tax set-aside = IF(C4="", "", C4 * Setup!$B$5)
Net to buffer = IF(C4="", "", C4 - D4)

The Dashboard rolls the logs up by month with SUMIFS on a date window and carries the buffer forward:

Gross income (month) = SUMIFS('Income Log'!$C$4:$C$503,
                        'Income Log'!$A$4:$A$503, ">="&A5,
                        'Income Log'!$A$4:$A$503, "<"&EOMONTH(A5,0)+1)
Buffer balance       = previous buffer + net income - salary
Runway (months)      = IF(salary=0, "", buffer / salary)

Two conditional formats do most of the work: the buffer cell turns red when it drops below zero, and runway turns yellow under 3 months. The >= month-start and < next-month-start window also handles timestamps safely, so you never need a "month" helper column in the log. Just type the date.

2. Snowball vs avalanche in plain formulas (no macros)

The difference between the two methods is only the order in which debts get the extra money:

• Snowball: smallest balance first (quick wins).
• Avalanche: highest APR first (least interest).

Ranking without SORT(). SORT doesn't exist in older Excel, so the priority column uses COUNTIFS. A debt's rank is the number of debts that beat it, plus a tie-breaker:

Snowball  rank = COUNTIFS($B$10:$B$17,"<"&B10, $B$10:$B$17,">0") + COUNTIF($B$10:B10, B10)
Avalanche rank = COUNTIFS($C$10:$C$17,">"&C10, $B$10:$B$17,">0") + COUNTIFS($C$10:C10, C10, $B$10:B10, ">0")
Priority       = IF(N(B10)<=0, 99, IF($B$5="Avalanche", <avalanche>, <snowball>))

The running COUNTIF($B$10:B10, B10) makes two equal balances get different ranks, so no money is ever split twice.

The monthly schedule with the rollover. Each month and each debt:

owed      = last balance * (1 + APR/12)
min part  = MIN(owed, minimum payment)
left      = total monthly budget - SUM(all min parts)
ahead     = SUMPRODUCT((priority < my priority) * MAX(0, owed - min part))   ← what higher-priority debts still need
pay       = min part + MIN(owed - min part, MAX(0, left - ahead))
balance   = ROUND(MAX(0, owed - pay), 2)

The total budget stays fixed at extra + all original minimums. So when a debt hits zero, its minimum doesn't disappear. It becomes part of left and flows to the next debt in line. That is the snowball rollover, and it needs no VBA.

The Summary tab counts months with a balance above 1 cent to get the payoff date. It also flags any debt whose minimum is at or below its monthly interest (min <= balance * APR / 12), because that debt does not decline and people rarely notice. Flip the method dropdown to compare total interest for both orders on your own numbers.

3. A P&L that builds itself with SUMIFS

For the bookkeeping sheet, the rule was "one row per transaction, nothing else". Each row is a date, a description, a type (Income/Expense) and a category from a dropdown (a DataValidation list fed by the Setup tab), plus an amount.

The P&L is a grid of categories × 12 months, and each cell is a single four-condition SUMIFS:

=IF($A6="", "", SUMIFS(Transactions!$E$4:$E$2003,
      Transactions!$C$4:$C$2003, "Income",          ← type
      Transactions!$D$4:$D$2003, $A6,               ← category
      Transactions!$A$4:$A$2003, ">="&B$4,          ← month start
      Transactions!$A$4:$A$2003, "<"&EOMONTH(B$4,0)+1))

Then come totals, net profit and margin (IF(income=0,"",profit/income)), and a simple tax set-aside tab: MAX(0, monthly profit) * rate, with a running total so you can see what you should have put aside so far. It's labelled as an estimate, not tax advice.

The details that took longest:

• $A6 / B$4 mixed references, so one formula string fills the whole grid.
• The category list on the P&L is itself a formula (=IF(Setup!A9="","",Setup!A9)). Rename a category once and it updates everywhere.

4. Printables: HTML + CSS → PDF

The undated budget binder (12 pages, A4 and US Letter) isn't a spreadsheet at all. A small Python script builds an HTML document: a cover, a monthly budget, a bill tracker, savings and debt trackers, all as CSS-grid tables. Then it prints that to PDF once per paper size. CSS is much nicer than a PDF library for "a grid of boxes with rounded corners", and changing the paper size is a single argument.

Lessons I'd keep

1. Test in Google Sheets as well as Excel. Both handle SUMIFS, EOMONTH and COUNTIFS the same way. Newer functions like SORT/FILTER are where they differ, which is why I avoided them.
2. Put example data in every log. An empty dashboard full of zeros looks broken. A realistic year of sample payments shows how it works in five seconds.
3. Shade the input cells. The buyer should know exactly which cells are theirs to type in, and that everything else is formulas.
4. Write the edge-case warnings into the sheet ("minimum below interest", "runway under 3 months") instead of the README nobody reads.

Get the files

If you just want to use them:

• Free: 50/30/20 budget sheet (Google Sheets + Excel) and a 5-page large-print coloring sampler (yes, unrelated, but people keep asking for it for their parents).
• Single templates: Freelancer irregular-income budget ($12), Debt snowball vs avalanche planner ($9), Bookkeeping with automatic P&L ($15), Undated budget binder PDF ($7).
• All four: Budget & Bookkeeping Toolkit for $29 instead of $43 bought separately.

If you'd rather not download anything, the same maths runs in the browser on calc.funmagi.com: debt snowball, 50/30/20 budget and freelance rate calculators, free and with no sign-up.

Questions about any of the formulas are welcome in the comments. Not financial advice: these are templates, and you enter your own numbers.

The setup

• Input: two 800×800 photos of the same doll (#392): one full-body front shot, one close-up crop.
• Client: a small gradio_client script that sends each photo to a Space and saves the returned GLB.
• Engines:
  • trellis-community/TRELLIS with mesh_simplify 0.95 and a 1024 texture
  • tencent/Hunyuan3D-2 via its /generation_all endpoint
• Preview: each GLB rendered from 4 angles in Blender 3.0.1 (EEVEE) so I could judge the back and sides, not only the front.

from gradio_client import Client, handle_file
client = Client("trellis-community/TRELLIS")
# upload the photo, run the image-to-3D endpoint, then extract the GLB
# (endpoint names and parameters differ per Space; check "Use via API" on the Space page)

Round 1: does it even run?

The Hunyuan3D-2 failure was on the Space side, not the input. Public Spaces break from time to time. I haven't retried it yet (the /shape_generation endpoint or the Hunyuan3D-2.1 Space are the next things to try), so this is not a quality verdict on Hunyuan3D, only on that Space on that day.

Round 2: is the TRELLIS output usable?

Lesson 1: feed it a full-body, front-facing photo with the whole subject in frame. Crops and close-ups don't work.

Lesson 2: a 1024² texture and a guessed back side are fine for a preview, not for a product.

Round 3: free vs paid, side by side

To see how far free gets you, I compared a second doll (#426: green pompom, orange knit hat, black top with "Boo!" embroidery) made from the same photo with a paid Meshy production model and with TRELLIS.2, rendered with identical settings.

One practical gotcha: TRELLIS.2 stored its textures as WebP, which Blender 3.0 couldn't read. I converted them to PNG first.

My verdict

• Free TRELLIS is real and useful for previews, sample renders and triage (deciding which doll is worth spending paid credits on). In my test it succeeded 2/2 on the Space, in about 40 seconds per photo.
• It is not the final product. A wrong colour (the grey pompom) means a buyer's listing would be wrong, so finished models still go through the paid pipeline, plus a manual colour fix if I use TRELLIS.2.
• Hunyuan3D-2: 0/2 because the Space was failing that day. It's worth a retry, not a conclusion.

See a finished model

If you want to see what the paid "finished" end looks like, my #27 Teddy on Skates doll model is on Gumroad: Teddy on Skates 3D model. It's $9.99 during launch (regular $14.99).

Need 2D art instead? The Cozy Chibi Doll Character Pack on itch.io has transparent PNG characters in matching poses, pay what you want from $4.99.

Try it yourself: take one full-body front photo of a doll or plush, run it through the free TRELLIS Space, and compare your result with the Teddy model above. If your photo works, it's a free preview. If you want a finished product, grab Teddy on Skates for $9.99 while the launch price lasts.

Status, so nobody is misled: the site went public on October 31, 2026. It has 20+ theme pages and two paid bundles on Gumroad. I have no sales numbers worth sharing yet, so this post is about the build, not revenue.

What the site is

• Free single pages, no sign-up. Every page has a direct PDF download in US Letter, with A4 offered too.
• Themes people actually search for. Christmas dog, Christmas cat, Santa Paws (pets in Santa hats), reindeer pets, easy pages for toddlers and large-print pages for seniors, plus winter birds, bees and garden sets.
• Difficulty badges (Easy / Medium / Detailed), so a toddler page and an adult page aren't mixed up.
• Two optional bundles for people who don't want to click 24 times: a $2.99 Christmas Pets pack (24 pages) and a $6.99 Holiday Mega Bundle (88 pages). Both are on the bundles page.

Step 1: generate on the free tier

Images come from Cloudflare Workers AI (a FLUX.2 Klein 4B model) at 896×1152. The style prompt does most of the work:

black and white coloring book page, clean bold uniform black outlines,
pure white background, no shading, no grey, no color, no text,
large simple shapes suitable for kids and adults, full subject centered, line art: <subject>

The subject is one short line, for example "a golden retriever puppy sleeping by the fireplace with Christmas stockings". A generation takes about 10 seconds.

The rule I set early: batch content never goes to a paid model. Calls go through a small quota gate that caps this site at 30% of the daily free allocation. If the provider ever returns a quota error, the gate locks the site out for the rest of the day, so the coloring site can't starve the other projects sharing the account.

Step 2: make AI line art actually printable

Raw model output is never truly black-and-white. It has grey anti-aliasing, faint shading and the odd speckle, and on a home printer that turns into muddy lines that crayons don't cover well. The fix is five lines of OpenCV:

g = cv2.imdecode(np.frombuffer(out, np.uint8), 0)             # grayscale
g = cv2.resize(g, (g.shape[1]*2, g.shape[0]*2), interpolation=cv2.INTER_CUBIC)
g = cv2.GaussianBlur(g, (5, 5), 0)                            # kill speckles
_, b = cv2.threshold(g, 150, 255, cv2.THRESH_BINARY)          # pure 1-bit
b = cv2.erode(b, np.ones((3, 3), np.uint8), 1)                # thicken lines
cv2.imwrite(f"samples/{slug}.png", b, [cv2.IMWRITE_PNG_BILEVEL, 1])

Upscaling before thresholding keeps curves smooth. Eroding the white area thickens the black outlines, which is what makes a page feel like a "real" coloring book. The PNG is saved as true bilevel, so it's tiny and crisp.

Then Pillow places the art on a 1275×1650 canvas (US Letter at 150 dpi) with a light grey footer line, and saves a PDF and a thumbnail. Print a few pages before you trust any pipeline: the threshold and erode values above came from test prints, not from staring at a screen.

Step 3: automatic QC with one number

I log a black-pixel ratio for every page (the share of pixels that are ink). That one number catches most bad generations:

• Too low means faint, broken outlines or an empty page.
• Too high means the model ignored "no shading" and filled big black areas, which wastes ink and is no fun to color.

The fireplace puppy above came in at 0.085, comfortably in range. Out-of-range pages are flagged and never auto-published. Every candidate also lands on a daily contact sheet for a quick human look.

Step 4: a boring daily publishing loop

The Christmas queue is a TSV of 108 subjects, and the plan is two new pages a day until December 24. One script, daily.py, does it in stages:

1. gen takes the next rows and generates them (only after the daily quota resets), then runs QC.
2. approve inserts the pages into the site's YAML config, rebuilds the static site, deploys it and HTTP-checks each new URL.
3. It then pings IndexNow with the new page URLs, their theme pages and the sitemap.
4. auto chains all of this and is idempotent per day, so a cron retry can't double-publish.

The whole site is static HTML built by a Python script from one site.yaml. Adding a theme means editing YAML, not touching templates.

A Cloudflare gotcha worth knowing: if you visit a new URL before it exists, Cloudflare can cache the 404 for hours. After launch, the real page still shows "not found" to everyone. I now check new pages only with a cache-buster (/new-page/?cb=1730390000) until they are deployed.

How it (hopefully) pays for itself

Free pages are the product. The search traffic they bring has two optional upsells:

• Bundles on Gumroad. Gumroad handles checkout (card or PayPal), instant delivery and re-downloads, so I didn't build any of that myself. The license page keeps terms simple: free for personal, family, therapy-group and classroom use; no reselling or re-uploading.
• "Your pet as a coloring page." Each theme page links to PetMagi, my other project, where you upload a photo of your own cat or dog and get printable line art of your pet. Someone printing Christmas dog pages is about the best audience that feature will ever have.

What I'd do the same way again

• Free-tier generation behind a hard quota gate, never paid APIs for bulk content.
• Deterministic cleanup (threshold + erode) instead of hoping the prompt gives clean lines.
• One QC metric that a script can act on.
• Small daily releases plus IndexNow, instead of one big dump of 100 pages.

If you have kids, a classroom or a grandparent who likes large-print pages, grab a few at color.funmagi.com. New Christmas pages are added every day through December. I'd love feedback on which themes are missing.

Two kinds of AI crawlers

Training crawlers collect pages to train future models. Blocking them costs you nothing in visibility today:

Search / answer crawlers fetch pages so an assistant can quote and link them. Block these and you simply don't show up as a source:

Check each vendor's crawler docs before relying on this list; names change every few months.

Template 1: allow everything (most small sites)

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

If you sell something and want to be recommended by assistants, this is usually the right default.

Template 2: no training, yes citations

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: meta-externalagent
Disallow: /

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

OAI-SearchBot, ChatGPT-User, Claude-SearchBot and PerplexityBot fall through to User-agent: * and stay allowed.

Template 3: block all AI (and accept the trade-off)

Add the search bots from the second table to Template 2. Your pages will stop appearing as sources in AI answers.

The mistakes I see most often

1. User-agent: * + Disallow: / left over from staging. Blocks every crawler, AI or not.
2. Blocking ChatGPT-User "because it's OpenAI". That bot only fetches a page when a person asked for it.
3. Content rendered only by JavaScript. Most AI fetchers don't run JS, so even an allowed bot sees an empty page. View source (not DevTools) and check that your main text is there.
4. No sitemap line. Cheap to add, helps every crawler.
5. No /llms.txt. It's an optional, Markdown summary of your site for language models. It isn't a standard yet, but it takes five minutes to write.

Checking many sites at once

Doing this by hand for one site is fine. For a client list, I built an AI Search Readiness Audit actor: you paste URLs and get, per page, which of 14 AI crawlers robots.txt blocks (split into training vs search bots), whether /llms.txt and a sitemap exist, JSON-LD types, server-rendered word count, a 0–100 score with prioritized fixes, and a ready-to-publish llms.txt draft. It's pay-per-page, and robots/llms/sitemap fetches are free.

If you only have one site, the tables above are all you need.

More small tools from TanLabs: Social Preview & Meta Tag Checker, App Store Review Insights, App Store Top Charts & Rank Tracker.

Status, so nobody is misled: the site is live, but checkout is still in test mode while merchant onboarding finishes. The numbers below are list prices from the providers' own pages (checked October 30, 2026), not revenue.

The stack (boring on purpose)

The one rule that saved the most work: every site is a YAML file. Brand, domain, languages, theme, price tiers, model names and a daily spend cap all live there, so a new seasonal site is a copy-and-edit, not a fork.

Model costs per call (fal.ai list prices)

• Free preview – FLUX.2 Flash edit: $0.005 per megapixel of input and output. A 1 MP photo in and 1 MP preview out is about $0.01.
• HD portrait – Seedream 4.5 edit: $0.04 per image, about a minute per edit, up to 4 MP output.
• Animated clip – PixVerse v4.5 image-to-video, 5 seconds: $0.15 at 540p, $0.20 at 720p, $0.40 at 1080p.

Free previews are the hidden cost. If 1 in 20 visitors who make a preview actually buys, those 20 previews cost about $0.20 on their own. That's why the config has a hard daily cap (daily_spend_cap_usd: 5) and a separate ceiling for how much of it free previews may use (40%).

Per-order math

Three tiers. Payment fee uses a typical MoR rate of 3.9% + $0.40 per transaction (Creem's published rate; yours will differ).

Two things jump out:

1. Model cost is not the problem. Even the premium tier spends well under a dollar on inference.
2. The fixed $0.40 fee is. On $4.99 it eats about 12% of the sale; on $14.99 it's under 7%.

The $4.99 trap

The tempting plan is: run ads to a $4.99 offer, make it up on volume. The math above says each $4.99 order leaves about $4.31 before acquisition. If a paid click-to-buyer costs more than that — and for a cold audience it easily can — every sale loses money. Volume makes it worse, not better.

What I did instead:

• $9.99 is the "most popular" default, visually highlighted; $4.99 exists as an anchor and for people arriving from free/organic links.
• The premium tier adds things that cost almost nothing to produce (a second clip, a written card) but feel like a different product.
• Packaging beats features. "AI pet portrait" on its own doesn't sell. "Your dog as Santa, delivered as a card you can send tonight" does. Seasonal landing pages (Christmas, Lunar New Year, a Japanese New Year card version) reuse the same pipeline with different copy.

Small engineering details that mattered

• Refuse bad input before paying for it. Face detection runs locally before any fal call; photos with people are rejected (the site is pets only, and real-person content is a policy minefield).
• Queue, don't block. fal's queue API returns a request id; the browser polls. One stdlib process handles it fine because nothing waits on the model inside a request.
• Delete by default. Uploaded photos and results are auto-deleted after 7 days. Less storage, less liability.
• Watermark previews, not HD. Previews are low-res and watermarked; HD files are only generated after the payment webhook, so a failed checkout costs one $0.01 preview, not $0.31.
• Log UTM first-touch and last-touch with each checkout. When you do test ads, you'll want to know which creative produced the buyer, not just the click.

Same pipeline, different products

Once you have "photo in → styled images + clip out", it reuses well. On the same stack I've built a casual browser game, Blob Drop, whose character art came out of the same image workflow.

Free stuff if you're building something similar

If you need cute placeholder or final art for a game or app UI, I packaged a set of transparent-PNG characters as the Cozy Chibi Doll Character Pack on itch.io: matching poses, two sizes, pay-what-you-want above a small minimum. And if you're testing a printable product (colouring pages are a common first one), there's a free 5-page Birds & Blooms colouring sampler you can download to see the line weight and page layout I use, with the full 32-page large-print Birds & Blooms pack if you want more.

The short version

Inference is cheap (cents per order). Payment fees and acquisition are what decide whether a small-ticket AI product works. Price the default tier around $10, cap your free-preview spend, reject bad inputs before you pay a model, and use seasonal packaging rather than "AI" as the hook.

Disclosure: I built PetMagi, Blob Drop, the character pack and the colouring packs linked above. The art and portraits are generated with AI models (FLUX.2, Seedream 4.5, PixVerse) and then curated by me. Prices quoted are the providers' public list prices on October 30, 2026.

1. Pick one consistent art style before anything else

Mixing three free asset packs is what makes a prototype look cheap. Pick one style (pixel, flat vector, or soft "chibi" characters) and stick to it for sprites, UI and the cover.

• Keep a single palette of 6–10 colours and reuse it everywhere, including the UI.
• Export sprites at 2× the size you draw them on screen, so they stay sharp on phones.
• Use transparent PNGs with a little padding, so your physics or hit-box shapes don't clip the outline.

If you want a ready set in the soft cute style, I put together a Cozy Chibi Doll Character Pack on itch.io: transparent PNG characters in matching poses that work as placeholder or final art for casual games, visual novels and UI mascots.

2. Make the store page images at the sizes portals actually use

Each portal crops differently, so make the images once at the right sizes:

Put the main character big and centred on the cover; at thumbnail size, nobody can read a busy scene.

3. Package the HTML5 build so it runs on the first click

• Zip the contents of your build folder, with index.html at the root of the zip.
• Use relative paths only; most portals serve your game from a sub-path inside an iframe.
• Test the zip on a phone in portrait mode. If the canvas does not resize, players leave in seconds.
• Don't autoplay sound before the first tap; browsers will block it anyway.

4. Check the share card before you post the link

When you post your game page on X, Reddit, Discord or Slack, the preview comes from og:title, og:description and og:image. Check that the image returns 200 at 1200×630 and that the title isn't cut off. To check a list of URLs in one go, Social Preview & Meta Tag Checker scores each page and gives you the missing tags to paste in.

5. Bonus: a printable for your players or your kids

A surprisingly nice launch freebie is a printable colouring page of your game's characters; parents and teachers share them. If you'd like to see what that looks like, there's a free cute colouring sampler you can download, and the full cute colouring pack if you want more pages.

The short version

One style, one palette, covers at the sizes portals crop to, a zip with index.html at the root, and a share card that isn't grey. That is an afternoon of work, and it is the difference between "prototype" and "game" for most players.

Disclosure: I made the Blob Drop game, the character pack, the colouring packs and the Apify tool linked above; the character and colouring art was created with AI assistance and then curated and edited by me.

None of these need an expensive tool. Here's the checklist I run before (and the week after) shipping something, with the free data source behind each step.

1. Share previews: check every link you'll post (5 minutes)

When someone pastes your URL into X, LinkedIn, Slack or iMessage, the preview comes from a handful of tags: og:title, og:description, og:image, twitter:card, plus a reachable image of the right size.

Check, for every page you plan to share (home, pricing, launch post, docs):

• og:image returns 200, is at least 1200×630, and is under ~5 MB.
• twitter:card is summary_large_image if you want the big card.
• The title is under ~60 characters and the description under ~160.
• There's a canonical URL, and the page is not accidentally noindex.

To do this for a list of URLs at once, I use Social Preview & Meta Tag Checker: it scores each page 0–100 and gives a fix list plus ready-to-paste tags.

2. AI search readiness: can assistants read and cite you? (5 minutes)

More and more people ask an AI assistant instead of Google. The basics that decide whether you get cited:

• robots.txt doesn't block GPTBot, PerplexityBot, ClaudeBot or Google-Extended (unless you mean to).
• Your main content is in the HTML, not only rendered by JavaScript.
• You have clear headings, a short "what is this" paragraph near the top, and structured data (Organization, Product, FAQPage).
• Optional but cheap: an /llms.txt summarizing your key pages.

AI Search Readiness Audit checks these per page and drafts an llms.txt for you.

3. Reviews: read what users actually say (5 minutes, then weekly)

For iOS apps, Apple publishes recent customer reviews per country as a public feed. In launch week, read them daily and sort into buckets: crashes, missing features, pricing complaints, praise. The first two buckets are your next update.

App Store Reviews Scraper & Insights pulls the reviews for one or many countries and groups the complaints and ratings into a short report, for your app or a competitor's.

4. Rankings: know whether launch moved anything (5 minutes, then daily)

Apple's public chart feeds give the top 100 per country, chart and category. Pick 3–5 countries that matter, record your position every day, and treat "not in the top 100" as a data point rather than a missing row.

App Store Top Charts & Rank Tracker snapshots the charts and compares them with the previous run, so you get a rank history without an ASO subscription.

The whole thing on one page

Twenty minutes before launch, five minutes a day after. Cheap insurance against the boring failures.

Disclosure: I built the four Apify tools linked above. Each runs on pay-per-use pricing of a fraction of a cent per page or report, and all the underlying data sources are public.

If all you need is daily chart positions for your app and a few competitors, Apple already publishes the data for free. This post shows where it comes from, what to watch out for, and how to turn it into a daily rank history with almost no setup.

Where the chart data comes from

Apple serves public RSS/JSON feeds of the App Store charts: top free, top paid, top grossing (iPhone and iPad) and new apps, per country and per category, up to 100 apps each. A second public endpoint, the iTunes Lookup API, returns an app's rating, rating count, current version, release date and size by its numeric id.

Together they are enough for honest rank tracking:

• Rank: the position of your app id in a given country × chart × category feed.
• Context: rating and version from the Lookup API, so you can see whether a rank drop lines up with a bad update.
• History: store yesterday's snapshot and compare it with today's.

Three things that trip people up

1. Charts are per country. Your app can be #8 in Finance in the US and absent in the UK. Pick the 3 to 5 storefronts that actually matter for revenue.
2. "Not in the top 100" is a data point. Record it explicitly, otherwise a missing row looks like a broken job.
3. Charts move during the day. Apple refreshes several times a day. One or two snapshots at fixed times give a cleaner trend than random manual checks.

A daily rank tracker in five minutes

I packaged the steps above as an Apify Actor: App Store Top Charts & Rank Tracker. You choose:

• Countries: two-letter codes such as us, gb, de, jp.
• Charts: top-free, top-paid, top-grossing, iPad variants, or new.
• Categories: overall plus 24 App Store categories (games, finance, productivity, health-fitness and more).
• Track my apps: the numeric App Store ids of your app and competitors.
• Save only tracked apps: keeps the output (and the cost) small when you only care about your own ids.
• Compare with previous run: remembers each chart in a named key-value store and reports rank changes, new entries and drop-outs since the last run.

Schedule it once a day in Apify Schedules and every run adds one row per tracked app per chart, with rank, previousRank, change, rating and version. Export to CSV or Google Sheets, or send a webhook to Slack, Zapier or Make when an app enters or leaves a chart.

Pricing is pay per event: $0.005 per chart fetched and $0.0003 per saved app row. Tracking 3 apps across 5 country/category charts every day costs well under a dollar a month, and Apify's free plan credit covers it.

What to do with the numbers

• After every release, check the next 2 to 3 days of rank in your main category. A drop together with a falling rating usually means a bad update; a drop with a stable rating usually means a competitor push.
• Before a launch in a new country, pull that storefront's category chart for a week to see how volatile it is and what rank range realistic download numbers buy.
• Watch the "new" chart in your category to spot competitors early.

Related tools

• App Store Reviews Scraper & Insights turns reviews into complaint themes and rating trends, which pairs well with a rank drop investigation.
• AI Search Readiness Audit checks whether your app's landing page is visible to ChatGPT and Perplexity.

If you track ranks a different way, or need a chart the feeds don't cover, tell me in the comments.

Here is a practical checklist, and a way to run it on many URLs at once.

1. Check robots.txt against the right AI bots

There are two kinds of AI crawlers:

• Training bots (GPTBot, CCBot, Google-Extended, Applebot-Extended, Bytespider, meta-externalagent). Blocking these keeps your content out of model training. That is a legitimate choice.
• Search / answer bots (OAI-SearchBot, ChatGPT-User, Claude-SearchBot, Claude-User, PerplexityBot, Perplexity-User). Blocking these means the assistant cannot fetch your page when a user asks, so you will not be cited or linked.

A blanket User-agent: * / Disallow: / for "AI", or a copy-pasted block list, often hits both groups. Decide per group.

2. Publish an /llms.txt

llms.txt is a short Markdown file at your site root that tells language models what your site is and which pages matter most: a title, a one-line summary, and a list of key links with descriptions. It takes ten minutes to write and gives assistants a clean map instead of guessing from navigation menus.

3. Make sure the content is in the HTML

Most AI crawlers do not run JavaScript. If your product description or pricing table only appears after client-side rendering, the bot sees an empty shell. Check the server-rendered word count and text-to-HTML ratio of your key pages.

4. Give machines structure

• A sitemap (listed in robots.txt or at /sitemap.xml).
• Schema.org JSON-LD: Organization, Product, Article, FAQPage where relevant.
• One clear H1, logical H2s, a real meta description, canonical URL, lang attribute.
• Visible dates on articles, and question-and-answer style sections for common queries.

5. Watch for accidental "do not use" signals

noindex, noai or noimageai meta tags left over from staging are surprisingly common.

Running the check on many pages

I packaged this checklist into an Apify Actor: AI Search Readiness Audit. Paste a list of URLs and it returns, per page, a 0–100 score with a letter grade, the robots.txt verdict for 14 AI crawlers (training vs search separated), llms.txt / sitemap / schema / rendering checks, a prioritized fix list, and a ready-to-publish llms.txt draft if you do not have one.

{ "urls": ["https://example.com/", "https://example.com/pricing"], "generateLlmsTxt": true }

It costs fractions of a cent per page audited (robots.txt, llms.txt and sitemap are fetched once per site and are free), which makes it practical for agencies auditing a whole client list.

Related tools: Social Preview & Meta Tag Checker for Open Graph and X cards, and App Store Review Insights.

Where the data comes from

Apple exposes public endpoints for this, so you don't need to scrape HTML:

• the iTunes Lookup API (https://itunes.apple.com/lookup?id=APP_ID) for app metadata and the store rating
• the customer reviews RSS feed (https://itunes.apple.com/{country}/rss/customerreviews/page=1/id={APP_ID}/sortby=mostrecent/json) for recent reviews, up to 10 pages per country

You can call these yourself with a few lines of Python. The harder part is turning raw reviews into something useful.

Getting a report instead of raw rows

I packaged this as an Apify Actor: App Store Review Insights. Give it one or more App Store links or app IDs and countries, and it returns:

• every review (rating, title, text, version, date)
• an app-level summary: average rating of recent reviews vs. the overall store rating
• recurring themes such as pricing and subscriptions, bugs after an update, ads, login problems
• the most negative and most positive reviews to read first

For example, a run on 20 recent US reviews of a large video app showed an average of 2.75 stars against a 4.66 store rating, with pricing/subscription, a disliked UI update and ads as the top themes. That gap between recent and lifetime rating is often the first sign a release went badly.

Example input:

{
  "apps": ["https://apps.apple.com/us/app/youtube-watch-listen-stream/id544007664"],
  "countries": ["us"],
  "maxReviewsPerCountry": 100
}

Pricing is $0.02 per app report plus $0.0003 per review.

Related tools

• App Store Top Charts & Rank Tracker: daily top free/paid/grossing charts for any category and country, with rank changes since the last run.
• Social Preview & Meta Tag Checker: checks how your app's landing page looks when shared.

Happy to answer questions in the comments.

• og:image points to a URL that returns 404 or redirects to a login page
• the image is too small (under 1200×630 looks blurry on most networks) or too heavy
• og:title / og:description are missing, so the network falls back to random page text
• twitter:card is missing, so X shows a tiny summary card instead of a large image
• the page has no canonical, or it is accidentally noindex

Checking this by hand for one page is fine. Checking it for 50 product pages or a whole blog is not.

A quick manual check

For a single URL you can look at the raw tags:

curl -sL https://example.com | grep -Eio '<meta[^>]+(og:|twitter:)[^>]+>'

That shows whether tags exist, but not whether the image actually loads, what size it is, or whether the title is too long to display.

Checking many pages at once

I built a small tool for this: Social Preview & Meta Tag Checker on Apify. You give it a list of URLs and it returns, per page:

• every Open Graph and X/Twitter card tag it found
• whether og:image loads, its HTTP status, pixel size and file size
• title and description length checks
• canonical, favicon, viewport, h1 and noindex checks
• a 0–100 score, a prioritized fix list, and ready-to-paste meta tags

Example input:

{
  "urls": ["https://example.com", "https://github.com"],
  "checkImage": true
}

You can run it from the Apify console, or call it from code:

curl -X POST "https://api.apify.com/v2/acts/tanlabs~social-preview-meta-checker/run-sync-get-dataset-items?token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"urls":["https://example.com"]}'

It costs $0.004 per page checked, so auditing 250 pages is about $1.

What to fix first

From the pages I tested, the most common problems were, in order: no og:image at all, a missing twitter:card, and descriptions longer than ~200 characters. Fix those three and most link previews look right.

If you want a wider check of how ready a site is for AI search engines (robots.txt rules for AI crawlers, llms.txt, structured data), there is also an AI Search Readiness Audit from the same author.

Questions or feature requests are welcome in the comments.