Atlas Digital Design

Engineering

The software underneath.

Three applications in production and a fourth built and waiting, all written from nothing, because at some point a spreadsheet stops being enough. This page carries the technical detail that would be out of place on a page written for a storefront owner.

Revenue ledger

Six years of email, read as an accounting system.

Python · about 8,250 lines · four major versions · in production

Reads six years of order-confirmation email across five sales channels and applies each channel's own royalty, modification-fee and flat-fee rules. The July 2026 output reconciles to the marketplace's own sales statement to the cent. Shipped with a drag-and-drop interface and a double-click launcher, so the merchant who depends on it never opens a terminal.

The test strategy is a version diff. Every version is compared row by row against a frozen gold standard, with each discrepancy printed alongside its field and both values and kept as a file. That suite is what caught a defect of mine that had been dropping the base price from bundled orders, so six years of revenue read low until the diff surfaced it.

It also settled, against the project that commissioned it, that the time on an order cannot schedule advertising. Across 368 plan orders in seven years, none falls on a Sunday, and the nine o'clock hour holds twice as many as the next busiest. I first read that as one marketplace manufacturing its timestamps, and said so. I was wrong. The parser takes the time from the notification email, so the field records when the mail went out. That marketplace's notices land on business days and bunch in the nine o'clock hour, which reads as a morning batch. The other channels show an ordinary spread through the day, Saturdays included. The ad-scheduling work was reported as unsupported either way. The correction is on the home page.

Split Engine

Money that reconciles exactly, and a program that will not start on bad weights.

Python · 2,967 lines · test suite, build pipeline, macOS packaging

A configuration-driven revenue-split desktop application, productized into a white-label build where every client-specific value lives in one config file, so standing it up for a new partner takes a config edit and a build.

  • Money is handled in Decimal, and the fee plus all three cuts are allocated from the gross in a single largest-remainder pass, so the parts reconcile to the gross exactly. Drifting pennies are the standard failure of percentage splits done in floating point.
  • Split weights are validated at startup and a group that does not total 1.0 stops the application with a message. The alternative is silently paying somebody the wrong amount, and an error dialog is the cheaper failure.
  • The test suite runs the engine against a second, invented partner contract, specifically to prove the arithmetic follows configuration rather than the numbers it shipped with.
  • Sync is offline-first and idempotent on a composite key, so a stranded order can be re-sent without ever appearing twice. State is reported in four values, because "confirmed absent from the sheet" and "could not reach the sheet" are different facts and collapsing them would lie to the user.

Study-set pipeline

A manufacturing line for a digital product.

Python · PyMuPDF and PIL · nine products shipped

Reduces 36×24 architectural construction sets to 11×17 sample sets, driven by per-product JSON so that adding a product is a data file and never a fork of the engine. Watermarking uses knockout compositing, marks laid first and intersecting dark pixels lifted above mark-on-paper value, so a single levels adjustment in an image editor cannot strip it.

Crop verification was moved out of manual review and into the build itself, as an ink-profile comparison inside against outside every crop edge, firing at build time. It was validated by rebuilding a plan with the exact crops that had previously shipped truncated: it fires on precisely the two edges that were wrong and stays silent on the corrected ones. It is advisory rather than a release gate, because it also fires on sheet borders and drawing captions, each of which was checked and confirmed a false positive before it was set aside.

Pin Board

A client with no destructive call available to it.

Python · native macOS · OAuth 2.0 authorization-code flow · built, posting not yet switched on

A desktop client for planning, inspecting and publishing to a 5,690-pin account, against a registered developer application. No destructive API call is reachable from it, it carries a protected-board allowlist, and its credentials are stored outside version control at restricted permissions. The safety is in the structure: there is no code path to delete, so no mistake at the keyboard can find one. The scheduled posting runner is built and tested and has not posted yet.

How the work is run

An AI stack with a reality filter on it.

The volume on this site is only possible because the practice runs a multi-model stack. The guardrails are stated with it, because an AI-assisted practice without guardrails produces confident nonsense at scale.

  • Every claim in a deliverable is tagged verified, inherited, inferred or untested, and the tag travels with the claim. A 2,100-word platform thesis was written this way, submitted for adversarial review by a second model, and corrected on both sides.
  • Deliverables go through an adversarial review chain. When an outside audit landed two genuine hits on the revenue ledger, both were credited as prominently as its errors were corrected.
  • Model output is treated as a draft that has to survive a source. An inherited strategy memo was verified against live sources before any capital moved, and six of its premises did not survive.
  • Sessions hand off through written documents carrying decisions made, decisions open, tool limits and a do-not-touch list, so work can move to a cheaper model without re-researching a single finding.

A practice that tags its own confidence has to publish the correction when a tag turns out wrong.

Inventory

Languages, platforms and instruments.

LanguagesPython, JavaScript (vanilla, DOM and shadow DOM, MutationObserver, Range and layout measurement), Shopify Liquid, HTML and CSS, SQL-style analytics query languages, JSON-LD, XML and RSS
PythonPIL and Pillow, PyMuPDF, pypdf, pypdfium2, ezdxf, customtkinter, PyInstaller, SQLite, Decimal-based money handling
ShopifyAdmin API and GraphQL, Storefront, theme architecture and Liquid, Flow, Forms, Email, metafields and metaobjects, ShopifyQL
GoogleAnalytics 4 and the Measurement Protocol, Google Ads, Search Console, Merchant Center, the Google tag, Rich Results and structured-data validation
Audit and researchSemrush site audits, backlink audits and position tracking, Core Web Vitals and Lighthouse, strict XML and feed-specification validation
Other platformsPinterest Business, Catalogs and developer API with OAuth 2.0, Cloudflare Pages and DNS, Zoho and Google Workspace mail, legacy stacks
PracticesREST and GraphQL integration, OAuth 2.0, structured data authoring, product feed engineering and strict validation, image processing and compositing, PDF generation and forensic diffing, CAD and DXF geometry extraction, macOS application packaging, email client compatibility engineering, browser automation and its limits

Boundaries

Limits I established by testing.

Each of these was tested before anything was designed around it. They are stated as far as the tests went.

  • Browser automation reaches the Shopify admin shell and stops at the embedded app frames I have tested, the Flow editor among them. Those frames accepted cursor movement and no synthetic click or keystroke. Remediation there gets rebuilt against a public API where one exists, and where none does the work is handed over as a build sheet and reported as open.
  • A Shopify Flow export carries a signature I could not reproduce from the file. I tried SHA-256, SHA-512, SHA3-256, BLAKE2s and HMAC-SHA256 over raw, compact, sorted and newline-variant encodings with a dozen salts, and none matched. That was enough to treat the refused import as a signing problem and stop retrying it as a formatting mistake.
  • Shopify's invisible CAPTCHA blocked storefront customer creation from client-side script both ways I tried it: a fetch came back 400, and a scripted submit landed on a missing-token page. That retired an approach that had already been written, and no workaround was built.