How we build things,
written down so you can copy it.

Before we write a line of code we ask one question of the marketplace: is anyone arriving in this niche now, and is anyone paying? We answer it from public data we scan ourselves, measure flow rather than lifetime totals, read complaints in full, count people rather than seats, and refuse to size a market until we can name the platform mechanism the product depends on.

At the start of every project, and again before every major version, we run the same research question through three AI deep-research engines and fuse the reports into one master roadmap. The value comes from the disagreements between engines and from verifying every load-bearing claim at source; the reports themselves are drafts, not findings.

We build every Shopify app on one shared chassis, keep the logic that makes it different in a pure module we can test for free, and treat the payment path as unproven until a real click reaches Shopify's approval page. Most of the method is a list of checks we added after something broke.

We build each add-on on Apps Script and CardService with the narrowest scope that does the job, then take it through consent, verification and review. Approval proves little: what kept our add-ons working was testing on a clean account, testing what they write, and counting people rather than seats.

We built 25 Jira and Confluence apps on a few shared chassis and submitted them together. Four are public; the other 21 were rejected and are stuck behind a listing state only Atlassian can clear, because we skipped the step that would have shown us the wall: taking one app all the way through review first.

We built one monday.com app, a board view that writes a short AI summary of a board, and submitted it in August 2026. It was rejected in September for overlapping apps that already exist. The build method held up; the step we skipped was asking monday, before writing code, whether the concept would clear its duplication policy.

We test demand with our own App Store scanner before writing code, keep the engine in a package that can be verified without Xcode, and treat a clean install on the simulator as our first reviewer. Our worked example, Null Field, is built and ready to submit, but it has not been submitted.

We read Google Play's gates and measure demand before writing code, build a native Kotlin and Compose app, then look at it running: our worst defects were visible only on screen. Our first app is built but not published, and our own research says organic Play distribution will not carry it.

We record the page, not the screen, in a dedicated browser, with steps addressed by selector and captions burned in. Each beat of the film shows one thing the requested permission is used for, so the reviewer can see the app do what the listing claims. Most of our rejected takes came from the surface and from leftover state, not from the app.

Every app marketplace asks what data the app touches, where it goes, who else processes it and what protects it. We answer every form from one data map per app, back each Yes with a public page or a contract, and treat a No that blocks approval as a reason to build, not to reword.

We are building SOLOMONAR, a first-person folk-horror game set in a Maramureș village over seven days, with agents doing most of the typing and one person deciding. The method rests on three decisions taken on day one, a world that can be checked without a screen, and one rule: no automated check is trusted until we have seen it fail on a world we broke on purpose.

For SOLOMONAR we take people, animations, voices and music from free sources and run the voice generation on our own machines. The method is to read every licence inside the file, under the heading it sits under, and to check the whole chain an asset came from. That reading reversed one of our own decisions: the Romanian voice we had cleared turned out not to be cleared.

The articles on this site are drafted by AI agents, checked by other agents and then by a script with no model in it. The method rests on one finding from the first round: language models invent quantities in words as readily as in digits, so a checker that only reads digits passes most of what it should stop.

We run many AI coding agents at once, often on the same files and the same systems. Almost nothing we lost came from bad code. It came from coordination: agents sharing a scratch space, two runs writing one live file, a deploy that published someone else's half-finished work, and runs that died together and resumed blind. These are the rules we follow now.

Before any submission we compare every claim on a plan page, a listing or a public page with the code that is supposed to back it. A claim stays only if a merchant can reach a working implementation; otherwise we build the feature or delete the claim. A script catches the mechanical cases, and the rest is read by hand.

Publish every page twice, as HTML for people and as Markdown for machines, and generate both from one source so they cannot disagree. Add an llms.txt index, an Atom feed, Article structured data that points to the Markdown, and a robots.txt that names the AI crawlers. Then check each file by what the server actually sends, not by whether it answers.

Generative engine optimisation (GEO) for a Shopify store is ordinary SEO aimed at AI answers: let the AI crawlers in, write pages that answer questions in quotable passages, add structured data that is true, give Shopify's own assistant real FAQs, and measure visits that arrive from AI referrers. This is the method we built into our Shopify app Cite Me, with the mistakes that shaped it.

An agent skill is a folder with a SKILL.md file that tells an AI coding agent when and how to do one recurring job, plus any script the job needs. We extend an existing skill before creating a new one, make every write a dry run by default, and keep the rules that must hold outside the prompt: in hooks, read-only database roles and a shared knowledge base.

Breakeven CPA is the most a store can pay in advertising for one placed order before that order loses money. For a cash-on-delivery store it is revenue without VAT, minus goods and shipping, counted only on delivered orders, minus the shipping already paid on every refused parcel. We scale only below 70% of that number.

To decide whether to scale, hold or cut an ad campaign, compare its cost per order with the store's breakeven CPA, not with a target CPA someone chose. Platform-reported ROAS is inflated, so CPA is the safer gate; brand search and ads on sold-out products need their own tests, because both look different in the report than in the bank account.

Every serious product-image fault we found passed our automated checks: a clean packshot missing half the product, an infographic with correct dimensions drawn over another product, a sharp file that turned blurry once cropped. The method is to open every image and compare it with an independent reference for the physical product, not with other pictures from the same supplier pack.

Mine Google Ads search terms by grouping the real queries into words and short phrases (n-grams), add negative keywords only for patterns that are clearly outside what the store sells, and audit existing negatives for ones that block buyers. Zero conversions on a single search term is not proof of waste: on Shopping and Performance Max most sales come from a long tail of queries that each convert rarely.

A Merchant Center misrepresentation suspension usually comes from trust signals, not from checkout: a hidden or contradictory company identity, missing policy pages, empty business information, and on-site claims that are not true, such as countdowns that restart for every visitor or invented sales counts. Fix every signal before you request a review, because review requests are limited, and run a weekly feed-health check so product-level problems never pile up.

Creative fatigue is visible as a pattern, not as one bad metric: frequency climbing while click-through rate falls or cost per purchase rises. We compare the last 7 days of each ad account with the 21 days before, flag an account only when frequency is up more than 15% and CTR is down more than 10% or CPA is up more than 20%, and only then drill down to individual ads. Most of our false alarms came from the data, not from the audience.

Before writing another email campaign, check which automated lifecycle flows the store already runs against a standard list of 10, whether each one is live or only a draft, and how much the email platform over-credits itself compared with your analytics. Then check the two things no flow audit shows: that consent withdrawals reach the sending platform at once, and that segments are built on customers who actually received their orders.

A duplicate order is the same customer placing the same order twice, usually minutes apart. We catch duplicate orders by running the duplicate decision inside the step that creates the shipping label, matching on the normalised phone number, and cancelling automatically only pairs that are strictly identical; everything else goes to a person. Our first detector decided correctly but too late, and most of what we know came from the cases it got wrong.

A ghost shipment is a parcel whose shipping label exists but which the courier never scanned at pickup, while the customer has already been told the order shipped. We find ghost shipments by asking the courier, not our own records, for the last event of every label older than a few days, treating a missing answer as a failed read rather than a status, and sending every case to a person instead of remaking labels automatically.

We let a language model draft customer service replies from the team's approved macros and from procedures learned from real agent replies, grounded in the customer's actual order data. A human reviews and sends every reply; the model never sends. The guards around the draft matter more than the prompt, and most of what we learned came from guards that were silently not working.

A refund watchdog is a read-only report that finds customers who are owed money the store never returned: card orders cancelled without a refund, and accepted returns that were sent to payment but never paid. It runs two plain rules against the order and return records and lists the oldest cases first. Our worst refund failure was a refund button that had never worked while every ticket showed as refunded.

Reorder quantity per SKU is daily sales velocity times the days until the next delivery plus a safety buffer, minus what is on hand and what is already on the way. Velocity can be read from daily inventory snapshots, but only after correcting for restocks, stock-outs and duplicated stock rows, and the incoming figure must come from what was actually loaded, not from what was ordered.

When several warehouse stations print shipping labels from the same orders, the safe design is one print queue in which downloading a label is the act that removes it from every station's queue. We route each label to one station with a single shared rule, filter before we download, mark as printed everything we export by any other path, and send a batch as one complete document. Every lost or double-printed label we had came from a download that happened in the wrong place or at the wrong time.

Address normalisation turns what a customer typed into the form a courier accepts and a national register confirms. We do it per country: first we find out whether that country's postcode describes a street or a whole locality, then we validate against a register whose flaws we know, normalise the register and the search with the same function, and send the courier its own spelling and identifiers. Most of the failures we hit were in the plumbing around the address, not in the address.

A GDPR erasure request is a customer asking an online store to delete their personal data. We stop marketing to that person within the hour, map every system that holds a copy, delete only by exact keys, and install a deletion ledger before deleting anything, because nightly syncs rebuild what you erase. Some records, such as invoices, must be kept by law, so the reply never says "we deleted everything". This is our working method, not legal advice.

An SEO article on a store blog may only mention products that exist and are in stock, and only claims the store can prove. We ground the writer in a catalogue exported from the store, have a second agent try to refute each draft, and let a script with no model in it block publication on fake product links, banned words and invisible AI characters.

Profit per product is the contribution each SKU leaves after its own costs: revenue without VAT, minus cost of goods, transport and marketing, counted on delivered orders only. Free gift units carry their real cost, transport comes from the real cost of each order with a fallback cascade, and marketing is allocated per order. The hard part is not the formula but taking each input from the right source.

To allocate advertising cost to products, read cost at the level of the individual ad, match each ad to a product through a fixed ladder of rules (exact SKU code, then keyword, then account), split shared ad accounts by a token in the campaign name, and divide what remains across products by number of orders. Every rule fails silently in a specific way, so the method is mostly about catching those failures.

To compare stores that sell in different EU countries, remove each destination country's VAT from revenue, convert every order from its own currency at a dated exchange rate, take costs without the VAT on their own invoices, and only then compare contribution per delivered order. Most of our cross-country errors came from a wrong VAT divisor, a stale exchange rate or a cost read in the wrong currency.

A buy-two-get-one-free (2+1) promotion makes money when a three-unit order, after the cost of all three units, one parcel and the advertising cost of one order, still leaves positive contribution. Measure it per order, split by units per order, on delivered orders only, with the free unit charged at full cost.

RFM segmentation, cohort retention and customer lifetime value only mean something on a cash-on-delivery store if they are computed on delivered orders, because a parcel refused at the door is not revenue. We score every customer by recency, frequency and monetary value from delivered orders only, per store and per currency, and we find a single customer across systems by the last nine digits of the phone number. The hard part was not the formulas but making sure the search and the data use the same normalisation.

A "frequently bought together" block can be computed from your own orders with market-basket analysis: count how often two products appear in the same order and rank the pairs by lift, which says how much more often they sell together than chance would predict. We compute pairs per store over the last 180 days, from a source that holds almost every order, with minimum counts that keep rare products from producing absurd lifts. The method finds real pairs; turning them into bundles was harder than the maths.

Performance Max does not take video files: every video asset is a YouTube video referenced by its ID, so the path is clip, checked MP4, upload to the brand's own YouTube channel, then a link to the asset group. We keep clips at 11 seconds or longer, deliver 16:9, 1:1 and 9:16 versions, attach a handful rather than dozens, and verify each step by reading the result back. Most of what went wrong for us came from steps that reported success without doing the work.

A scheduling API that answers HTTP 200 has accepted the post, not published it; publishing happens later and can fail separately on each network. In the period we measured, our poster logged success on every run while all 17 Facebook posts and 12 Instagram posts failed. We now read the final status per network after the publish time, expire every cached list of connected accounts, and check generated captions in code, on the text that actually leaves.

A conversion audit of a product landing page checks, in a fixed order, whether a visitor on a phone can see the offer, the price, the buy button and the reasons to trust the shop, and whether the page loads fast enough to be seen at all. The output is a list of hypotheses ranked by likely impact, not a proven lift: only an A/B test can say whether a fix raised conversion.

To monitor competitor prices, keep a list that maps each of your products to the same product on competitor sites, read the price from the page's structured data every night, store every reading in an append-only history, and compare only fresh, plausible prices against yours. Matching the right product and keeping the feed alive are harder than reading the price. A price change based on the comparison is a decision to test, not a proven gain.

A silent data failure is a pipeline that reports success while its data is stale or wrong. We catch them with three scheduled checks: a watchdog that reads the newest row instead of the job status, heartbeats that fire only on success, and a daily reconciliation of the same number from two independent sources. The checks themselves were wrong several times, and those mistakes are part of the method.

A successful deploy command proves that a transfer happened, not what was transferred. We make deploys safe with three habits: every deploy script is a dry run unless given --apply, a daily parity check compares server files with git, and after publishing we compare the served source and response bodies with what we meant to ship.

Headless Chrome will not lay a page out narrower than about 500 CSS pixels, so a 390-pixel screenshot is a crop of a wider page, not a phone. We test phone widths with device emulation over the Chrome DevTools Protocol and then measure the page instead of looking at it. Six traps on our own site were caught only that way.

Shopify Admin API tokens come in kinds that must be handled differently: a permanent custom-app token must never go through refresh logic, while an expiring token must be refreshed with a single-use refresh token that you persist every time. Most of our token outages were not expired tokens but refresh logic applied to the wrong token, or two refreshes racing each other.

Google Apps Script code can be read and written through the Apps Script API, so a script no longer has to be pasted into the editor by hand. Our deploy tool runs as a dry run by default, backs up the current project before every write, re-sends every file because the API replaces the whole project, and verifies the result twice: by reading the code back and by checking what the script wrote.

A fail-safe cache is one where a failed refresh leaves the previous data untouched: write with a pure upsert, never delete-then-reinsert, and retry the timeout exception your client library really raises. Backfills fill gaps with IS NULL instead of rewriting decisions, snapshots check themselves on read, and a value from today never answers a question about the past.

The database traps that hurt small production apps are not about scale: a long read on SQLite blocks every writer, a filter on an encrypted column silently matches nothing, DISTINCT fails on a table with a json column, commit() and rollback() expire ORM objects even inside the error handler, and a fixed epsilon is too small for a float32 column. Each one passes a quick test and fails in production, usually without a clear error.

A warehouse scanning app turns a barcode read on a rugged Android terminal into an answer the picker can act on in a glance. We take the scan from the hardware scanner as a broadcast, route every screen through the same scan handler, write status as short field labels with colour for severity, and test every text colour against every background in both the light and the dark theme. Most of our bugs were a fix that existed on one screen and not on the others.