FireAndStorm Desktop QA Report

Full report

On this page

Executive summary

The portal has a promising role-based structure on the apex host (fireandstorm.com): the public demo is clearly labeled as a demo, uses DEMO-... claim references, repeats that submissions are unavailable, and provides working return paths such as Switch Role, Exit, and Back to dashboard. That part of the experience is comparatively disciplined and safe. The biggest release blocker is the user-facing host the test began on, https://www.fireandstorm.com/: from that entry point, the main Property Owner Login, Contractor Login, Contractor Registration, Adjuster Login, Adjuster Registration, and Internal Admin Review links return 404s, which breaks most primary portal journeys before a user can authenticate or request access.

Beyond the host/routing problem, the next highest-priority concerns are trust and accessibility. The homepage explicitly says that “longer context stays in hover text,” which creates an avoidable keyboard/touch accessibility gap. The login and request-access pages look like unfinished shells rather than production-ready forms, and no visible privacy or terms links surfaced on the tested data-collection pages. I also found a public-facing admin login entry point and search-engine-visible technical demo route names that expose internal-ish vocabulary.

Highest-priority fixes are clear: make www and apex resolve the same way or redirect one host to the other; replace shell-like auth/request pages with production-ready recovery, help, and policy content; move essential portal guidance out of hover-only treatment; and reconsider whether an internal admin entry should be linked from the public homepage at all.

Tested areas

I started at https://www.fireandstorm.com/, then verified the same homepage on the apex host https://fireandstorm.com/ to isolate the host-specific breakage. From there, I mapped the main role routes exposed by normal navigation: Property Owner Login and Access Request, Contractor Login and Registration, Insurance Adjuster Login and Registration, the external public-site handoff, Live Demo Workspace, and Internal Admin Review. On the working apex host, I also followed Return to portal chooser, Switch Role, Exit, and Back to dashboard paths.

I inspected the public demo chooser, all three demo role dashboards, and the role-specific claim-detail previews for contractor, adjuster, and property owner. Those pages exposed the preview forms and states the user asked about: upload evidence, gallery preview, onboarding, invoice form, evidence review, estimate review, request information, photo/receipt upload, visit scheduling, and owner estimate/payment visibility. I did not submit any live forms or perform any write action.

The browsing environment exposed desktop-rendered page content, but it did not reliably provide text entry, bitmap screenshots for HTML pages, or guaranteed pixel-accurate viewport forcing. As a result, I could inspect visible structure, copy, links, labels, and route behavior, but not fully validate live field-level error messaging, loading states, or exact 1920×1080 and 1366×768 layout behavior.

Findings table

Detailed findings

The evidence below uses cited page excerpts. This environment did not provide bitmap screenshots for HTML pages, so each finding includes a screenshot description rather than a file name.

Broken auth links on the www host

ID: FS-01 Severity: High Page URL: https://www.fireandstorm.com/ and linked auth/admin routes Browser/viewport: Desktop browser, approximately 1440×900

Steps to reproduce: Open https://www.fireandstorm.com/. Click Property Owner Login, Contractor Login, Sign Up Contractor Registration, Insurance Adjuster Login, Sign Up Adjuster Registration, or Internal Admin Review.

Expected result: Every homepage CTA should open its matching auth or registration page on the same public host, or cleanly redirect to the canonical host.

Actual result: On the www host, those main CTAs return 404s. By contrast, the equivalent apex-host routes such as https://fireandstorm.com/property-owner/login, https://fireandstorm.com/contractor/register, https://fireandstorm.com/adjuster/login, and https://fireandstorm.com/admin/login load normally. Property Owner Access Request and Demo are the notable exceptions that do work from www.

Impact: This breaks the primary owner/contractor/adjuster/admin entry flows from the exact URL a public user is likely to type or click. It is a release-blocking defect because it prevents authentication and professional onboarding from the public homepage.

Suggested fix: Choose one canonical host and enforce it consistently. Either deploy all portal routes on both hosts or 301-redirect www to apex before the user ever clicks deeper links. Also add automated route checks for every homepage CTA.

Screenshot description: Homepage on www.fireandstorm.com showing role cards; clicking one of the main login/admin CTAs results in a 404 fetch failure, while the equivalent apex-host route loads a form shell.

Hover-dependent role guidance on the homepage

ID: FS-02 Severity: Medium Page URL: https://fireandstorm.com/ Browser/viewport: Desktop browser, approximately 1440×900

Steps to reproduce: Open the homepage and read the introductory copy above the portal cards.

Expected result: Important role-selection guidance should be available inline and equally accessible by mouse, keyboard, and touch.

Actual result: The page explicitly states that “longer context stays in hover text and the portal itself,” which means some role-selection guidance is intentionally hidden behind hover behavior.

Impact: Keyboard-only users, touch users, and some assistive technology users may not receive the same contextual guidance as mouse users, which can lead to wrong-portal selection or uncertainty.

Suggested fix: Move the “longer context” into visible helper text, disclosure panels, or focusable Learn more affordances that behave the same on mouse, keyboard, and touch.

Screenshot description: Portal chooser intro text above the role cards showing the statement that longer context remains in hover text.

Public forms look like unfinished shells

ID: FS-03 Severity: Medium Page URL: https://fireandstorm.com/property-owner/login, https://fireandstorm.com/property-owner/register, and equivalent contractor/adjuster/admin flows Browser/viewport: Desktop browser, approximately 1440×900

Steps to reproduce: Open any of the login or request-access/registration pages from the apex homepage.

Expected result: Production auth/request forms should provide clear instructions, required-field treatment, account-recovery/help options where applicable, and a visible explanation of what happens after submission or failed login.

Actual result: The pages present shell-like wording such as “This route has its own accessible form shell. Use public-safe contact and role details only,” then expose only minimal field labels like Email Password Login or Name or company Email Phone Public-safe access goal Submit request. I found no visible Forgot password, no visible help/support cue, and no visible required-field language on the tested pages.

Impact: These pages feel closer to prototypes than customer-ready flows. Users may hesitate to trust them, may not know whether fields are required, and may have no obvious recovery path if they forget credentials or need help.

Suggested fix: Replace the shell copy with user-facing language, add password-reset/help affordances, surface required-field treatment and validation conventions, and explain what approval/review looks like after a registration or access request.

Screenshot description: Login page showing only Email Password Login beneath shell-style helper text; registration page showing only Name or company Email Phone Public-safe access goal Submit request with no visible policy or next-step messaging.

Missing privacy and terms links on data-collection pages

ID: FS-04 Severity: Medium Page URL: Homepage, demo chooser, access-request flows, and admin login Browser/viewport: Desktop browser, approximately 1440×900

Steps to reproduce: Look for Privacy or Terms links on the homepage, demo chooser, request-access pages, and admin login shell.

Expected result: Pages that collect contact or login information, especially in a claims/evidence context, should visibly link to privacy and terms content.

Actual result: No visible Privacy or Terms links surfaced on the tested homepage, demo chooser, property-owner access request page, or admin login page. At the same time, the product positions itself around claim status, evidence, documents, appointments, estimate visibility, and professional review workflows.

Impact: This creates a trust and compliance gap. Users being asked to log in or request access to claim-related materials should not have to guess how their information or documents are handled.

Suggested fix: Add persistent footer or header links for Privacy Policy and Terms of Use on all public/auth pages, and include a brief data-handling note beside request-access forms.

Screenshot description: Property Owner Access Request page with fields visible but no nearby Privacy/Terms link; homepage and demo chooser likewise show no visible policy links.

Publicly exposed internal admin entry point

ID: FS-05 Severity: Low Page URL: https://fireandstorm.com/, https://fireandstorm.com/admin/login Browser/viewport: Desktop browser, approximately 1440×900

Steps to reproduce: Open the apex homepage and click Internal Admin Review.

Expected result: Staff-only admin entry points should usually be removed from public navigation, clearly separated, or at minimum more explicitly labeled as non-public.

Actual result: The public homepage includes an Internal Admin Review CTA, and the linked admin page loads a public login shell with Email Password Login.

Impact: This does not prove a vulnerability, but it does blur the audience boundary of the site and unnecessarily advertises an internal surface to public users and search engines.

Suggested fix: Remove the admin CTA from the public chooser, place it on a staff-specific subdomain or hidden entry point, or at minimum add stronger staff-only language and separate styling.

Screenshot description: Homepage role chooser showing Internal Admin Review as a public CTA, followed by the publicly reachable admin login shell.

Technical demo routes are publicly indexable and resolve inconsistently

ID: FS-06 Severity: Low Page URL: Search-visible routes including /demo/setup-snippet and /demo/export-packet-draft-manifest Browser/viewport: Desktop browser, approximately 1440×900

Steps to reproduce: Search the public web for same-domain FireAndStorm pages, then open /demo/setup-snippet.

Expected result: Technical or placeholder demo routes should generally not be indexable, and any public route that is indexable should resolve to a clear, purposeful user-facing page.

Actual result: Public search results expose route names such as Demo Setup Snippet and Demo Packet Draft Manifest, with snippets that use internal-ish language about blocked actions and raw JSON. Opening /demo/setup-snippet resolves to the generic portal chooser rather than a distinct page that matches its indexed title.

Impact: This creates SEO confusion, leaks implementation vocabulary that ordinary users should not see, and makes the public surface look unfinished.

Suggested fix: Add noindex to technical/demo helper routes, clean up route titles, and redirect dead/placeholder paths to the most appropriate canonical page with accurate metadata.

Screenshot description: Search result showing Demo Setup Snippet/Demo Packet Draft Manifest on the FireAndStorm domain, followed by /demo/setup-snippet rendering the generic portal chooser instead of route-specific content.

Homepage support discoverability is weak and branding is inconsistent

ID: FS-07 Severity: Low Page URL: Homepage and inner public portal pages Browser/viewport: Desktop browser, approximately 1440×900

Steps to reproduce: Compare the homepage with any inner public page such as Property Owner Access Request or Demo.

Expected result: A stressful claims workflow should surface consistent help/contact information at the homepage decision point, with consistent brand formatting across pages.

Actual result: I did not find a visible phone/help cue on the homepage, but inner public pages do show ☎ Call 1 (708) 230-2304. Those inner pages also render the brand header as Fire And Storm .com, which is inconsistent with the domain-style FireAndStorm.com branding used elsewhere.

Impact: The site asks users to choose the correct portal without presenting obvious support on the homepage if they are unsure. The inconsistent brand formatting slightly reduces polish and trust.

Suggested fix: Surface phone/help options on the homepage and normalize the brand string across all pages.

Screenshot description: Homepage without visible phone/help next to portal choices, contrasted with an inner public page header showing Fire And Storm .com and the phone number.

Accessibility notes

The most concrete accessibility concern I found is on the homepage itself: the site tells users that additional role guidance lives in hover text, which is not an acceptable place for essential decision-making content. I also did not find a visible Skip link on the homepage, a registration page, or the demo/claim-detail pages I tested.

There are also a few positive signs. The working apex-host flows do expose visible return paths: forms have Return to portal chooser, demo dashboards have Switch Role and Exit, and claim-detail views have Back to dashboard. That should help keyboard and screen-reader users orient themselves if those affordances are properly coded. The demo also repeatedly states that submission is unavailable, uploads are disabled, and values are redacted/example-only, which is good explanatory practice.

The main unverified areas are focus visibility, exact tab order, modal focus trapping, live error announcements, and field-level validation behavior. The parsed page output also shows several standalone × close controls in the demo/claim views; those may be visually fine if they have hidden accessible labels, but that naming could not be confirmed here.

Security and privacy observations

I did not see obvious raw JSON, stack traces, or debug text exposed during normal navigation through the demo dashboards or claim-detail screens. That is good, and it aligns with the homepage’s explicit “no default raw JSON” messaging for the demo. I also did not see sensitive tokens or personal information embedded in the visible tested URLs; the demo uses role/scenario parameters and clearly demo-labeled claim references instead.

The demo data handling is also comparatively responsible. Each demo portal is marked Demo Mode, claim references are prefixed with DEMO-, and the pages repeatedly say that final submission is unavailable or disabled, with redacted/example values. I did not see obvious live production claim/customer data in the public demo flows I tested.

The passive concerns are boundary and discoverability related rather than exploit-related. Publicly advertising an internal admin login, exposing technical demo route names in search results, and splitting behavior between www and apex hosts all make the surface area look less intentional and may encourage unwanted probing even if no data is directly exposed.

Open questions

• Is https://www.fireandstorm.com/ supposed to be the canonical public entry point, or should all traffic redirect to https://fireandstorm.com/ before users interact with the portal chooser? The current split breaks most auth flows from www.
• Are the current login/request-access pages intentionally shipping as public “form shells,” or are they placeholders that still need production copy, recovery/help affordances, and validation states?
• Are Privacy Policy and Terms hosted elsewhere but simply omitted from these pages, or do they not yet exist for the portal?
• Should Internal Admin Review be reachable from the public homepage at all?
• Are technical routes like /demo/setup-snippet and /demo/export-packet-draft-manifest intended to be indexable, or should they be redirected/noindexed?
• A follow-on browser pass is still needed for safe field-entry validation, exact focus order, screen-reader-style labeling, and pixel-accurate desktop checks at 1920×1080 and 1366×768, because those elements were not fully observable in this environment.