DEV Community: HS Solution

Before the final invoice: a 10-point acceptance checklist for outsourced software

HS Solution — Fri, 16 Oct 2026 22:33:27 +0000

Most outsourcing disputes I've seen don't start during development. They start the week after the last invoice is paid, when the client discovers that the server is on the developer's personal account, the email service runs on someone else's API key, and nobody wrote down how to deploy.

We run a small development studio, so we sit on the delivering side of this. Over time we turned "what should be true before the final payment" into a written acceptance checklist that we send to clients before delivery. It protects both sides: the client knows exactly what "done" means, and we get a clear acceptance date instead of an open-ended "one more thing."

Here is the short version. If you freelance, feel free to copy it into your own contracts.

The 10 checks

1. Every feature, one row in a table. Copy the features from the quote or spec into a table and mark each row pass or needs fixing. Clicking around the obvious screens is how missing features slip through.

2. Real devices, real browsers. Run the core flows on what users will actually use: an iPhone with Safari, a mid-range Android phone, Chrome on desktop. "Works on my machine" is not acceptance.

3. The unhappy paths. Submit an empty form, type a wrong password, go offline. A clear message is a pass. A blank page or a raw stack trace is a fix.

4. Accounts in the client's name. Admin panel, server, database, email sending, maps, payments: each should sign in with the client's own email, not a borrowed developer account. Change passwords after handover.

5. Source, repo, domain, server. The full source lives in a repository the client owns. The domain registrant and hosting account are in the client's name. Compare against the contract line by line.

6. Deployment is written down. Install, configure, build, upload, restart. If another developer could ship a new version from that document alone, it's enough. Secrets go over a separate channel, never in the README.

7. Personal data and backups. What is stored where? Are passwords hashed? Does the privacy policy match what the code actually does? Do backups run automatically, and has anyone ever restored one?

8. The bug-fix window is in writing. How many days of free fixes, starting from which date (acceptance or delivery), and what counts as a bug versus a new feature request.

9. Licenses for fonts, images and libraries. A list of every font, photo and icon, whether commercial use is allowed, and whether credit is required. "Found it on Google Images" turns into a legal email later.

10. Basic performance. How fast the first screen appears on mobile data, whether images are oversized, whether text is readable on a phone. If the contract has numbers, test against those.

Tie the final payment to acceptance

This is the part that actually prevents the arguments. Put three things in the contract:

a review period (for example, 7 days after delivery),
how fix requests are filed (in writing, against the checklist rows),
and that the final payment is due a few days after the acceptance date, which is the day every row reads pass.

The filled-in table becomes the acceptance record. No one has to remember what was agreed in a call.

This is general information, not legal advice. Have important contracts reviewed by a professional.

Full version

The longer guide has an example for each check and sample contract wording: Acceptance Checklist: 10 Things to Verify Before the Final Payment. It's on our studio site (HS Solution), so yes, that's our page.

What's on your own handover list that isn't here? I'm especially curious how other freelancers handle third-party API keys.

This post was written by an AI assistant from the checklist we use in our own projects.

One modulo gives you a Korean Saju day pillar (and Seoul's 1900 time zone breaks it)

HS Solution — Fri, 16 Oct 2026 16:35:20 +0000

In Korean Saju (the "Four Pillars" of birth), the day pillar is the one part of the chart that is pure arithmetic. No solar terms, no lunar calendar, no lookup tables — just a 60-day cycle that has been running without a break for a very long time.

So it should be a one-liner. It mostly is. But the obvious JavaScript version gives the wrong answer for every date if your machine is set to Korean time. Here is the math, the bug, and the fix.

The 60-day cycle

Each day gets a pair: one of 10 Heavenly Stems and one of 12 Earthly Branches. Both advance by one every day, so the pair repeats every lcm(10, 12) = 60 days.

const STEMS    = "甲乙丙丁戊己庚辛壬癸"; // Gap, Eul, Byeong, Jeong, Mu, Gi, Gyeong, Sin, Im, Gye
const BRANCHES = "子丑寅卯辰巳午未申酉戌亥"; // Ja, Chuk, In, Myo, Jin, Sa, O, Mi, Sin, Yu, Sul, Hae

Because both counters move together, a single index i in 0..59 is enough: the stem is i % 10 and the branch is i % 12. Index 0 is 甲子 (Gap-ja), index 59 is 癸亥 (Gye-hae).

Pick an anchor, count days

All you need is one date whose pillar you know. 31 January 1900 was 甲辰 (Gap-jin), index 40. From there:

function dayPillar(y, m, d) {
  const days = Math.round(
    (Date.UTC(y, m - 1, d) - Date.UTC(1900, 0, 31)) / 86_400_000
  );
  const i = (((40 + days) % 60) + 60) % 60; // works for dates before 1900 too
  return STEMS[i % 10] + BRANCHES[i % 12];
}

dayPillar(2000, 1, 1);  // "戊午"  (Mu-o, 55th day)
dayPillar(2000, 1, 2);  // "己未"  (Gi-mi)
dayPillar(1949, 10, 1); // "甲子"  (start of a cycle)
dayPillar(2026, 10, 17); // "甲子" — also a cycle start

Two details matter:

((x % 60) + 60) % 60 — JavaScript's % keeps the sign, so dates before the anchor would give a negative index without it.
Date.UTC and Math.round — this is the part people skip.

The bug: local time + `Math.floor`

The "obvious" version uses local dates:

// Don't do this
const days = Math.floor((new Date(y, m - 1, d) - new Date(1900, 0, 31)) / 86_400_000);

I ran both versions for 15 May 1990 under different TZ settings:

TZ	local-date version	UTC version
UTC	庚辰	庚辰
America/New_York	己卯 (wrong)	庚辰
Europe/London	己卯 (wrong)	庚辰
Asia/Seoul	己卯 (wrong)	庚辰

New York and London are wrong because of daylight saving: 15 May is in summer time, 31 January is not, so the gap is one hour short of a whole number of days, and Math.floor drops a day. In January the same code happens to work, which is why this bug survives testing.

Seoul is worse. Daylight saving isn't the problem there. In the time zone database, Seoul in 1900 was on local mean time, UTC+8:27:52, not today's +9:00. So the gap between any modern date and the 1900 anchor is about 32 minutes short of a whole day:

TZ=Asia/Seoul  (new Date(1990,4,15) - new Date(1900,0,31)) / 864e5
→ 32975.9777

Math.floor turns that into 32975, and every date comes out one pillar early. The machine most likely to run a Korean astrology calculator is the one where the naive code always fails.

The fix is boring: do calendar math on calendar dates. Date.UTC has no time zone and no DST, and Math.round absorbs any leftover floating-point dust.

What the day pillar does not handle

Year and month pillars are a different problem. They change at solar terms (the year at Ipchun, around 4 February), not on 1 January, so you need an astronomical table or a good library for those.
The 23:00 boundary. Some schools start the new day at 23:00 (the start of the 子 double hour), others at midnight. My calculator uses midnight on the calendar date and says so on the page. Whichever you pick, document it, because users will compare results across apps.
Birth time zone. Use the calendar date where the person was born. Don't use the date converted to the server's zone.

Try it

I put this exact function behind a small free page that shows your day pillar and what the Day Master element traditionally means: Find Your Day Master. It is entertainment and cultural reference, not prediction.

The same rule runs inside our Android app Starlit Alley, which builds the full chart (Google Play). I'm part of the small team that makes it.

If you've hit the Seoul LMT offset in other date code, I'd like to hear where it showed up.

This post was drafted with AI assistance. Every result in it, including the table, came from running the code above in Node.js.

Catching broken vertical game clips before posting, with row-wise Laplacian sharpness

HS Solution — Thu, 15 Oct 2026 13:20:37 +0000

We are a tiny studio, and we post a lot of 9:16 clips of our games. Last week one of them went out broken: the gameplay sat in the top half, the bottom third was an empty blurred background, a debug overlay was still visible, and the game's name was nowhere on screen.

Nobody "looked" because everybody assumed someone else had. So we wrote a check that a script runs before any vertical video can be posted. It has no ML model. It uses ffmpeg, numpy and one old trick: row-wise Laplacian sharpness.

The idea

Our vertical template puts the gameplay (landscape) in the middle of a 1080x1920 canvas. Above and below it we put a blurred copy of the same footage, plus two text bands: a hook line on top and the game name below.

Blurred background is soft. Real gameplay and text are sharp. So if you measure "how sharp is each row of pixels", you get a vertical profile of the frame. From that profile you can read where the real content sits.

Sharpness per row

For each sampled frame (1s, 25%, 50%, 75% of the clip), grab a PNG with ffmpeg:

ffmpeg -y -ss 12.5 -i clip.mp4 -frames:v 1 f2.png

Then a 4-neighbour Laplacian, averaged across each row:

import numpy as np
from PIL import Image

g = np.asarray(Image.open("f2.png").convert("L"), dtype=np.float32)
H, W = g.shape
lap = np.abs(4 * g[1:-1, 1:-1] - g[:-2, 1:-1] - g[2:, 1:-1]
             - g[1:-1, :-2] - g[1:-1, 2:])
row = np.zeros(H, dtype=np.float32)
row[1:-1] = lap.mean(axis=1)   # one number per row

On our footage, blurred background and flat colour rows land around 0.2–1.0. Gameplay rows are well above that. We call a row "sharp" at 2.0 or more.

What we check

Empty margins. Find the first and last sharp rows (ignoring runs shorter than 2 rows). Everything outside them is "blank". Our good template has about 27.6% blank at the bottom by design. The broken clip had 34–49%. The limit is 31%.
Is the gameplay centred? Mask out the two text bands, then join sharp runs with gaps of 60 rows or less (dark game scenes have soft rows inside them). Take the longest block of at least 100 rows. Its centre must be between y=760 and y=1040.
Is there text in the bands? In the hook band and the name band we check two things: at least 2% of pixels are bright (above 190), and the band's average sharpness is at least 3.0. White text on a blurred background passes. An empty band fails.

One trick that mattered: a single frame can be a dark scene with almost no sharp rows. So for the "centred" check we take the maximum of each row across all four frames and judge once. Margins and text bands are still judged per frame.

The gate

The check writes a contact sheet with the safe-zone lines drawn on it, and a JSON line with the file's sha256 and the measured values. Our posting command refuses a vertical mp4 unless:

the machine check passed for that exact sha256, and
a different person (not whoever made the clip) has looked at the sheet and signed off with a note.

The second rule is not technical, but it is the one that would have saved us last week.

What it doesn't catch

A debug overlay inside the gameplay area. We now crop it out when building the clip, but the check can't tell UI from gameplay.
A sharp but wrong frame (for example a menu screen). That's what the human sign-off is for.
Thresholds are tuned to our template. If your background isn't blurred, row sharpness won't separate content from margin.

It runs in a few seconds per clip, and on last week's broken clip it fails on the bottom margin straight away.

We make small games and apps in Seoul. The clip that started this was for Leather Atelier, a cozy bag-crafting game we're building in Godot.

Written by our in-house AI assistant from our actual code and measurements, and marked as AI-generated.