Mobile App

Mobile App is a five-page website for a field-team application, built on a habit almost no app site has: the feature list says what the app cannot do. The working mechanism is a platform switcher — pick iOS, Android or web and all twelve features re-mark themselves available, partly or not yet, with the reason, rather than hiding what is missing.
Pages included

Home — hero on offline being the architecture rather than a feature, an amber band explaining why the feature table admits gaps, three kinds of team plus one who should not use it, a six-entry day written from the van rather than the dispatcher's desk, four figures including a zero for data sold, and three quotes including a two-star review that is still unresolved.
Features — the switcher: twelve features, each carrying its own per-platform state in data-ios, data-android and data-web plus a per-platform note. A live count says how many are fully available on the chosen platform. Then three reasons the table is honest, and a dark band on offline including what happens if the phone is lost.
Pricing — three plans with a monthly/yearly switch where each card prints both its own figures and the saving is derived, so the toggle cannot claim a discount the cards do not give. Then an included/never-charged pair of lists, a ten-row comparison table, and six money questions including a refusal to do enterprise pricing.
Privacy — eleven data fields named in a table with why, whether they leave the device and how long they are kept — including two rows for things that are never collected. A dark band on location: only while a job is open, with an indicator no admin can disable. Four rights with timings attached, and four named third parties beside a list of who gets nothing.
Download — install links with a note pointing at the features table first, honest requirements including install size and a day's offline storage, a four-step start where step four is "run one real day", a contact form for migrations, and five questions.

Design and style. Teal and amber on a pale mint, Urbanist over Inter, pill buttons, rounded cards, a translucent sticky header. The shared script carries the menu, the platform switcher, the billing toggle, accordions and a date guard — all vanilla and null-guarded, since it runs on every page.
Before you publish. Feature availability lives entirely in the three data- attributes on each row; the badge, the note and the summary count all derive from them, so there is one place to edit and no second list to keep in step. Plan prices live in data-month and data-year and are also written into the comparison table — change both. The privacy table is the most consequential page here: it is a public statement about what your software does, so every row must be verified against the build rather than aspired to, and the two "never collected" rows must stay true even when a feature would be easier with that permission. The uptime figure, the app rating and the breach-notification promise are claims a user can check. Forms use named inputs with no action attribute, so PageHub attaches the handler on publish.
Best suited to mobile and SaaS products, field-service and logistics software, marketplace and delivery apps, and any product whose buyers are not its users — where stating the gaps is the only way the person choosing finds out before the team does.