Executive Product Overview
mycountdowntimer turns a time-limited offer into a defined, testable campaign. The product combines a Free Desktop authoring application with a Paid Managed edition that adds central administration, persistent visitor deadlines, publishing controls and richer expiration behavior. Its purpose is straightforward: help a business communicate when an offer ends and define what the visitor experiences afterward, without asking the business to construct a timer from scratch for every page.
The engineering challenge is larger than displaying decreasing numbers. A credible countdown must interpret time consistently, survive the appropriate browser lifecycle, respect the selected edition, and transition into a deliberate expired state. A managed campaign also needs safe administrative access, versioned publication and dependable event delivery. Those responsibilities are separated into reusable packages and a small browser runtime so that the visible component remains focused while the surrounding system carries the operational complexity.
This case study describes the reviewed implementation and deployment candidate. It does not present a production launch, completed Windows installer validation or measured conversion uplift. The commercial value is a product objective; the engineering evidence concerns implemented behavior, repair results, package integrity and the remaining release gates.
The Problem: An Offer Needs an Ending
A countdown is often treated as decoration added near a purchase button. That approach leaves unanswered questions at exactly the moment the promotion ends. Should the visitor move to a different page? Should the price change? Should purchasing stop, a waitlist appear, or an integration receive an event? When those decisions are scattered across page scripts, each new campaign becomes another opportunity for conflicting behavior and difficult support.
Returning visitors introduce another challenge. A timer that starts again on every refresh can contradict the intended offer. A campaign with one absolute deadline must behave differently from an evergreen campaign that begins with a visitor’s first qualifying visit. The product therefore makes timing mode, persistence and expiration action explicit configuration rather than incidental consequences of a browser tab staying open.
There is also an operator problem: people need a useful entry product before they need a managed service. The Free edition provides local authoring and an exportable component. The Paid edition adds control where central publishing, recurring use and integration justify it. Keeping those boundaries explicit makes both the product promise and the implementation easier to evaluate.
Two Editions, One Campaign Model
The Free Desktop edition is the giveaway entry point. Its expiration capability is redirecting to another page; richer managed actions do not belong in its export path. Its local authoring workflow reduces the need for a hosted admin service when the user simply wants to prepare and place a countdown. A compiled Windows release remains a separate delivery gate from having functioning desktop source and automated tests.
Paid Managed provides the administrative layer: campaign creation and editing, publication, version history, rollback, visitor persistence and multiple expiration actions. It uses a browser-based React interface backed by a PHP API and MySQL-compatible database. The same conceptual campaign model connects the authoring experience to the component that eventually appears on a visitor’s page.
The shared schema is deliberately not the only enforcement point. A campaign can be structurally valid and still belong to the wrong edition. The Free exporter now asks the edition question directly before writing an output. Tests include altered files and direct calls into the desktop bridge, because hiding a control in the interface is insufficient to establish a product boundary.
| Capability | Free Desktop | Paid Managed |
|---|---|---|
| Authoring | Local desktop | Browser admin |
| Expiration | Redirect | Redirect, page updates and events |
| Persistence | Page-load evergreen | Visitor and recurring modes |
| Publication | Export component | Versioned publish and rollback |
| Release evidence | Windows runtime pending | Hosting and hardening pending |
System Architecture
The implementation separates schemas, core timing and design logic, export generation, Free runtime, Managed runtime, desktop application and administrative application. A shared campaign definition carries identity, lifecycle, timing, content, design, urgency stages, expiration actions, audit fields and provenance. This avoids creating unrelated representations of the same offer across the editor, API and browser component.
The desktop application hosts a local authoring experience through Electron. The web admin builds on React and TypeScript. The server side targets PHP hosting with a MySQL-compatible data store, while browser bundles deliver the countdown experience. The deployment package distinguishes publicly served files from private application code and configuration. Secrets and operational application files are not intended to sit beside the public landing page.
This separation supports targeted review. A change to webhook delivery can be checked against the Free runtime hash. A routing adjustment can be evaluated independently from campaign design. A visual repair can be scoped to the admin interface without changing the approved marketing page. The architecture makes those boundaries measurable through package contents, source comparisons and focused regression evidence.
Timing, Time Zones and Deadline Semantics
Fixed campaigns define a local deadline and an explicit time zone, which the core resolves into an absolute instant. Daylight-saving transitions matter: a local time can be ambiguous when clocks move backward or nonexistent when they move forward. The schema includes an ambiguity policy rather than silently assuming that every local timestamp maps to exactly one real moment.
Evergreen campaigns express a duration and a persistence mode. The schema distinguishes page-load, session, visitor, daily and weekly behavior. Daily and weekly configurations include a local cutoff, and weekly schedules additionally identify a weekday. These are different scheduling contracts, not merely different labels on an identical timer. Each must be interpreted according to its own rule at initialization and subsequent visits.
The visitor sees a simple countdown, but the underlying question is always which deadline governs that visit. Separating deadline resolution from rendering prevents a visual refresh from becoming an unintended extension of the offer. It also allows the system to test boundary conditions directly, including expiration, reload and invalid local time input, without depending on someone watching a clock manually.
Persistence That Matches the Offer
Paid visitor persistence is designed to carry a visitor’s deadline across reload and browser restart. When stored observations disagree, the implementation uses earliest-deadline-wins behavior so a later observation does not quietly give the same visitor a longer offer. This is a practical distinction from the Free page-load behavior, which does not promise durable visitor identity.
Browser persistence has a defined scope. Clearing the relevant site data can remove the local record; private browsing, different browsers and different devices are separate contexts. Clearing a browser’s ordinary HTTP cache is not necessarily the same action as clearing cookies or local storage. The product should explain this accurately rather than promising an identity guarantee that client-side storage cannot provide.
Persistent display logic also does not establish a checkout entitlement by itself. If an offer must stop being purchasable at a precise deadline, the commerce system needs to enforce that deadline when it accepts a transaction. mycountdowntimer manages campaign presentation and configured transitions; an integration must connect those transitions to authoritative purchasing rules when the business requires that stronger guarantee.
A Reusable Visual System
The campaign schema supports edge, contained and floating bars alongside several inline formats: transparent, soft card, outline and dark card. Recipes such as classic, split, spotlight, editorial, promo and minimal provide structured starting points. Timer styles range from clean blocks and compact numerals to digital, flip-clock and progress-ring treatments. The purpose is reusable composition rather than a separate hand-coded component for every offer.
A base color drives a derived palette, with explicit overrides available for surfaces, borders, primary and secondary text, calls to action and focus indication. Content fields include an eyebrow, headline, supporting text, CTA and expired message. Optional labels and day display let a campaign fit its context without discarding the underlying timing semantics.
Motion is represented as a configuration choice, and urgency stages can request a one-time pulse as a threshold is crossed. Reduced-motion behavior is part of the model’s intent. The approved mycountdowntimer logo remains a separate brand asset: its original pixels are embedded in this document, while CSS controls the visible size and alignment within the page’s header and portfolio tile.
Expiration Is a Product Workflow
Free campaigns keep expiration narrow: redirect the visitor to another page when configured, with an expired message available when a redirect is absent or fails. This is easy to explain and useful for a giveaway product. The destination can contain the standard offer, a closed-promotion explanation or another page the business has prepared.
Paid actions broaden that workflow. The schema includes replacing the offer headline, replacing the displayed price, replacing the CTA, disabling a purchase control, showing a waitlist, hiding the component, restarting an evergreen sequence within a configured cycle limit, dispatching a browser event and requesting a webhook through a registered endpoint. A redirect remains available as well.
These actions serve different operational needs. A price replacement communicates the next offer; a waitlist preserves interest after availability closes; a browser event lets the containing page respond; a webhook connects the campaign to a server-side recipient. A displayed price change alone does not alter a payment provider’s price. The implementation and integration contract must keep that distinction visible so campaign presentation and transaction authority remain consistent.
Administration, Publication and Recovery
The Paid admin provides a central place to manage campaigns rather than requiring every revision to be copied into a new standalone page. Draft editing is separated from publication. Transactional publish protects the relationship between campaign configuration and the version being made available to visitors. Optimistic concurrency detects competing edits so one operator does not silently overwrite another operator’s newer work.
Rollback is implemented as a new audited version. That choice retains the fact that an operator restored earlier behavior, instead of erasing the intervening history. A reviewer can distinguish the original publication, later revisions and the subsequent recovery action. The audit trail becomes part of how the system explains changes, rather than a cosmetic activity list detached from publication.
The requested access direction is password entry with Google login hidden for now. Google OIDC work exists in the implementation history, but live Google authentication is not represented as cleared for release. Login hardening remains part of the active release work. A branded login screen improves continuity; successful authentication and secure session behavior still require their own technical evidence.
Webhook Delivery: Authenticity Before Automation
Webhook delivery exposed an important integration defect during independent review. The worker originally signed with a hash of the issued secret while a recipient used the issued secret itself. Both sides could reasonably believe they implemented HMAC and still disagree on every authentic message. The repair aligned the signing contract with what the recipient was actually issued.
Secrets are sealed with libsodium secretbox under a server key held outside the database. This supports retrieving the correct signing material without storing it as plaintext in the database. Rotation, revocation, backup and restore behavior need to be considered together: restoring the database without the corresponding server key cannot legitimately reconstruct usable secrets, and delivery must fail closed rather than invent a replacement.
The repair evidence included a TLS recipient verifying a real delivery with its issued secret. Altered bodies, altered timestamps and incorrect keys were rejected. That is stronger evidence than comparing two helper functions in one process. It tests the contract across the same sender-recipient boundary that an external integration will depend on in actual operation.
Network Destination Controls and DNS Rebinding
An outbound webhook is a network request made by the server on behalf of a configured campaign. Validating only the URL’s text is insufficient. A hostname can resolve to an unacceptable address, and its answer can change between initial validation and the eventual connection. The review therefore treated destination validation and connection behavior as one security boundary.
The repair pins the validated IP address into the cURL connection while retaining certificate verification and the original TLS server name. Redirect following is disabled. The important property is that the address actually contacted remains constrained by the decision made during validation. Otherwise an initially acceptable hostname could become a route into an internal service before the request is sent.
The evidence used controlled rebinding scenarios and a pre-repair comparison to demonstrate the difference. Earlier testing also uncovered bracketed IPv6 addresses escaping the intended classification path. These findings show why ordinary successful HTTPS delivery is not enough to close the feature. Negative controls must establish what the worker refuses, while production-host egress behavior remains an environment-specific check.
Concurrency, Leases and At-Least-Once Delivery
The webhook outbox separates deciding that an event should be delivered from performing the network request. Workers claim jobs under a lease, deliver them and record the outcome. A bounded work limit should govern each worker’s execution without turning concurrent workers into duplicate claimants for the same available job. Failed or interrupted work also needs a route back to execution.
The repair test placed four workers in contention over twenty-four jobs. The returned evidence recorded twenty-four deliveries with twenty-four distinct keys and no duplicates in that run. Another scenario reclaimed a crashed lease using the same job identity. These tests address both normal competition and recovery after a worker disappears before completing its responsibility.
The contract remains at-least-once. If a recipient completes its side effect and the acknowledgement is lost, retrying can be correct even though the recipient has already acted. The receiving system must use the stable idempotency identity to prevent a second business effect. Later recipient proof exercised atomic deduplication; it did not convert a distributed network into a promise of exactly-once transport.
Desktop Isolation and the Free Boundary
Electron introduces a boundary between the rendered interface and privileged desktop operations. The Free edition must retain its export restrictions when a caller reaches the preload bridge directly or places an altered campaign on disk. The repaired edition assertion establishes the condition before export generation, and regression coverage exercises more than the visible form controls.
Sandbox verification was also corrected during the build. An earlier launch used a no-sandbox switch while the report overstated the protection. The switch was removed, and the suite now checks the process state. The Linux execution used the supported sandbox arrangement and a non-root run; passing those checks does not establish that a packaged Windows application has passed its own installation and runtime checks.
Windows delivery remains a distinct final-mile responsibility. Source archives, an Electron development launch and a packaging plan are useful prerequisites, but none is the installer. The required release evidence includes an actual Windows build, the expected distributable artifacts, packaged application startup and installation behavior on a suitable runner. This distinction prevents a tested development tree from being mislabeled as a finished desktop download.
Deployment Package and Hosting Boundary
The reviewed deployment candidate separates public HTML, browser assets, admin files and API entry points from private application code and environment configuration. Packaging uses an explicit allowlist so a convenient archive of the repository does not become the public website. The approved overview page is carried into the package without silently replacing its design or embedded brand asset.
Subdirectory hosting is part of the application’s real deployment shape. The admin and API need to agree on the application base path, and route stripping must respect path segments rather than removing a similar-looking prefix indiscriminately. The reviewed package includes routing work for the intended application location and private bootstrap resolution outside the public directory.
Offline package validation covered archive integrity, file manifests and a clean deployment candidate. Actual Apache behavior, host configuration and production egress remain separate environment questions. Cache policy also needs to distinguish fingerprinted assets from stable filenames: a long immutable lifetime is inappropriate for a loader or logo expected to change at the same URL. That hardening belongs to the current release work, not to a claim already closed by this case study.
Verification, Repairs and Evidence
The build uses multiple levels of verification: unit tests for isolated logic, integration tests for connected behavior, PHP tests against a real MariaDB instance and browser tests for user-facing flows. The reviewed Wave 8 return reported 457 passing tests across nine verification gates: 169 unit, 60 integration, 134 PHP and 94 browser tests. Those counts describe that candidate and its execution environment.
Independent review also checks artifact identity. Archive hashes, extracted file manifests and source-tree reconciliation determine whether the reviewer is examining the implementation that the executor reported. A claimed commit without reachable Git history is recorded as unverified rather than treated as a substitute for the actual file evidence. The accepted package is a specific candidate, not a floating assertion that the latest folder must be good.
Repair quality is assessed through failing regressions and explicit negative controls. The useful question is not just whether the fixed code passes, but whether the test demonstrates the original defect and then distinguishes the repair. Edition tampering, signature disagreement, DNS rebinding, concurrent claims and sandbox state each required evidence tailored to its own failure mechanism.
Build Governance: NEXT → REVIEW
The VPL build approach separates execution from adjudication. NEXT directs the executor to the saved active assignment. REVIEW asks the lead engineer to evaluate the returned artifacts against the assignment and acceptance criteria. The owner should not need to reconstruct commands from a conversation or transport large bundles between tools simply to keep the process moving.
Durable storage is part of completion. A source archive attached only to a transient response is not equivalent to a verified artifact in the project authority folder. The build encountered precisely that distinction during an earlier repair return. Subsequent recovery work treated persistence, readback and manifest reconciliation as deliverables, rather than administrative details to postpone after claiming completion.
Closed work stays closed unless a concrete regression or changed requirement reopens it. Open work needs a named next action and the evidence required to close it. For this project, an offline deployment candidate can pass while Windows execution remains blocked and production promotion remains unauthorized. This case study follows that same discipline by identifying what the engineering work demonstrates and what it has not yet established.
Practical Benefits and Honest Outcomes
For the campaign creator, the product replaces repeated timer construction with reusable configuration. For the visitor, a defined deadline and deliberate expired state make the offer easier to understand. For the operator, publication history and rollback provide a way to change behavior without losing the record of how the campaign evolved. For an integrator, signed events and stable delivery identities make downstream automation more dependable.
The Free and Paid split also creates a coherent adoption path. Someone can begin with a locally authored countdown and a redirect destination, then move to managed publication and persistent behavior when those controls become useful. The feature boundary must remain explicit in the product experience, source enforcement and documentation so the giveaway is useful without being confused with the managed service.
No conversion percentage, revenue improvement, production uptime record or customer adoption count is claimed here. Those outcomes require actual usage and measurement after release. The demonstrated result is an implemented two-edition system with reviewed repairs and a verified offline deployment candidate, accompanied by concrete remaining gates. That is a meaningful engineering outcome without borrowing credibility from business results that have not yet been measured.
Release Readiness and Remaining Work
The reviewed state has completed Free source work, Paid implementation, webhook repair proof, admin visual repair and offline deployment packaging. The latest release-hardening assignment addresses password-login request controls, cache behavior, hosting verification where access permits and corrections to Windows readiness documentation. A new executor return is required before those active items can be adjudicated as closed.
Windows installer and runtime validation require a suitable execution environment. Repository access remains unverified for the product’s durable remote anchor. Host-specific staging and final independent validation must be tied to the actual candidate being considered for release. The planned Gemini and DeepSeek review through Magai is a validation stage, not a runtime dependency and not a completed approval implied by displaying those technologies.
The public giveaway flow also has deliberately deferred integration work. Lead capture and a real downloadable desktop artifact must be connected before the public page can truthfully deliver the complete advertised journey. Production promotion follows review and authorization. Publishing this architecture case study does not deploy the application, authorize a release or silently resolve those remaining delivery obligations.
mycountdowntimer Technologies
These project-specific components supplement the retained VPL technology catalog below. PHP, MySQL, HTML, CSS, JavaScript, Git, cURL and Apache connect the application to the broader web stack already illustrated in that catalog. The badges below identify implementation tools; all artwork is inline and requires no logo download.
TypeScriptShared contracts, core logic and browser applications
ReactPaid admin and application interface composition
ElectronFree Desktop shell and privileged bridge
ViteBrowser and admin build tooling
ZodCampaign schemas and input validation
Node.jsBuild scripts, tooling and test harnesses
pnpmWorkspace and locked dependency installation
VitestUnit and integration regression suites
PlaywrightBrowser flows and visual/runtime checks
MariaDBReal database used in integration verification
libsodiumSecretbox sealing for webhook signing secrets
NSISPlanned Windows installer delivery
WindowsDesktop packaging and runtime target
Apache / .htaccessPHP hosting and routing; host verification pending
cURLPinned HTTPS delivery for managed webhooks
PushoverRetained reference technology; MyFlightWatcher alerts, not an MCT integrationAI-assisted development and independent review
Claude supports implementation and repair; GPT provides lead review and adjudication; Cursor is part of the intended build and delivery workflow. Gemini and DeepSeek through Magai are designated for final independent validation. Their inclusion describes the workflow and does not claim that final validation has run. Uiverse supplied design-reference direction; redistribution of source design-pack assets is not implied.
Hostinger is the intended PHP hosting environment. Google authentication is an implemented but currently hidden access path whose live verification remains open. GitHub is the intended durable remote and potential Windows runner location; a verified repository and runner are still required before the Windows gate can close.
