P0
User permission rules are unspecified
Sensitive role, membership and profile fields require verified protections and trusted privileged writes.
Verify platform defaults and enforce allowed self-service fields.
Source-based reviewLive configuration unverified
Keza Studio · Prepared for Mark Baxter · 6 October 2026
Nereus
technical audit.
A consolidated review of the product, architecture, security, payments and delivery path.
Conclusion
Productionise
Scope
15 routes
Test state
0 executed
Sources
4 originals
01Executive assessment
Substantial capability. Incomplete launch controls.
Nereus has a clear private fishing-intelligence proposition and broad reported functionality. The next stage is operational and technical maturity, not a complete rebuild.
Product
Broad reported coverage
Launch posture
Controlled programme required
Payments
Partially implemented
Evidence
Source-based, not live-tested
Recommendation
Our recommendation — your route to launch
We would not recommend rebuilding the application. However, we would not recommend launching it in its current state either.
Nereus already contains substantial functionality and payments are partially implemented rather than absent. Two P0 concerns — unspecified User permission rules and the hardcoded Elite tier — together with the absence of a staging and live release process, currently block a trusted paid launch.
Launching as it is today
- Every user resolves to Elite, so paid membership cannot generate reliable revenue
- User role, membership and profile protections are unverified
- Changes can break other parts of the app and are only discovered after publishing; no staging or rollback
- No business admin portal for user, support or subscription oversight
- 70 manual test cases specified, none executed; release readiness unassessed
Launching after Phases 1–3
- Trusted paid entitlement and a fully tested Stripe subscription lifecycle
- Isolated staging and live environments with a repeatable, traceable release pipeline and rollback
- Critical journeys, weather and maps dependable on agreed devices and in field conditions
- Admin V1 providing user, support and verified subscription visibility
- An evidence-based launch decision against defined exit gates
Do these three phases first
Phase 01
Admin & Platform Foundations
Admin portal V1, verified User/entity permissions, removal of production test helpers, hardened sharing fetches, staging and live deployment pipeline, version control, rollback, error monitoring and backup verification.
Exit gate
Privileged actions are backend-protected; users cannot alter roles or entitlement; releases can be tested and rolled back.
Phase 02
Core Application Stabilisation
Critical defects, weather and map reliability, input bounds, calculation consistency, complete onboarding, venue, session and sharing journeys, regression checks and sunlight readability.
Exit gate
Critical journeys pass on agreed devices; weather failures are understandable; session history persists; no data-loss or cross-account defects.
Phase 03
Complete & Productionise Payments
Trusted membership enforcement, Stripe price mapping, webhook lifecycle, customer billing management, plan benefits and limits, cancellation and upgrade/downgrade policy, verified subscription state in admin.
Exit gate
Full subscription lifecycle passes; paid permissions cannot be bypassed; admin billing agrees with Stripe; final prices approved by Mark.
Customer usability fixes required for launch may run during Phases 1–3.
Why this route
This route gives Nereus the best chance of success without significantly changing time, effort or cost. It builds on what already exists rather than starting again, and early subscription revenue can then fund the later phases.
What you can do next to go live
- 01Approve Phases 1–3 as the pre-launch scope
- 02Confirm final tiers, prices, benefits and limits
- 03Provide deployed access and Stripe test/live settings
- 04Agree supported devices and any essential minimum offline capability
- 05Approve the paid launch gate and a dated delivery plan
This audit also sets out how Nereus can grow into a deeper, world-class application through Phases 4–7 — outdoor UX, offline capability, intelligence and native apps. The current product is a strong MVP to get into the market; completing Phases 1, 2 and 3 before launching puts you in a far stronger position than launching as it stands today.
Important limitation
This assessment consolidates supplied evidence. It is not a fresh repository audit, penetration test or live checkout test.
02Product & application
The fishing loop is already materially represented.
The reported application covers venue planning, active fishing, logging, historical insight, sharing and subscription scaffolding across 15 routed screens.
01
Dashboard
Venue context and active-session entry
02
Map
24-hour and seven-day tactical map
03
Forecast
Condition alignment and weather blocks
04
Log
Venues, swims, spots and fishing history
05
Sessions
Captures, sightings and baiting activity
06
Insights
Capture, sighting and aggregate patterns
07
Pricing
Explorer, Intelligence and Elite plans
16
Page components
15
Routable screens
01
Unmounted OAuth page
The intended experience is private, tactical and readable at a glance. Intentional venue sharing should remain, but secure data isolation is central to the product promise.
03User journeys
Preserve the core loop. Correct trust and recovery gaps.
The source material separates current reported behaviour from proposed improvements. This view keeps that boundary explicit.
01
Public demo
02
Authenticate
03
Complete onboarding
04
Select venue
05
Plan with forecast
06
Start fishing
07
Record activity
08
Review patterns
Current = reported, not live-testedProposed = target behaviourRed = known gap
04Architecture & infrastructure
A reusable foundation with boundaries to harden.
How each part of Nereus connects today, from the angler's device through the managed backend to external providers.
Whole-system overview
Solid · built todayDashed · not yet builtRed · current limitation
Every component below is in place today except the Business admin portal, which is a proposed Phase 1 delivery.
Visitor / angler
- Mobile browser / PWA experience
- Public demo or authenticated use
opens app
React / Vite frontend
- React Router: 15 routed screens; 16 page components
- Dashboard, Map, Forecast, Log, sessions and insights
- React Query + auth / venue / map / weather contexts
- Tailwind, Radix UI, Recharts, Motion; PDF export
UI state →
Browser-side tools
- localStorage / sessionStorage caches
- React Leaflet map renderer
- jsPDF / html2canvas export
authenticated app requests
Base44 SDK
- Authentication, entity calls, functions and media
backend APIs
Base44 managed backend
- Auth and User identity
- Entities with owner-scoped rules on most models
- Functions: weather, alerts, sharing, checkout, webhook
- Workflows: telemetry capture and share expiry
- Hosted media / CDN
weather / billing →← protected APIs (proposed)
External providers
- Open-Meteo: weather / forecasting
- Mapbox: map service / tiles
- Stripe: subscription checkout and events
Business admin portal
Not yet built- Users, support and business metrics
- Trusted subscription / system health views
- Proposed Phase 1 delivery
membership consumed by UI
Important current limitation
- getUserTier() always returns Elite.
- Stripe exists; paid access is not enforced end to end.
Recommendation
Platform dependency on Base44
Current position
Nereus is currently heavily reliant on Base44 for several core parts of the application, including authentication, database entities, backend functions, workflows and hosted media.
AuthenticationDatabase entitiesBackend functionsWorkflowsHosted media
What this does not mean
This does not mean that Nereus should immediately be rebuilt or migrated away from Base44. At the current stage, doing so could introduce unnecessary cost, risk and delay. However, the level of dependency should be treated as a strategic technical consideration as the product moves towards commercial launch and future growth.
Main concern
The main concern is that a significant proportion of the application's backend infrastructure and operational logic is tied to a single platform. This can reduce flexibility if Nereus later needs greater control over infrastructure, scaling, pricing, deployment processes, advanced backend functionality or migration to a different technology stack.
- — Infrastructure control
- — Scaling
- — Pricing
- — Deployment processes
- — Advanced backend functionality
- — Migration to a different stack
We therefore recommend introducing a platform-dependency and portability workstream alongside the stabilisation programme.
05Security & data protection
Prioritise verification before exposure becomes incident.
The audit preserves the supplied P0, P1 and P2 classifications. Conditional risks require verification and correction; they are not presented as confirmed exploitation.
P0
Paid entitlement is bypassed
The frontend resolves every user to Elite and a sharing fallback also grants Elite behaviour.
Restore conservative tier resolution and enforce entitlement server-side.
P1
Remote image fetching accepts influenced URLs
Venue-share acceptance can fetch a client-influenced photo URL from the server.
Use trusted hosted assets or enforce host, redirect, size and content limits.
P1
Test-data restoration is callable by users
restoreTestCapture reportedly permits any authenticated caller.
Remove it from production or restrict it to controlled admin/development use.
P1
Weather and alert inputs are weakly bounded
Coordinates, timezones, arrays and numerical values need stronger schemas and limits.
Reject malformed and oversized requests before provider calls.
P2
Public and privileged boundaries need hardening
Demo auth behaviour, broad admin venue access and duplicated Mapbox configuration need review.
Isolate demo access, minimise privileges and centralise provider configuration.
Positive foundations
The supplied review reports owner-scoped rules on most business entities, Stripe signature verification and a passing frontend build.
06Payments & membership
The commercial foundations exist. They are not yet production-ready.
Nereus already contains a three-tier subscription model, Stripe checkout and webhook handling. The priority is to activate it securely, not redesign it.
One of the strongest opportunities identified during our review is that Nereus already has the foundations of a subscription-based commercial model within the existing codebase.
A
Current situation
Reported · already in code
Explorer
Free
Current implementation, not final pricing
Intelligence
£6 / month
Current implementation, not final pricing
Elite
£8 / month
Current implementation, not final pricing
The application also already includes a Stripe-based checkout flow and backend webhook handling intended to update a user's membership when a subscription is purchased or changed.
This is important because the commercial functionality does not need to be designed entirely from scratch. A significant part of the technical foundation is already present.
Billing flow
01Pricing screenReported
02Checkout sessionReported
03Stripe subscriptionReported
04WebhookReported
05Trusted membershipBypassed
Risk · not production-ready
However, the subscription system is not currently production-ready or operating as intended.
At present, the membership logic within the application effectively treats every user as an Elite member. As a result, paid features can be made available without a verified paid subscription, normal upgrade options may not appear correctly, and the application is not reliably enforcing the commercial tiers already defined in the codebase.
Still to complete and verify
Commercial decisions
- OutstandingConfirming the final subscription prices and benefits
Stripe & entitlement
- OutstandingConnecting the application to the correct production Stripe products and Price IDs
- OutstandingRestoring genuine Explorer, Intelligence and Elite entitlement checks
- OutstandingEnsuring users cannot grant themselves paid access
Lifecycle
- OutstandingConfirming upgrades and downgrades behave correctly
- OutstandingHandling cancellations, failed payments and subscription expiry
- OutstandingProviding customers with a way to manage billing and payment methods
Operations & testing
- OutstandingConnecting verified subscription information into the proposed admin portal
- OutstandingFully testing the payment journey in staging before enabling live subscriptions
B
Recommended
RecommendationWhy we recommend prioritising this
From a business perspective, we believe this should be treated as a high-priority workstream.
Nereus already contains a substantial amount of functionality, and Mark has invested considerable time and effort into developing the product. Completing the subscription system creates a route for that existing product investment to begin generating recurring revenue rather than continuing indefinitely as a development-only project.
It would also provide useful commercial validation. Rather than continuing to expand the application with a large number of additional features before launch, we recommend getting the existing core product stable, securing the platform and bringing the subscription model into production.
What Mark will learn
01
Whether anglers are willing to pay for Nereus
02
Which subscription level users prefer
03
Which features genuinely drive upgrades
04
How customers use the application after subscribing
05
What users are prepared to pay over time
06
Which areas of the product justify further investment
Reinvestment path
Early subscription revenueField reliabilityOffline functionalityUX improvementsIntelligence featuresNative mobile
Our recommendation
We recommend that Nereus does not redesign the subscription model from the ground up at this stage. Instead, the immediate priority should be to productionise and securely activate the commercial functionality that is already present in the codebase.
The current £6 and £8 pricing should be treated as existing implementation rather than automatically assumed to be the final commercial decision. Mark should confirm the final tiers, benefits, limits and pricing before launch.
Mark's options before launch
Option A
Keep current pricing
Confirm £6 Intelligence and £8 Elite as the launch prices and activate them as implemented.
Option B
Adjust prices
Change the price points before launch; Keza maps the new Stripe Price IDs.
Option C
Change benefits or limits
Redefine what each tier includes, its quotas and limits, within the existing three-tier model.
All options follow the same route: confirm first, then productionise. A full redesign of the model is not recommended at this stage.
Activation sequence
- 01MarkConfirm final tiers, benefits, limits and pricing
- 02KezaComplete the Stripe integration
- 03KezaRemove the current Elite override
- 04KezaEnforce membership securely on the backend and frontend
- 05KezaConnect subscription information into the admin portal
- 06KezaFully test the subscription lifecycle before accepting live customer payments
In our view, this is one of the most commercially important pieces of work within the Nereus roadmap because it moves the application from being primarily a product under development towards becoming a revenue-generating business.
07QA & validation
Seventy cases specified. Zero results recorded.
The workbook is a manual test specification, not executed evidence. Every case begins Not run and the release decision remains unassessed.
70
Total cases
70
Not run
0
Executed
Not assessed
Release decision
Execution sequence
- 1Demo and access
- 2Venue, swim and spot setup
- 3Session and baiting
- 4Forecast, maps and insights
- 5Sharing and privacy
- 6Themes and connectivity
- 7Billing with owner
Evidence required
Record URL or screen, date, build, account alias, device and browser, actual outcome, timing and screenshot or video. Credentials, private locations and payment data must be redacted.
Use confirmed Stripe TEST mode only. Known defects still count as Fail; unavailable prerequisites count as Blocked, never Pass.
08Recommended roadmap
Move through measurable exit gates, not feature count.
The proposed programme secures and stabilises the existing product before expanding its offline, intelligence and native capabilities.
PHASE 01
Admin & platform foundations
Secure permissions, establish staging/live controls and deliver measured business oversight.
PHASE 02
Core application stabilisation
Fix critical journeys, weather/map failures, validation, persistence and field readability blockers.
PHASE 03
Productionise payments
Complete trusted entitlement, price mapping, webhook lifecycle and customer billing management.
PHASE 04
Outdoor UX & UI
Make layouts, typography, themes and map interactions dependable on supported devices outdoors.
PHASE 05
Low connectivity & offline
Define cached access, durable local records, reconnect synchronisation and conflict handling.
PHASE 06
Intelligence & alerts
Validate historical matching, explainability, preferences and notification usefulness.
PHASE 07
Native iOS & Android
Choose a native strategy after the web product and operating foundations are stable.
Paid launch gate
Verified security, dependable critical journeys, accurate entitlement and billing, viable outdoor readability, customer support visibility, monitoring and a recovery process.
09Open decisions
Turn unknowns into owned launch inputs.
These decisions affect implementation and estimation. They do not justify delaying currently authorised documentation and foundation work.
Mark / product lead
Final tiers, benefits, quotas and commercial rules
Mark / technical lead
Deployed access, live configuration and Stripe test/live settings
Technical lead
User protections, backups, recovery, retention and media rules
Mark / QA lead
Minimum offline scope and supported devices
Mark / Keza delivery
Launch target, budget, native strategy and delivery capacity
Product / support
Admin support scope, metric definitions and privacy boundaries
Overall conclusion
Nereus has substantial product coverage and a clear proposition. Its next stage is operational and technical maturity: secure the foundation, introduce early business administration, stabilise existing journeys and complete the partially implemented subscription system.
Immediate direction
Demonstrate readiness through release gates and live verification rather than inferring it from feature count or a successful build.
10Source library
Original evidence, preserved unchanged.
Each supplied document remains individually downloadable with its original filename and format. These files are the detailed source of truth behind this presentation.
PDF
Application & Technical Review
The consolidated product, architecture, security, payments and delivery assessment.
v1.1 · 6 Oct 2026 Download
DOCX
Detailed User Journey Flow
Current journeys, known gaps, proposed refinements and acceptance criteria.
v1.1 · 6 Oct 2026 Download
PDF
Infrastructure Diagram
Whole-system, data, integration, deployment and future-boundary diagrams.
5 pages · 6 Oct 2026 Download
XLSX
Manual Test Cases
The unexecuted manual test specification, evidence template and release dashboard.
v1.0 · 70 cases Download
Prepared by
Keza Studio
This presentation summarises supplied evidence. The original files should be consulted for full qualifications, detailed acceptance criteria and source references.