Eight days, and almost none of it went forward.

A standing instruction: argue with me

Before any code, one rule was set — don't just agree. An advisory persona was defined with four modes: mentor, startup advisor, execution coach, fractional CFO. The founder's explicit note, revisited whenever the advice got too comfortable: encouragement that isn't earned is worthless.

That instruction is why most of what follows exists. A more agreeable process would have shipped in two days and broken in front of customers.

A backend for a site that had no backend

The landing page was a single static file with nowhere to send an order. The answer was a Google Apps Script web app: form submissions land in a private spreadsheet, screenshots upload to Drive, every order gets an ID.

No admin panel was built, because none was needed — the private spreadsheet is the admin panel. One person approving orders by hand doesn't need software to do it.

Proof, not promises

The pricing section was built around a real receipt from a real trip — shelf prices against a delivery app's marked-up version of the same cart.

An early draft used an invented example: "a typical 25-item cart." The founder asked one question — where did 25 come from? It came from nowhere. It was a plausible midpoint dressed as a fact. It was cut, and replaced with photographs of an actual 19-item cart.

Then the arithmetic in the comparison column didn't balance. His own screenshot of a real order explained the gap: a waived delivery fee. The receipt was corrected to match the world rather than the argument.

One price becomes four

A single $25 service grew into a ladder: two standard tiers and two live in-store tiers where the customer joins by video call while the shopping happens. The live shop is the part a delivery app structurally cannot copy.

Going public, and nearly losing the mail

A domain, a business phone, a business email address. Connecting the domain to the host offered a one-click path: delegate the nameservers, done in seconds.

Checking the destination zone first showed it held two records and no mail configuration at all. Taking that one-click path would have silently deleted the business email — no error, no warning, just mail that stopped arriving. External DNS was used instead.

Saying no to bookings, gracefully

Four time windows a day, two orders each. The site now counts existing bookings and greys out full windows, with a manual override sheet for days blocked by hand.

Both checks fail open on purpose. If the availability lookup breaks, every slot stays selectable and conflicts get caught during manual review. A form that silently refuses bookings costs far more than one that occasionally lets through a slot that has to be moved.

Where the money actually moves

The payment structure was stress-tested line by line. The founder never fronts money: the customer's funds land before anything is bought. But one step had a hole in it — standing at a register with a full cart, waiting on a stranger to look at their phone.

That became a 15-minute window, plus a pay-in-full option for customers who know they'll be unreachable. Cash was refused outright, and the reasoning was the founder's: cash invites haggling, change-making and disputes, and leaves no record.

One word, and the receipt fell apart

The founder decided his own pricing should read "service charge," never "fee" — reserving fee for the delivery apps, because that is the word people associate with being nickel-and-dimed. Keeping "fee" on their side of the comparison and "charge" on his sharpened the contrast the entire page is built on.

Renaming it meant reading every line again. And reading every line again exposed something that had been sitting on the most persuasive element of the site for days: the proof receipt showed a $25 service charge against $228.95 of groceries — an order nobody could actually book, because $25 caps at $150.

Service charge   $25.00  →  $40.00
Total           $260.82  →  $275.82
You keep         $47.87  →  $32.87

The failures that never announced themselves

With the business apparently finished, testing began in earnest. Four bugs surfaced that had been live the entire time — every one of them silent.

Text extraction had never worked. Not once. The code called a Google API using the previous version's syntax. It threw an error on every single order, and a safety net designed to stop a failed scan from blocking a customer's order swallowed the error completely. The column sat empty for a week and looked like a feature nobody had used yet.

Photos arrived sideways. Phones store the camera's raw pixels plus a tag saying which way to turn them. Every photo app obeys that tag; the text scanner does not. It was reading rotated handwriting and returning things like reen beans for Green beans.

Only one screenshot ever arrived. A file input replaces its entire selection each time the picker opens — so choosing images one at a time silently discarded all but the last, with nothing on screen to say so.

The calendar had 67 duplicate bookings. One test order existed sixteen times. The duplicate check searched for existing events without a date range, and that search only looks forward — so any order whose date had passed was invisible to it, and a fresh duplicate was created every hour, all day, for five days.

orders dated in the past     up to 16 copies each
orders dated in the future   exactly 1

Two lists, two different readers

Once text extraction worked, it produced something ugly: a cart screenshot scans into a mess of product names tangled with interface text — buttons, promotions, prices, quantity steppers.

The instinct was to clean it up at the source. The decision was the opposite: the raw scan stays raw forever, as the unedited record. Cleaning happens twice downstream, for two people who need opposite things.

The customer gets product names only, in their confirmation email — and if the scan is too damaged to trust, the system refuses to guess and says it will work from the photo instead. Nobody's groceries will ever be listed as "Go to checkout."

The founder gets the opposite: a prep document written to Drive and linked from the calendar booking — items grouped by store department so the store is walked once, with sale prices, deal markers, checkboxes, and the raw scan underneath so anything suspicious can be verified in seconds.

items extracted from 3 screenshots   $125.15
total printed on the customer's cart  $125.15
difference                              $0.00

Fifteen seconds, and five ways to get it wrong

The site made one claim it could not prove: that a real person reading a shelf is different from an app sending a substitution notice. Footage existed. Putting it on the page took five passes.

4 min, full quality   149.0 MB   ~23 plays/day before the free tier ends
40 sec                 25.9 MB
15 sec                 10.2 MB   ~336 plays/day

Then: an export that was a QuickTime file wearing an MP4 name, which half of all browsers refuse to play. A vertical phone video laid out full-width, which had to move into a narrow column. A file that uploaded correctly but landed as aisle-ally-shop.mp4.mp4 — a doubled extension hidden by the operating system, found by the founder reading the deploy log after a remote check had wrongly concluded the file was missing.

And finally: the clip only started playing after you scrolled past it. The proposed fix was a line of small print telling visitors to scroll down and back up.

That line was rejected, and the reasoning is the sharpest thing in the whole build. A workaround written into the page becomes permanent. Instructions teach customers that the site needs handling. The playback was driven explicitly instead — starting 200 pixels before the clip reaches the screen, pausing when it leaves, and falling back to tappable controls on phones in low power mode, which refuse autoplay outright.