A desktop app builds a promo page from a brief or a link

Two template families, one interface

The repository has two templates: template_1 on Bootstrap, and template_2, a static export of an Astro build with Tailwind-style utility classes. Their markup, file names and sets of slots differ, so when you switch templates the app rebuilds its tabs: each template has its own image slots, its own set of colors and its own substitution rules. For the user, the workflow stays the same.

A page from a link: the built-in downloader

The source can be a folder on your computer or the address of an existing page. The downloader uses only the Python standard library and behaves like a careful browser:

• honors <base href> when resolving relative paths
• collects files from img/link/script/source/srcset and from url(...) in inline styles
• follows CSS all the way down, including url() and @import, so fonts and backgrounds aren't lost
• downloads files only from the same site; files on external CDNs stay as links, so the download doesn't pull in half the internet
• strips the contents of <script> before parsing; otherwise strings inside inline JS get mistaken for src=

The logo, favicon and background come from the markup

The first version sorted images into slots by guessing from file name and size, and that is how random images ended up in the header. Now the markup comes first. The favicon comes from <link rel="icon">, the logo from the header and from alt/class values containing logo/brand, the background from background-image: url(...) on body/html, and review images from their own blocks. Guessing by name and size is left only as a fallback. An exclusion list keeps decorative icons, avatars and badges out of the logo slot. Anything the app can't work out stays visible in the interface and is fixed by hand.

Colors are taken from the source page

The app reads the HTML together with its linked CSS files and pulls colors out of the theme variables. If a color is set several times, the last value wins, because the theme should override the base styles. Colors in hex, rgb() and oklch() are brought to one format. Greys and near-whites are dropped, and the rest are assigned to roles: button, button text, header, page background, card, accent. After that, the colors appear in the interface as ordinary fields you can edit.

A project is a single JSON file

Everything about a build is saved in a project file: the chosen template, paths, all the content, colors, which image goes in which slot, questions, reviews. To repeat a page or make a variant, you open the project and change a couple of fields. As a bonus, any build can be repeated exactly, and its versions can be kept alongside the code.

Images are compressed before publishing

Every file that goes into a slot passes through Pillow, a Python library for working with images. It shrinks the image along its longer side, keeps transparency for PNG and WebP and picks a sensible quality. If Pillow isn't available, the files are simply copied and the build carries on. This is the kind of small chore nobody does reliably by hand on every page.

Before publishing, the app checks the markup

A finished page has required elements that are easy to lose while editing a template: hidden placeholders that the host fills in when it serves the page, and a shared event ID for analytics in the browser and on the server. The app checks for them before upload. If something is missing, it puts it back and writes a warning to the log. A template edit must not quietly break event tracking: when statistics silently show zeros, people notice far too late.

Publishing takes one action, even when the name is taken

The finished folder is zipped in memory (system files such as .DS_Store are filtered out), encoded in base64 and sent to the host's Admin API. Existing groups load into a dropdown, and the page name is built from a pattern like {store} - {product} - {template} - {lang}. If the host replies with a 422 "name already used" error, the run doesn't stop: the app finds the existing record and asks whether to overwrite it. If you agree, it sends a PUT request to that record's id. The API key is kept outside the repository, in a local config file that only the owner can read (permissions 600).

The design rules live next to the code

The repository also holds three briefs. The first covers the shared basics: fonts, grid, element states, the mobile version and the page weight budget. The other two are written one per template family: they go through every CSS selector, list what to remove and what to add, and end with a checklist. The app takes care of structure, and the briefs take care of the look. Without the briefs, the app would simply turn out weak layouts faster.

A whole class of mistakes is gone

A forgotten og:image, the favicon from the last project, a logo in the wrong slot, a photo of several megabytes, a background lost in the move: all of this used to be spotted by eye on a live page. Now these things either appear as separate fields in the interface or are checked automatically before upload.

The commit history is a list of real bugs

The tool was polished on real builds, and nearly every commit fixes a specific bug. An animation made the intro logo grow by fractions of a pixel. Relative paths broke when files were moved. A name clash on re-upload used to stop the run outright. The app mistook small icons for a logo. You can't foresee things like these; they turn up in real use. That is why a tool for your own process is worth refining on live tasks.

Limits

This is an internal tool. The interface has no automated tests, and parsing quality depends directly on how neatly the source page is built. On an unusual page the app fills some fields wrongly. That is why everything it detects can be edited, and the log shows every step. You always see what was filled in and where it came from.