jobtrackingapp/automation/prompts/Prompt 6 — PRODUCT-REVIEW-01.txt

# Jobjakt — PRODUCT-REVIEW-01
## Independent Product Audit, Feature Discovery, Ranked TODO and Development Roadmap

## Mission

Following completion of the redesigned Jobjakt application, perform a comprehensive, independent product and architecture review.

Determine which changes would provide the greatest value to real users.

Then integrate known planned initiatives, create a single ranked master TODO and split the resulting roadmap into independently deliverable workstreams.

This is research, analysis and planning only.

Do not implement features or deploy.

## 1. Product priorities

Use the following order of importance:

1. Ease of use.
2. User value and successful job-search workflows.
3. User acquisition and retention.
4. Subscription conversion and commercial sustainability.
5. Product differentiation.
6. Development efficiency and maintenance cost.

Security, privacy, data integrity and production reliability are mandatory foundations, not optional features to discard because they score poorly on commercial value.

Jobjakt should remain genuinely useful on the free tier.

## 2. Audit independently before reviewing planned features

Begin by examining the actual current application without assuming the owner's existing feature ideas are necessarily the best priorities.

Inspect:

- Onboarding.
- Authentication.
- Dashboard.
- Jobs and applications.
- Job Detail.
- Career Profile.
- CV Editor.
- CV Import.
- Cover letters.
- Documents.
- AI.
- Analytics.
- Notifications.
- Settings.
- Administration.
- Mobile usability.
- Accessibility.
- EN/Bokmål.
- Performance.
- Database architecture.
- Security and tenant isolation.
- Operations and monitoring.

Trace complete journeys from registration to job application outcomes.

Identify friction, duplicate entry, confusing interfaces, missing automation, repetitive steps and opportunities to simplify the product.

Verify implementation rather than relying only on feature descriptions.

Research credible current competing products, prioritising Norway and relevant international services.

Use dated sources and distinguish verified product features from speculation.

Complete and record this independent stage before considering the predefined roadmap.

## 3. Incorporate owner-planned initiatives

After the independent findings are documented, evaluate the following alongside newly discovered opportunities.

### LinkedIn career import

Desired experience:

Click Connect with LinkedIn → authorise access → import permitted career history → review changes → update Career Profile.

Investigate official access and developer approval.

Also assess importing previous LinkedIn job applications where officially accessible.

Provide a user-data-export fallback if direct access is not viable.

Do not propose unauthorised scraping.

### FINN and NAV job discovery

Assess:

- FINN URL import.
- Official FINN API access feasibility.
- NAV official job-advertisement feed.
- Job search.
- Filters.
- Saved searches.
- Alerts.
- Application tracker integration.

Consider regulatory, API and data-lifecycle obligations.

### AI-P5-13 completion

Review AI CV improvement, grounded rewriting, job-specific emphasis, user accept/reject controls and original semantic qualification obligations.

### Open AI model evaluation

Find the best available self-hosted model or combination of models for Jobjakt.

Do not favour a specific brand or model family.

Include credible candidates such as Qwen and Bonsai where current evidence justifies them, alongside newer suitable alternatives.

Evaluate whether specialised extraction, writing, embedding or reranking models outperform a single general-purpose model.

Consider:

- GTX 1080 Ti compatibility.
- 11 GB VRAM.
- Approximately 62 GiB system RAM.
- English and Norwegian.
- CV extraction accuracy.
- Writing quality.
- Hallucination risk.
- Inference latency.
- Concurrent SaaS usage.
- Licence.
- Operational complexity.

Assess alternative inference engines where justified.

Initial research and benchmark planning are in scope.

Large production model downloads, production cutover and complete P5-13 semantic qualification are not authorised.

### Android application

Evaluate the existing Android roadmap, including:

- Login and sessions.
- Dashboard.
- Application tracking.
- Kanban and timeline.
- Basic CV editing.
- PDF export.
- English/Norwegian.
- Themes.

Evaluate development priority and expected user benefit rather than assuming it belongs in the next release.

### Monitoring and infrastructure

Evaluate operational improvements involving:

- Grafana.
- Prometheus.
- Docker/host monitoring.
- Disk health.
- Database monitoring.
- API metrics.
- AI and GPU health.
- Backup success.
- External availability.
- Alerts.

Keep this separate from end-user application analytics.

### SaaS business improvements

Evaluate:

- Onboarding.
- Trial experience.
- Pricing presentation.
- Subscription conversion.
- Feature discoverability.
- Retention.
- Product education.
- User feedback.
- Privacy/trust.
- Account deletion and data export.

Avoid dark patterns or deliberately frustrating free-tier behaviour.

## 4. Rank every opportunity

Generate approximately 15–30 worthwhile proposals, or fewer if evidence doesn't justify that many.

For each opportunity record:

- Stable ID.
- Feature name.
- Problem.
- Proposed solution.
- User benefit.
- Acquisition/retention benefit.
- Commercial benefit.
- Technical dependencies.
- External approval dependencies.
- Security/privacy concerns.
- Current implementation status.
- Expected engineering effort.
- Ongoing maintenance cost.
- Confidence.
- Acceptance criteria.

Score 1–5 for:

- Usability improvement.
- User value.
- Expected reach.
- Acquisition/retention.
- Commercial benefit.
- Strategic differentiation.
- Engineering effort.
- Technical risk.
- Dependency complexity.
- Maintenance burden.

Publish a transparent scoring and ranking method.

Weight usability and user value most heavily, followed by user growth and subscriptions.

Do not treat speculative commercial scores as measured business data.

Separate mandatory security/reliability work from optional product rankings.

## 5. Categorise work

Use:

QUICK WIN — High value, low effort.

STRATEGIC WIN — High value, substantial effort.

LOW-EFFORT POLISH — Modest benefit, low effort.

MAJOR INVESTMENT — Large project with meaningful dependencies.

FOUNDATION / REQUIRED — Mandatory reliability/security work.

LOW PRIORITY — Limited value relative to effort.

DEFER / REJECT — Unjustified or currently infeasible.

Include a clear explanation for each classification.

## 6. Produce ranked TODO

Create:

`docs/roadmap/TODO_RANKED.md`

Include:

- Mandatory foundations.
- Ranked product improvements.
- Quick wins.
- Larger strategic initiatives.
- Blocked external integrations.
- Deferred work.

Use actionable Markdown checkboxes.

Every task must have a stable identifier, status, priority, dependencies and reference to its detailed specification.

Differentiate:

PLANNED / READY / BLOCKED / IN PROGRESS / IMPLEMENTED / ACCEPTED / DEPLOYED.

Do not confuse a committed feature with a production deployment.

## 7. Machine-readable backlog

Create:

`docs/roadmap/BACKLOG.json`

and:

`docs/roadmap/BACKLOG_SCHEMA.json`

Represent every item with consistent IDs, scores, dependencies, effort, acceptance criteria and status.

Validate the JSON schema.

Keep the machine-readable and Markdown representations consistent.

## 8. Create the delivery roadmap

Create:

`docs/roadmap/DELIVERY_PLAN.md`

Split major initiatives into independently testable, useful checkpoints.

For each development package provide:

- Branch name.
- Scope.
- Prerequisites.
- Dependencies.
- Estimated effort.
- Tests.
- Acceptance criteria.
- Required owner approval.
- Release implications.

Use separate feature branches for major workstreams.

Identify which quick wins can safely be delivered before larger integrations.

Identify workstreams that can run in parallel.

Prefer meaningful vertical slices over giant simultaneous changes.

## 9. Production readiness

Maintain a separate mandatory release gate for:

- Verified backups.
- Restore capability.
- Filesystem integrity.
- MariaDB compatibility and supported-version strategy.
- Ingress/security requirements.
- Accessibility and manual qualification.
- Deployment rollback.
- Monitoring.
- Outstanding production advisories.

Review the latest evidence rather than assuming historical blockers are still open or resolved.

Do not let feature acceptance automatically confer production approval.

## 10. Deliverables

Create:

`docs/product-review/PRODUCT_REVIEW_01.md`

`docs/roadmap/TODO_RANKED.md`

`docs/roadmap/BACKLOG.json`

`docs/roadmap/BACKLOG_SCHEMA.json`

`docs/roadmap/PRIORITY_MATRIX.md`

`docs/roadmap/DELIVERY_PLAN.md`

`docs/roadmap/DEPENDENCIES.md`

`docs/roadmap/BRANCHING_AND_RELEASES.md`

Also produce suitable specifications for high-ranked proposed workstreams.

Avoid duplicating existing authoritative documents.

## 11. Final executive recommendation

Provide:

- Overall system maturity.
- Biggest UX weaknesses.
- Top 10 product opportunities.
- Top 10 quick wins.
- Top strategic investments.
- Important features to defer.
- Estimated effort.
- External dependencies.
- LinkedIn feasibility.
- FINN/NAV feasibility.
- AI model investigation recommendations.
- Android priority.
- Operational readiness priorities.
- Suggested first development branch.

Clearly explain which recommended item should be implemented first and why.

## 12. Git and execution

Create:

`planning/product-review-01`

from the latest accepted development baseline.

Commit and push completed documentation to this planning branch.

No feature implementation.

No main merge.

No production deployment.

## Final instruction

Perform the independent audit first, then integrate planned features and produce a ranked master backlog.

The review must be willing to challenge the original feature priorities.

Finish with:

PRODUCT REVIEW: COMPLETE / INCOMPLETE.

MASTER BACKLOG: READY / NEEDS REVIEW.

DEVELOPMENT ROADMAP: READY FOR OWNER APPROVAL / BLOCKED.

Stop after delivering the research, recommendations and proposed roadmap.