HSLG Media

Scope and constraints

Scope and constraints

HSLG is a single branded customer application for Tap Yard, Tap Rooms, Flying Fleece, Flying Pig and Yewdale Inn. Each venue has distinct content and styling; the underlying customer UI and service contracts are shared. The current host is a pre-existing Virtualmin/Ubuntu server. The operator is developing and testing largely alone, without a standing engineering team or large recurring software budget.

What is optimised

  • One implementation of each screen minimises duplicate debugging and design work.
  • An independent web presenter allows rapid visual review without a native release.
  • Self-hosted MariaDB and WordPress reuse existing operating skills and avoid new account-platform subscriptions.
  • A replaceable REST/content boundary preserves the option to move away from WordPress later.
  • Automated checks reduce the number of regressions that one person must remember to inspect manually.

What is not optimised yet

  • Multi-restaurant offline replication, end-to-end payment operations and App Store distribution are not completed.
  • Automated tests are evidence only for the environments in which they ran.
  • Hosting costs are not zero: backups, security maintenance, email delivery, cloud iOS builds and payment processing can incur costs.

Decision authority

The project owner approves customer-flow and financial-product choices. Code may implement previously agreed behaviour but may not invent payment, privacy, messaging, provider or identity policy. Unknown details remain explicit TODOs.

The operating problem this project is solving

HSLG needs one customer application that can represent five distinct hospitality venues without requiring five separately maintained mobile applications. A person may discover a venue, inspect events, identify a table, review a menu, prepare an order, manage account details and eventually pay. Venue identity must remain visible throughout those actions; a table or basket must never silently move from one venue to another. The first deliverable is a working application and a safe self-hosted API, not an immediately distributed system.

The owner is doing the product work, testing, deployments and much of the operations alone. Every added runtime, SaaS subscription, domain, repository, signing credential, scheduler and database introduces maintenance overhead. The design therefore favours a small number of inspectable components, explicit interfaces between them, and executable gates that remember recurrent release checks. The objective is not to eliminate engineering work; it is to reduce the number of independent things that must be repaired after a change.

Boundaries and the reasons for each one

The shared customer UI lives in packages/app-ui; shared service contracts live in packages/app-core. This allows a presenter to display the same venue and ordering screens as the mobile app without duplicating screen markup and CSS. The presenter injects demonstrative services and may return fictional events and confirmations. The native runtime must inject real services and reject unsupported operations. This boundary costs additional adapter code but prevents a visually convincing demonstration from accidentally being treated as a purchase, reservation or authenticated session.

WordPress has three separate responsibilities: publish editorial venue content; host an independent HSLG API plugin; and host independently packaged presentation and documentation plugins. These packages should not share activation side effects. A documentation update should not execute a customer-schema migration; a presentation asset change should not change payment handling. Separate plugin ZIPs require more version checks, but failures are easier to isolate and reverse.

HSLG business tables use MariaDB through the WordPress database connection. WordPress's own posts, categories and users are not the authoritative identifiers for customers and orders. This avoids coupling future customer migrations to editorial IDs or WordPress account plugins. MariaDB is already available on the Ubuntu host. The saved cost is a second database service and its backups, alerting and security work; the trade-off is the need to carefully isolate schema names, authorization and query performance within one hosted installation.

Capacitor wraps the shared web application in a native Android/iOS host so that official device plugins can provide camera access, haptics, incoming application URLs and platform lifecycle events. Choosing Capacitor does not mean the app is an ordinary website running in a browser. A real deliverable requires a signed native project, installed plugins, OS permissions, an application ID, verified package contents and physical-device tests. An Android WebView-only preview proves little beyond layout and is never accepted as the mobile release.

Cost versus reward, including hidden costs

The main direct saving is reduced duplication: one interface change propagates to the browser demonstration and native app source. Another saving is using the existing Ubuntu/Virtualmin host rather than paying for a separate compute environment before user demand exists. WordPress provides familiar administration and revisions. The owner can review changes through an installable plugin and a real Android device instead of buying or configuring a large commercial development platform at this stage.

These savings do not make the system maintenance-free. The same human must patch WordPress, monitor certificates, protect database backups, handle spam and email delivery, maintain an Android SDK toolchain, and eventually supply an appropriate macOS environment for iOS. Service costs that depend on traffic or usage—payment fees, messages, offsite backups, app-store membership and SMS/WhatsApp providers—are not covered by the initial hosting decision. Budget planning must separate fixed hosting, periodic release work, and marginal per-transaction charges. Prices must be confirmed with current providers rather than embedded as timeless project facts.

For a solo operator, the most expensive failure mode is not a modest hosting invoice; it is hours spent remembering an undocumented sequence after a failed update. That motivates append-only history, deployment commands with captured output, release evidence and a single disaster-recovery manual. Automated tests reduce repeated manual work, but maintaining tests is a cost. The reward is faster safe iteration and clearer evidence of what is—or is not—working.

Rejected approaches and why they remain rejected for the MVP

Five independently coded branded applications would permit unrestricted differences between venues, but would multiply QA, App Store releases, accessibility reviews and urgent fixes. Separate early database servers or restaurant nodes would add replication, network trust, clocks and repair processes before a single live venue order can be placed. Replacing WordPress with a dedicated API platform immediately would need additional hosting and administration without solving the current missing native integration. Firebase-style managed identity or messaging is not required by the approved first release and would introduce new service dependency and data-policy review.

Conversely, merging every responsibility into one WordPress plugin would lower the ZIP count but make unrelated releases dangerous. Putting a development toolchain in public_html would make installation easier but expose build artifacts or secrets to a web-served path. Saving successful demo transactions in the native app would make screenshots impressive but would be deceptive. All three shortcuts are deliberately prohibited.

Staged delivery and acceptance evidence

The project is intentionally sequenced. First make the shared app and a single-server API work. Then connect real native hardware features, authenticated sessions, content and safe order drafts. Only once the provider architecture and server-owned pricing are verified should checkout use real payments. Finally consider offline multi-restaurant replication and encryption/versioning extensions. A TODO or a source adapter is not a completed feature; it requires a test in the environment where it actually runs.

The current milestone checkpoint has a browser demonstration, native adapter source, account and order API foundations, a generated Android project scaffold, documentation releases and local automated tests. It does not have a verified genuine Capacitor APK, live Stripe settlement, production-grade SQLite offline handling or iOS signed release. This separation matters in planning: 'implemented in source' and 'working on a phone' are different acceptance states.

For each milestone collect: a bounded source archive; the dependency and configuration versions; automated check output; relevant WordPress plugin ZIP; a concise human test script; and observations from the staging site or physical device. Financial acceptance additionally requires server reconciliation and repeat-request testing. A 'passed' browser screenshot cannot satisfy those native or financial requirements.

Decisions that must come back to the owner

The code may use existing agreed UI rules, but must not invent commercial terms or consent. The owner still needs to approve cross-venue payment account mapping, saved-card eligibility, loyalty accounting, staff redemption authority, reservations and messaging policy, verification channels beyond email, and personal-data retention/erasure rules. Each decision should be recorded with a date, the rejected alternatives, the affected source modules, deployment implications and a rollback or migration consideration. Until approval, a safe unavailable response is better than a default that creates a real financial or privacy obligation.

What to examine when reviewing this design

Start with hslg-architecture.json for the component boundary and package.json for workspace scripts. Then read packages/app-core/src/contracts/ for the capabilities the shared UI expects, apps/demo-runtime/ for fictional dependencies, apps/mobile/ for fail-closed native wiring, wordpress/hslg-app-api/ for the server endpoint registration and repositories, and wordpress/hslg-docs-publisher/ for the publication process. Check the documented milestone TODOs against executed tests; do not infer completion solely from the existence of a module.

This architecture is a compromise selected for a real operator and a real budget. Its success depends on protecting component boundaries and recording exceptions when a change is justified, not on keeping the original diagram untouched regardless of operating evidence.