Clarity before change.Independent website review
MyBishBash Photobooth
Website review
A full source-code and hands-on review of what MyBishBash Photobooth — our own product — ships, says and asks visitors to do.
Key judgement · At risk
The engineering here deserves a commercial layer that works: the rendering engine, the consent architecture and the pricing substrate are better than most funded products at this stage. What stands between them and revenue is three disconnected exits — fix those before anything else, including before the planned domain migration, which changes the address but fixes none of them.
https://raes-photo-booth.vercel.app/
Inspected 9 August 2026
White-box review · full source access (our own product)
What we noticed
A GreatInternet review of what MyBishBash Photobooth says, shows and asks visitors to do—based on full source access and hands-on sessions: it is our own product, reviewed to the standard we sell.
What we looked at
White-box audit: full source review (38 files, ~17,986 lines) plus hands-on sessions in the live product at desktop and mobile viewports as a first-time anonymous visitor, completed 9 August 2026. This pack translates that audit into our standard report contract; it is dated and presented as an assessment as of 9 August 2026, not a re-audit of the product as it stands today. Sample pack authored under our own methodology, the same one we sell: it is our own product, reviewed to the same standard as a customer's.
The short version
MyBishBash Photobooth is a genuinely good product with no working way to pay for it, no working way to contact anyone about it, and no way for a free user to be told why the thing they just spent five steps configuring did nothing. The rendering engine, the consent architecture and product.js are better than most funded products at this stage. The commercial layer is the problem, and it is not one bug: every paid tier dead-ends, every Business contact route 404s, and a completed free setup saves nothing.
The engineering here deserves a commercial layer that works: the rendering engine, the consent architecture and the pricing substrate are better than most funded products at this stage. What stands between them and revenue is three disconnected exits — fix those before anything else, including before the planned domain migration, which changes the address but fixes none of them.
The first useful move
Reconnect the contact mailto:, decide the checkout state, and stop the silent save from discarding a user's work — in that order, roughly a day of combined effort.
Overall signal
at risk
Genuinely excellent engineering craft (imaging, consent architecture, and product.js's price/capability separation all score 9/10 in the source audit) sits on top of a commercial layer that currently converts zero: every paid tier, every Business contact route and the free-to-paid save action are all disconnected, and the site sells to UK consumers with no terms or privacy policy.
What would strengthen it: Reconnect the three commercial exits (contact, checkout state, silent save) and publish terms/privacy/refund — both are scoped as near-zero-risk, independent of the planned domain migration, and mostly already specified in the source repository's own implementation tracker.
Significant evidence indicates this area may undermine customer confidence, outcomes, or business performance.
The useful diagnosis
Biggest opportunity
Clicking any of the three paid plans renders "This service is not available yet." with class checkout-status error. curl to /v1/plans returns 404, identical for all three plans.
Directly reproduced live and confirmed by a same-day curl check of the billing endpoint.
Biggest risk
All four "TALK TO US" CTAs resolve to https://mybishbash.app/contact, which returns 404. Site-wide there are zero mailto: and zero tel: links.
Directly confirmed by curl across all four CTA locations; the domain itself is live, isolating the fault to this one path.
Additional legacy finding
Completing all five steps of the Customise My Booth flow and clicking Save produces no visible message and writes nothing to localStorage.
Directly reproduced live with a concrete before/after localStorage check.
Additional legacy finding
Clicking START PHOTOBOOTH with the camera unavailable fires a native dialog reading "Please allow camera access in Safari and try again." — regardless of the actual cause.
The failure and its cause are directly evidenced in source; the in-app-browser behaviour itself is explicitly [verify by hand] in the audit, since the audit browser cannot reproduce in-app browser restrictions.
One immediate recommendation
Reconnect the three disconnected commercial exits — contact, checkout, and the silent save — before any other work.
Publish terms, privacy and a refund notice before the first live transaction.
Reprice Personal around the event, not the subscription duration, and show the real free-vs-paid difference on the pricing card.
Full website audit
| Dimension | Band | What we saw | What would raise it |
|---|---|---|---|
| Positioning | sound | The hero, honest live-rendered demos and clear structure are strong marketing craft (7/10 in the source audit); undermined by a mobile-nav defect that lands directly on the hero and a paywall that leads with its weaker lever. | Fix the mobile-nav overlap (F-21) and lead the pricing card with the real event-name differentiator (F-23), both already specified and low-effort. |
| Journey & conversion | at risk | Every commercial exit is disconnected: all three paid tiers dead-end, all four Business contact CTAs 404, and a free user's completed setup work is silently discarded on save. The source audit scores commercial completeness 0/10. | Reconnect the three exits in the order the audit recommends: the contact mailto: first, the checkout decision second, the silent save third — collectively close to a day of work. |
| User experience | needs attention | The rendering engine and core booth experience are excellent (9/10 imaging craft in the source audit); every failure mode in the product is silent rather than explained, from the discarded save to the one-size-fits-all camera alert. | Ship the two forgiveness fixes already specified: name the reason at every point of denial (F-03, F-04, F-12), branch the camera alert on the real error. |
| Trust | needs attention | The consent architecture is genuinely excellent and correctly built (9/10 in the source audit) — but the site sells £30-£100 to UK consumers with no terms, privacy policy or refund notice anywhere, and the entitlement enforcement is client-side. | Publish terms, privacy and a refund/cancellation statement (already drafted, per the source repository's tracker, pending only a legal classification decision) and decide the entitlement-enforcement posture explicitly rather than by accident. |
| Content & clarity | needs attention | Personal pricing is framed in subscription months for a one-evening event, and the pricing card leads with the weaker of its two real differentiators — both are copy/framing fixes, not rebuilds. | Reprice around the event, not the duration (F-22), and put the two covers side by side on the pricing card so the real differentiator is shown, not described (F-23). |
| Mobile | needs attention | A 2.23 MB image is 96% of the page weight on the connection profile most guests actually have, the mobile nav overlaps the hero, and 22 demo controls fall under Apple's touch-target guidance on the surface that does the selling on mobile. | Crop and re-encode the demo image (F-17, expected ~2.23 MB -> under 200 KB), fix the nav containing-block bug (F-21), and raise the demo chips to 44px (F-25) — all independently shippable in hours to days. |
| # | Severity | Finding | Effort |
|---|---|---|---|
| 01 | high | [F-01, source severity Blocker] Every paid tier says the shop is shut | medium |
| 02 | high | [F-02, source severity Blocker] The Business funnel has no contact route at all | low |
| 03 | high | [F-03, source severity Blocker] Customise My Booth silently discards a free user's work | medium |
| 04 | high | [F-04, source severity High] One Safari-flavoured alert for six different camera failures | low |
| 05 | high | [F-05, source severity High] A shareable product with nothing to share | low |
| 06 | medium | [F-06, source severity Medium] /business is metadata-identical to / | medium |
| 07 | medium | [F-07, source severity Medium] No robots.txt, no sitemap.xml | low |
| 08 | medium | [F-08, source severity Medium] Unbranded, unnavigable 404 | medium |
| 09 | high | [F-09, source severity High] The domain move strands every existing user | high |
| 10 | medium | [F-10, source severity Medium] Legacy grandfathering will silently expire at the new origin | medium |
| 11 | low | [F-11, source severity Low] Founding scarcity is asserted, never evidenced | low |
| 12 | high | [F-12, source severity High] No upgrade route exists at any point of denial | medium |
| 13 | high | [F-13, source severity Blocker] Selling to UK consumers with no terms, privacy policy or refund notice | medium |
| 14 | medium | [F-14, source severity Medium] Privacy claims are made in marketing but nowhere binding | low |
| 15 | medium | [F-15, source severity Medium] A localStorage key unlocks Personal | high |
| 16 | medium | [F-16, source severity Medium] Entitlement is a browser variable | high |
| 17 | high | [F-17, source severity High] 2.23 MB of PNG is 96% of the page | low |
| 18 | low | [F-18, source severity Low] Three <h1> elements in one document | low |
| 19 | high | [F-19, source severity High] /photobooth without a trailing slash breaks every asset | high |
| 20 | medium | [F-20, source severity Medium] /business needs a rewrite the parent domain does not yet have | medium |
| 21 | high | [F-21, source severity High] Mobile nav detaches from the header and lands on the hero | low |
| 22 | high | [F-22, source severity High] Personal sells six months of a one-evening event | low |
| 23 | high | [F-23, source severity High] The paywall undersells itself | low |
| 24 | medium | [F-24, source severity Medium] Kicker labels fail AA contrast | low |
| 25 | medium | [F-25, source severity Medium] 22 sub-44px touch targets on the interactive demo | medium |
| 26 | low | [F-26, source severity Low] No skip link | low |
What we noticed · 1
high confidenceConversion · Commercial · Commercial
Clicking any of the three paid plans renders "This service is not available yet." with class checkout-status error. curl to /v1/plans returns 404, identical for all three plans.
What the evidence shows
Live reproduction on the production site plus a curl check of the billing API.
Evidence
“app.js:1534 (startCheckout); index.html:12 (empty photobooth-api-base meta); worker/ (written, 14/14 tests passing, not deployed)”
Likely root cause
Appears to be: startCheckout posts to /v1/billing/checkout, but API_BASE resolves to "" because the photobooth-api-base meta tag is empty, so the request goes same-origin to Vercel, which serves static files only. The Worker exists and is tested but is not deployed.
Based on publicly available evidence; not verified.
Where it happens
100% of prospective paying customers, at the moment of trying to pay
Why it matters
The site advertises three prices and can sell none of them; every purchase attempt ends in an unresolvable error.
Worth doing next
Either deploy the Worker and proxy /v1, or — if that is not imminent — replace the price CTAs with an email-capture waitlist. Advertising a price you cannot take is worse than advertising no price.
high confidence
Directly reproduced live and confirmed by a same-day curl check of the billing endpoint.
What we noticed · 2
high confidenceConversion · Commercial · Commercial
All four "TALK TO US" CTAs resolve to https://mybishbash.app/contact, which returns 404. Site-wide there are zero mailto: and zero tel: links.
What the evidence shows
curl -L against the contact URL from all four CTA locations; a full link inventory of both surfaces.
Evidence
“index.html:11 (business-contact-url meta pointing at a page that has never existed)”
Likely root cause
Appears to be: The contact URL was set in metadata before the page it points to was ever built.
Based on publicly available evidence; not verified.
Where it happens
Every Business prospect, the highest-value tier
Why it matters
The entire Business sales funnel terminates in a 404; not one enquiry can currently reach the business.
Worth doing next
Point at a mailto: today — it costs one line and cannot 404. Build the contact page before the Business surface gets any traffic.
high confidence
Directly confirmed by curl across all four CTA locations; the domain itself is live, isolating the fault to this one path.
What we noticed · 3
high confidenceConversion · Trust · Core journey
Completing all five steps of the Customise My Booth flow and clicking Save produces no visible message and writes nothing to localStorage.
What the evidence shows
Live reproduction: typed a real event title, saved, and confirmed Object.keys(localStorage) returned [].
Evidence
“app.js:1494 (savePersonalSettings: bare early return with no user-facing consequence); app.js:1690-1691 (openPersonalSettings has no entitlement check at the entrance)”
Likely root cause
Appears to be: savePersonalSettings opens with a bare early return when the user lacks entitlement, while the entry points that open the setup flow carry no entitlement check at all — so free users are invited into a flow whose exit is silently disabled.
Based on publicly available evidence; not verified.
Where it happens
Every free user who engages with the Personal upsell — the most interested segment
Why it matters
The single worst bug in the product also destroys the work of its most engaged, closest-to-paying users, with no explanation.
Worth doing next
Move the gate to the save action itself: let free users configure everything, then convert Save into the paywall moment — they have already done the work and seen their own event name, the strongest possible moment to ask. That turns the worst bug into the best conversion point on the site.
high confidence
Directly reproduced live with a concrete before/after localStorage check.
What we noticed · 4
medium confidenceCore journey · Accessibility · Core journey
Clicking START PHOTOBOOTH with the camera unavailable fires a native dialog reading "Please allow camera access in Safari and try again." — regardless of the actual cause.
What the evidence shows
Live reproduction of the camera-denied path.
Evidence
“app.js:931 (single catch wraps the whole capture routine without inspecting err.name)”
Likely root cause
Appears to be: A single catch handles NotAllowedError, NotFoundError, NotReadableError, an insecure context, a video.play() rejection and a gallery-write failure identically, with Safari-specific wording regardless of browser.
Based on publicly available evidence; not verified.
Where it happens
Every user whose camera fails to start, concentrated in in-app browsers
Why it matters
The product's real distribution channel is a link pasted into a WhatsApp or Instagram group; those open in in-app browsers that restrict getUserMedia and are not Safari — the most likely real failure mode is a guest being told to fix Safari inside Instagram.
Worth doing next
Branch on err.name, replace the native alert with in-page state, and add an explicit "open in Safari/Chrome" route for in-app browsers.
medium confidence
The failure and its cause are directly evidenced in source; the in-app-browser behaviour itself is explicitly [verify by hand] in the audit, since the audit browser cannot reproduce in-app browser restrictions.
Verification · Reproduced
The behaviour was observed again on re-check.
What we noticed · 5
high confidenceConversion · Discoverability · Discoverability
og:* tag count: 0. twitter:* tag count: 0. No canonical link. Zero JSON-LD blocks, on either surface.
What the evidence shows
Enumerated every <meta> tag on both the Personal and Business surfaces.
Evidence
“index.html:3-17 (hand-authored <head> with no social metadata added)”
Likely root cause
Appears to be: Social metadata was never added when the head was authored.
Based on publicly available evidence; not verified.
Where it happens
Everyone who receives a shared link — the primary acquisition path for a party product
Why it matters
A link pasted into the exact channel this product is distributed through (a group chat) renders as a bare, unbranded URL rather than the rich keepsake preview the product could show.
Worth doing next
Add a full og:/twitter: set with a rendered keepsake as og:image — the product already generates the exact image that should sell it.
high confidence
A complete, direct enumeration of every meta tag on both surfaces.
What we noticed · 6
high confidenceDiscoverability · Discoverability
document.title and the meta description on /business are byte-identical to the homepage, and neither surface has a canonical link.
What the evidence shows
Direct inspection of both routes' document head.
Evidence
“vercel.json (both routes serve the same static index.html; the client selects a surface at runtime and nothing updates the head)”
Likely root cause
Appears to be: Both routes serve one static document and pick a surface client-side, with no per-surface head update.
Based on publicly available evidence; not verified.
Where it happens
Search engines and link-preview crawlers indexing either surface
Why it matters
Search results and shared links cannot distinguish the Business surface from the Personal one.
Worth doing next
Set title/description/canonical/og: per surface on route selection.
high confidence
Directly evidenced by inspecting both routes' rendered head content.
What we noticed · 7
high confidenceDiscoverability · Discoverability
Both /robots.txt and /sitemap.xml return 404, text/plain, 79 bytes.
What the evidence shows
Direct request to both paths.
Evidence
“No robots.txt or sitemap.xml present on the deployment”
Likely root cause
Appears to be: Neither file was ever added.
Based on publicly available evidence; not verified.
Where it happens
Search engine crawlers
Why it matters
Search engines have no explicit crawl guidance or sitemap for the site.
Worth doing next
Add both at the final domain, not before — they should name mybishbash.app/photobooth.
high confidence
Directly confirmed by request.
What we noticed · 8
high confidenceCore journey · Core journey
A mistyped path returns a bare 404, content-type text/plain, 79 bytes — no branding, no link home.
What the evidence shows
Direct request to a nonexistent path.
Evidence
“vercel.json declares three explicit rewrites and no catch-all, so unmatched paths fall through to the platform default”
Likely root cause
Appears to be: No catch-all route or branded error page is configured.
Based on publicly available evidence; not verified.
Where it happens
Any visitor who mistypes or follows a stale link
Why it matters
A lost visitor gets no path back into the product, and this gets more likely once the site moves under a subpath.
Worth doing next
Ship a branded 404 that routes back to the booth.
high confidence
Directly confirmed by request.
What we noticed · 9
high confidenceArchitecture · Trust · Architecture
All persistence (settings, gallery, edition counter, access token) is scoped to localStorage/IndexedDB on the current origin. Moving to mybishbash.app/photobooth is an origin change, and browsers scope both storages by origin.
What the evidence shows
Source review of every persisted key and its storage mechanism.
Evidence
“app.js:95-100 (SETTINGS_KEY, ACCESS_KEY, GALLERY_DB, EDITION_KEY, all origin-scoped)”
Likely root cause
Appears to be: The existing migration path is a same-origin key rename with no cross-origin equivalent; one is not possible without an explicit export/import or a server round-trip.
Based on publicly available evidence; not verified.
Where it happens
Every current organiser and returning guest, at the moment of the domain migration
Why it matters
Paid access is recoverable via the existing email restore flow, so money is not lost — but settings, gallery and the edition counter have no recovery path and will simply be gone.
Worth doing next
Ship export/import of settings before the cutover, keep the old origin serving a redirect plus a one-time "move your booth" hand-off, and decide explicitly whether the gallery is worth carrying.
high confidence
Directly evidenced by a complete inventory of every persisted key and its storage scope.
What we noticed · 10
high confidenceArchitecture · Architecture
legacyProfileAvailable is derived from a localStorage key that will not exist on mybishbash.app.
What the evidence shows
Source review of the grandfathering flag's origin.
Evidence
“app.js:161 (legacyProfileAvailable derived from localStorage.raePhotoBoothLiveSettings)”
Likely root cause
Appears to be: The same origin-scoping issue as F-09, applied to the grandfathering signal specifically.
Based on publicly available evidence; not verified.
Where it happens
Existing legacy free users who currently have Personal unlocked
Why it matters
Whether legacy users keep their unlocked status after the move will be decided by accident rather than on purpose, unless it is made an explicit decision.
Worth doing next
Decide deliberately: either carry grandfathering across in the hand-off, or end it and say so.
high confidence
Directly evidenced; the same origin-scoping mechanism as F-09.
What we noticed · 11
high confidenceTrust · Commercial · Commercial
The page claims "Limited to the first 500 Founding Lifetime customers", but the endpoint that would populate the live remaining count 404s, so the claim never loads real data.
What the evidence shows
Source review of the founding-availability loader and its endpoint.
Evidence
“loadFoundingAvailability() calls /v1/billing/founding, which 404s (same undeployed-Worker root cause as F-01)”
Likely root cause
Appears to be: The undeployed Worker (same as F-01); the static fallback is a reasonable degradation of an otherwise verifiable claim.
Based on publicly available evidence; not verified.
Where it happens
Any visitor who reads the founding-scarcity claim
Why it matters
An unevidenced scarcity claim is weaker than none — especially one that is verifiable by design once the Worker is live.
Worth doing next
Once live, show the real remaining number; until then, remove the unevidenced scarcity line.
high confidence
Directly evidenced; the remaining-count mechanism is explicitly designed to be verifiable once deployed.
What we noticed · 12
high confidenceConversion · Commercial · Commercial
The only paths to pricing are the plan-choice button and one post-checkout scroll; nothing in the settings screen, the booth, or the free branding notice links to pricing.
What the evidence shows
Source review of every link and CTA that could plausibly lead to pricing.
Evidence
“app.js:1581, app.js:1689 (the only two paths to pricing in the entire product)”
Likely root cause
Appears to be: Denial is implemented as silent absence rather than as a named offer, at every point a free user hits a locked capability.
Based on publicly available evidence; not verified.
Where it happens
Any free user who hits a locked capability anywhere except the two named entry points
Why it matters
The product misses the moment a user has just discovered a reason to pay, repeatedly.
Worth doing next
Every locked capability should name its plan and link to it.
high confidence
Directly evidenced by a complete inventory of pricing-linking CTAs.
What we noticed · 13
high confidenceTrust · Compliance · Compliance
/privacy and /terms both 404, and neither is linked from either footer, while the site advertises £30-£100 purchases and the Business surface describes collecting email addresses and consent records.
What the evidence shows
Direct request to both legal-page paths; full footer link inventory on both surfaces.
Evidence
“No terms, privacy or refund/cancellation notice present anywhere on the site”
Likely root cause
Appears to be: The compliance layer was never built — not a considered trade-off.
Based on publicly available evidence; not verified.
Where it happens
Every prospective UK purchaser, and every Business prospect whose data the site would collect
Why it matters
UK Consumer Contracts Regulations require pre-contract information and cancellation rights for distance sales, and a privacy policy is required once personal data is processed; Stripe's own account review also expects reachable terms and privacy URLs — this can block the payment integration F-01 is waiting on.
Worth doing next
Publish terms, a privacy policy and a cancellation/refund statement, linked from both footers, before the first live transaction. The product has a genuinely strong position to write from: photos never leave the device on Free and Personal.
high confidence
Directly confirmed by request against both legal-page paths and a complete footer link inventory.
What we noticed · 14
high confidenceTrust · Compliance · Compliance
The landing page states "Photos stay on your device. There is no backend photo upload." — true and well-evidenced in code — but it exists only as marketing copy, with no policy document behind it.
What the evidence shows
Source review confirming the claim is accurate, alongside confirmation no privacy policy exists to formalise it (see F-13).
Evidence
“Landing-page copy asserting local-only photo storage, with no corresponding privacy policy document”
Likely root cause
Appears to be: The compliance layer (F-13) does not exist yet, so a true, well-evidenced technical claim has nowhere binding to live.
Based on publicly available evidence; not verified.
Where it happens
Any visitor evaluating the privacy claim before trusting the product with photos
Why it matters
The product's best trust asset is currently its least durable — a claim rather than a commitment.
Worth doing next
Promote the claim into the privacy policy, where it becomes a commitment rather than marketing copy.
high confidence
The underlying technical claim was directly verified in source; the absence of a binding document is confirmed by F-13.
What we noticed · 15
high confidenceCommercial · Commercial
The Personal gate is client-side and OR'd with a legacyProfileAvailable flag read from a localStorage key any visitor can write from the console; confirmed writable on the live origin.
What the evidence shows
Source review of the gate condition plus a live confirmation the key is writable.
Evidence
“app.js:435, app.js:1495, app.js:1503 (gate condition); app.js:161 (legacyProfileAvailable read from a client-writable key)”
Likely root cause
Appears to be: A legitimate grandfathering decision (recognise genuine legacy users) was implemented with a client-writable signal that trusts any browser claiming to be one.
Based on publicly available evidence; not verified.
Where it happens
Any visitor who opens the browser console on the live product
Why it matters
For a £30 consumer product this is a low-value target and not uniquely weak (all Personal enforcement is client-side, see F-16) — it is listed because the grandfathering intent and its mechanism have drifted apart into an undocumented honour system.
Worth doing next
Grandfather by issuing real entitlements to known legacy users, or accept the bypass explicitly as a documented decision.
high confidence
Directly confirmed live: the key was writable and the gate condition read it as designed.
What we noticed · 16
high confidenceArchitecture · Commercial · Architecture
Entitlement is module state hydrated from a localStorage value and refreshed against a restore endpoint; branding policy is selected from it at render time.
What the evidence shows
Source review of the entitlement hydration and branding-selection path.
Evidence
“app.js:162 (entitlement as module state); app.js:407 (branding policy selected from it at render time)”
Likely root cause
Appears to be: Inherent to a local-first static app, and largely the right trade for a £30 party tool — the honest framing is that export attribution is a courtesy, not a control.
Based on publicly available evidence; not verified.
Where it happens
Any determined user attempting to bypass branding or entitlement enforcement
Why it matters
The product pays some architectural cost for an enforcement pretence it cannot actually deliver client-side.
Worth doing next
Accept the trade explicitly and stop paying architectural cost for the pretence — or move export branding server-side for Business only, where white-labelling is worth money. Do not build DRM for a £30 party tool.
high confidence
Directly evidenced by source review of the entitlement and branding-selection code paths.
What we noticed · 17
high confidencePerformance · Mobile layout · Performance
A single demo image is 2,232,546 bytes of a 2,331,527-byte critical path — every other asset combined is under 100 KB. The same image at JPEG q82 is 335,630 bytes, an 85% reduction, and the service worker pre-caches the PNG, so every install pays the cost.
What the evidence shows
Measured uncached transfer sizes of every critical-path asset, plus a re-encoding test of the same source image.
Evidence
“assets/demo-photos.png (2.23 MB); sw.js:3 (pre-cached); marketing.js:10 (crops to 640 of 1024 downloaded rows — 37% of downloaded pixels never displayed)”
Likely root cause
Appears to be: The demo image was never optimised or cropped to the region actually used, and is shipped uncompressed relative to what the page displays.
Based on publicly available evidence; not verified.
Where it happens
Every mobile visitor, disproportionately at venues on poor data — exactly where a party photobooth link gets opened
Why it matters
The single largest asset on the page delivers zero pixels beyond what a correctly sized, correctly encoded image would, at roughly 10x the necessary weight.
Worth doing next
Crop to the 640 rows actually used and encode as WebP with a JPEG fallback; expect roughly 2.23 MB to drop under 200 KB with no visible change.
high confidence
Directly measured transfer sizes and a direct re-encoding test of the same source image.
What we noticed · 18
high confidenceAccessibility · Accessibility
Three separate <h1> elements exist in the DOM at once ("Your party. Your photobooth.", "Want your brand on the booth?", "Your Celebration") — only one visible at a time.
What the evidence shows
Direct DOM inspection.
Evidence
“All surfaces are .screen sections within a single document”
Likely root cause
Appears to be: All surfaces (Personal landing, Business landing, booth) live as sections of one document rather than distinct documents or dynamically managed headings.
Based on publicly available evidence; not verified.
Where it happens
Screen-reader users and search engines parsing document structure
Why it matters
Weakens the document outline for assistive technology and search indexing.
Worth doing next
Resolve alongside per-surface metadata (F-06).
high confidence
Directly confirmed by DOM inspection.
What we noticed · 19
high confidenceArchitecture · Architecture
Every asset reference is relative. At https://mybishbash.app/photobooth (no trailing slash) the document base is /, so styles.css resolves to /styles.css — wrong. At /photobooth/ it resolves correctly.
What the evidence shows
Source review of every relative asset reference and the service worker's asset list.
Evidence
“index.html:13-16 (relative href/src); app.js:1755 (register("./sw.js")); all 14 service-worker ASSETS entries”
Likely root cause
Appears to be: Relative paths are the right choice for a portable subpath app, but they make the trailing slash load-bearing, and nothing currently enforces it.
Based on publicly available evidence; not verified.
Where it happens
Everyone, from the moment the migration goes live, if the trailing slash is not enforced
Why it matters
The failure mode is a totally unstyled, non-functional page at first launch on the new domain.
Worth doing next
A permanent redirect from /photobooth to /photobooth/ at the parent domain, plus a <base> tag as a belt-and-braces guard, verified before cutover.
high confidence
Directly evidenced by a complete inventory of every relative asset reference.
What we noticed · 20
medium confidenceArchitecture · Architecture
Under the subpath, the relative link to /business resolves to /photobooth/business, which the parent domain must rewrite to the same document; there is no catch-all, so any other /photobooth/* path yields the bare 404 of F-08.
What the evidence shows
Source review of the current vercel.json rewrites plus a live navigation check.
Evidence
“vercel.json rewrites exactly /, /business, /business/ — no catch-all; index.html:30 (relative href="business")”
Likely root cause
Appears to be: The current rewrite list enumerates exact paths rather than a catch-all pattern.
Based on publicly available evidence; not verified.
Where it happens
Anyone navigating to /business or any other path once the site moves under /photobooth
Why it matters
The Business surface would 404 under the new subpath unless the parent domain's rewrite is updated first.
Worth doing next
Rewrite /photobooth/(.*) to the deployment and let the client route, rather than enumerating paths in two places.
medium confidence
The rewrite gap itself is directly evidenced; one hard navigation to /business timed out during the audit while curl returned 200 and client-side routing worked, so the audit flags this as instrument noise pending a manual recheck under the subpath.
Verification · Reproduced
The behaviour was observed again on re-check.
What we noticed · 21
high confidenceMobile layout · Mobile layout
At 375x812, the audience nav renders 71px below the header it belongs to, in a bordered box overlapping the hero kicker text. Confirmed by programmatic rect intersection.
What the evidence shows
Direct viewport measurement at 375x812 with a programmatic rect-intersection check.
Evidence
“styles.css:364 (.audience-nav{grid-row:2;grid-column:1/-1;position:absolute;top:72px} — for an absolutely-positioned grid item, the containing block is the grid area, not the grid container's padding box, so top:72px double-counts the header height)”
Likely root cause
Appears to be: The absolutely-positioned nav is also a grid item, so its containing block is its grid area rather than the container — a CSS positioning-model mismatch, not a design error.
Based on publicly available evidence; not verified.
Where it happens
Every visitor at 768px or narrower — the majority
Why it matters
A floating, overlapping navigation box sits directly on top of the hero copy for most mobile visitors, on the page whose entire job is to convert a first-time visitor.
Worth doing next
Drop grid-row/grid-column from the absolutely-positioned element, or use top:100% — the intended tab-bar-off-the-header design is correct, only the containing block is wrong.
high confidence
Directly measured and confirmed by programmatic rect intersection, with the exact CSS mechanism identified.
What we noticed · 22
high confidenceCommercial · Content clarity · Commercial
Personal pricing is duration-based (£30/6 months, £50/12 months, £100 lifetime), but the customer has one party — nobody has six months of birthdays, and pricing in months forces buyers to reason about a duration rather than the event they already scheduled.
What the evidence shows
Source review of PLAN_METADATA and a reasoned analysis of how a party host actually evaluates the purchase.
Evidence
“product.js:107-138 (PLAN_METADATA: £30/6mo, £50/12mo, £100 lifetime capped at 500)”
Likely root cause
Appears to be: Pricing was structured around subscription duration rather than the single-event use case the product actually serves.
Based on publicly available evidence; not verified.
Where it happens
Any prospective Personal buyer evaluating which tier matches their one event
Why it matters
The £30 tier is dominated on both price and duration by the £50 annual tier and exists mainly to anchor it, while the whole framing invites an unanswerable question ("will I still want this in month five?").
Worth doing next
Sell the event: "One event, £X" matches how the purchase is actually reasoned about, removes the expiry objection, and makes the upsell to Founding Lifetime a straightforward "host more than twice and this pays for itself." Keep Founding Lifetime unchanged.
high confidence
Directly evidenced pricing structure; the audit explicitly notes this is among the cheapest changes in the whole audit since pricing is presentational metadata by design (product.js's own separation of price from capability).
What we noticed · 23
high confidenceCommercial · Content clarity · Commercial
The Free pricing card promotes removing branding, but launchFreeBooth resets free users to a default event title of "Your Celebration" — so every free magazine cover is mastheaded "YOUR CELEBRATION" rather than the guest's actual party.
What the evidence shows
Source review of the free-booth default state and the cover-copy generation path.
Evidence
“app.js:1501 (launchFreeBooth resets to DEFAULTS); app.js:2 (eventTitle: "Your Celebration")”
Likely root cause
Appears to be: The pricing card leads with the weaker lever (removing branding) while the stronger, already-built lever (the guest's real event name on the keepsake) is never shown.
Based on publicly available evidence; not verified.
Where it happens
Any free user evaluating whether to upgrade to Personal
Why it matters
The real free/paid difference — a keepsake that says the guest's actual party name, not "Your Celebration" — is a far stronger reason to pay, and it is hidden.
Worth doing next
Show it, don't describe it: put the two covers side by side on the pricing card, the same comparison already built for the welcome screen, applied to the difference that actually sells.
high confidence
Directly evidenced by source review of both the default event title and the pricing-card copy.
What we noticed · 24
high confidenceAccessibility · Accessibility
The product-kicker pink-on-pill combination measures 3.60:1, below the 4.5:1 required for bold text under 18.66px.
What the evidence shows
Direct colour-contrast measurement of the rendered kicker element.
Evidence
“.product-kicker: rgb(217,45,127) bold 10px on its pink pill background”
Likely root cause
Appears to be: The kicker's pink was chosen without checking contrast against its own pill background at the size actually used.
Based on publicly available evidence; not verified.
Where it happens
Any visitor relying on text contrast to read section labels
Why it matters
A section-labelling element used across the marketing surfaces falls short of AA on every appearance.
Worth doing next
Darken the pink or lighten the pill.
high confidence
Directly measured contrast ratio against the WCAG threshold for the actual rendered size and weight.
What we noticed · 25
high confidenceAccessibility · Mobile layout · Accessibility
22 mobile controls measure under 44x44 CSS px, including all nine demo frame/filter chips at 29px tall.
What the evidence shows
Direct measurement of every interactive control on the mobile landing surface.
Evidence
“Demo frame/filter chips: White 42x29, Film 35x29, B&W 39x29 — all pass WCAG 2.2 SC 2.5.8's 24x24 minimum, but fall short of Apple's 44pt guidance”
Likely root cause
Appears to be: The demo chips were sized to fit visually rather than against a touch-target guideline.
Based on publicly available evidence; not verified.
Where it happens
Any mobile visitor using the interactive demo, which does the selling on mobile
Why it matters
The chips that demonstrate the product's actual output — the strongest selling moment on mobile — are the hardest controls on the page to hit accurately.
Worth doing next
Raise the chips to 44px.
high confidence
Directly measured every control; the audit is explicit this is a usability finding against Apple's guidance, not a WCAG 2.2 SC 2.5.8 failure (which these controls pass).
What we noticed · 26
high confidenceAccessibility · Accessibility
No skip-to-content link exists on any surface; keyboard users must traverse the full navigation on every surface change.
What the evidence shows
Direct keyboard-navigation inspection.
Evidence
“No skip-link element present in the DOM”
Likely root cause
Appears to be: A skip link was never added.
Based on publicly available evidence; not verified.
Where it happens
Keyboard users navigating between surfaces
Why it matters
Adds unnecessary keyboard traversal for a real, if small, share of visitors.
Worth doing next
Add a standard skip-to-content link.
high confidence
Directly confirmed by DOM inspection.
Accessibility note: This assessment identifies observed accessibility considerations from the tested evidence. It is not a formal accessibility conformance certification or legal opinion.
Technical note: Technical observations reflect the tested environment and evidence available during this assessment. Behaviour may vary by device, browser, session state or subsequent site changes.
Website Review & Implementation Pack
Pre-call strategic review pack
This is a pre-launch product with a genuinely excellent core engine and no working way to convert a single visitor into a customer. It is really selling a keepsake worth showing off, but every current path from interest to purchase or enquiry ends in silence.
What is most in the way: The governing constraint is sequencing, not craft: the engine, consent model and demo experience are already strong; the commercial layer was never finished, and the planned domain migration is being considered before the shop is even open.
Treat the contact mailto:, the checkout-state decision, and the silent-save fix as a single, ordered, near-zero-risk unit of work that lands before the mybishbash.app migration, not alongside or after it.
None of the three failures is caused by the current domain; migrating first means carrying all three onto the new domain and re-testing them there, while the new domain earns its first impressions on a site that still cannot take money or answer an email.
RequiresFounder agreement on the checkout decision (deploy the Worker now, or replace prices with a waitlist) — the one open call in this bet.
Expected outcomeA site that can actually convert a visitor, on either domain, within roughly a day of combined effort.
RiskIf the migration turns out to be more urgent for an external reason (a booked event, a brand deadline), this sequencing needs revisiting — but the source audit notes these three fixes travel with the code and are not invalidated by the move, so the reverse risk (migrating first) is not symmetric.
high confidence — All three underlying findings are directly reproduced and evidenced, and the sequencing argument is the audit's own explicit, single recommendation.
Write the terms, privacy and refund policy from the product's genuinely strong position — photos never leave the device on Free and Personal — rather than treating this as a delayed formality.
The product already has a strong, true privacy claim in its marketing copy with nothing binding behind it; formalising it turns the best trust asset in the product from a claim into a commitment, while also closing a real UK consumer-protection and Stripe-account-review exposure.
RequiresA decision on the legal classification of the paid event access (digital content, digital service, or licence/access right), which determines the exact cancellation-rights wording.
Expected outcomeA compliant checkout path and a strengthened, formalised privacy position, unblocking the payment integration.
RiskThe classification question is genuinely legal, not commercial, and should not be resolved by picking whichever category is commercially convenient.
high confidence — The compliance gap and the strength of the underlying privacy claim are both directly evidenced.
Reprice Personal around the single event the customer actually has, and replace the pricing card's "removes branding" pitch with a side-by-side comparison of the real keepsake difference (the guest's actual event name vs. "Your Celebration").
Both fixes are already fully specified, low-effort, and reversible — pricing is presentational metadata in a file explicitly designed so a price change grants nothing — and both directly address a scored 0/10 commercial-completeness gap without any redesign.
RequiresFounder agreement to keep Founding Lifetime unchanged while repricing only the entry Personal tier.
Expected outcomeA pricing page that matches how a party host actually reasons about the purchase, and a paywall that leads with its strongest lever.
RiskLow — the audit is explicit that this is among the cheapest, most reversible changes available.
high confidence — Both findings are directly evidenced pricing and copy structure, with the audit's own explicit cost-of-being-wrong assessment.
Included strategy conversation
Your access includes one strategy conversation to discuss your report.
Methodology & transparency
This report has been generated with the assistance of artificial intelligence using the evidence available at the time of assessment. GreatInternet applies a defined assessment methodology and presents observations, judgements and recommendations based on that evidence. AI-assisted output should be reviewed by an appropriate human decision-maker before material reliance or implementation.
Limitations