jobtrackingapp/automation/prompts/Prompt 10 - homepage.txt

# Jobjakt — LAUNCH-SITE-01
# Complete Public Homepage Redesign, Multilingual Marketing Website and International Launch Experience

## ROLE

Act as a senior product designer, UX researcher, frontend architect, internationalisation specialist, accessibility engineer, SEO specialist and SaaS conversion designer.

Your task is to completely redesign and modernise the public-facing Jobjakt website to accurately showcase the finished application.

The new website must look and feel like a modern, polished, trustworthy, premium-quality SaaS product.

It must represent Jobjakt as an international career-management and job-search platform for **people in every profession**, not just software developers.

Work autonomously through research, design exploration, implementation, testing and documentation, but obtain my approval before selecting and implementing the final visual design.

---

# 1. OVERALL OBJECTIVE

Create a comprehensive, visually impressive, multilingual marketing website that:

1. Immediately explains what Jobjakt is.
2. Shows users how Jobjakt helps them throughout their job search.
3. Demonstrates the actual application's modern interface.
4. Showcases accepted functionality using genuine screenshots.
5. Uses high-quality, relevant photographs, illustrations and other visual assets.
6. Encourages visitors to create an account.
7. Works beautifully on desktop, tablet and mobile.
8. Supports English and relevant local languages.
9. Supports future country-specific marketing pages.
10. Accurately represents available features and subscriptions.
11. Performs well in search engines.
12. Is accessible, responsive and fast.
13. Is easy to maintain and update for future releases.

This is a comprehensive redesign, not a minor styling exercise.

However, do not unnecessarily rebuild shared infrastructure that already works.

Preserve Jobjakt's identity while substantially improving its public presentation.

---

# 2. IMPORTANT PROJECT CONTEXT

Jobjakt is a job-search and career-management SaaS platform.

Its target audience is **all jobseekers**.

Example audiences:

- Teachers.
- Nurses.
- Care assistants.
- Chefs and cooks.
- Hospitality workers.
- Retail employees.
- Electricians.
- Plumbers.
- Carpenters.
- Warehouse workers.
- Drivers.
- Administrative workers.
- Engineers.
- Software developers.
- Graduates.
- Students.
- Career changers.
- People returning to employment.
- International jobseekers.

Avoid creating a marketing website that appears exclusively targeted at technology professionals.

The application has undergone extensive UI redesign work, including a redesigned CV Editor and Docling-based CV Import.

Other planned or potentially implemented features include:

- Application tracking.
- Career Profiles.
- Personalised dashboards.
- CV templates.
- Cover letters.
- CV import.
- Job discovery.
- Multilingual functionality.
- Reminders and follow-ups.
- Automation.
- AI-assisted features.
- International job search.
- Country-aware location filtering.
- Saved job searches.

**Do not assume all these features are currently released.**

Inspect the repository, latest acceptance reports and deployment records.

Only advertise features as currently available when their release and availability have been verified.

Distinguish implemented, accepted, deployed, disabled and planned functionality.

The previously discussed international job-discovery features must not automatically be treated as available.

---

# 3. PROJECT BASELINE AND GIT SAFETY

First inspect:

- Current Git branch.
- Latest development baseline.
- Remote state.
- Existing homepage implementation.
- Design system.
- Application routes.
- Existing languages and translations.
- Current registration and onboarding.
- Subscription/payment configuration.
- Released feature inventory.
- Current production-release restrictions.

Use the latest accepted development integration baseline rather than assuming `main` contains the redesigned application.

Create a dedicated branch:

`feature/launch-site-redesign`

If the branch already exists, inspect its history before using it.

Commit and push validated checkpoints.

Do not force-push.

Never merge into `main` automatically.

Never deploy production.

Do not modify production databases, infrastructure, credentials or services.

Do not replace or modify the authenticated application dashboard as part of the public homepage redesign unless an approved integration specifically requires it.

---

# 4. PHASE A — RESEARCH AND EXISTING HOMEPAGE AUDIT

Before designing anything, inspect the current public website.

Review:

- Navigation.
- Hero section.
- Headlines.
- Feature descriptions.
- Screenshots.
- Photography and illustrations.
- Colour palette.
- Typography.
- Calls to action.
- Pricing.
- Registration journey.
- Responsive layout.
- Accessibility.
- SEO.
- Loading performance.
- Language handling.
- Footer.
- Privacy and legal links.

Identify:

- What works.
- What feels outdated.
- Which features are missing from the marketing presentation.
- Where messaging is confusing.
- Where visual quality can improve.
- Where visitors may abandon registration.
- Which elements should be preserved.
- Which elements need complete replacement.

Inspect credible contemporary SaaS marketing design patterns for inspiration.

Do not clone another company's proprietary layout, branding, illustrations or assets.

Document your findings and proposed improvements.

Deliver:

`docs/launch-site/HOMEPAGE_AUDIT.md`

---

# 5. PHASE B — GENERATE MULTIPLE HOMEPAGE MOCKUPS

**This phase is mandatory and must occur before final implementation.**

I want to participate in choosing the final design.

Produce at least **four visually distinct homepage concepts**.

Each must include:

- High-fidelity desktop mockup.
- Mobile mockup.
- Header/navigation.
- Hero section.
- Main call to action.
- Product screenshot placement.
- Feature presentation.
- Photography/illustration direction.
- Colour and typography choices.
- How-it-works section.
- Pricing presentation.
- Footer.

Suggested creative directions:

### Concept A — Modern Minimalist

Clean, spacious, elegant design.

Strong typography, restrained colours, excellent whitespace and sophisticated product screenshots.

### Concept B — Premium SaaS

Bold hero, confident typography, layered application previews, polished cards and subtle gradients.

### Concept C — Friendly and Human

Warm, approachable design featuring people from different professions alongside genuine application screenshots.

### Concept D — Modern Editorial

Distinctive typography, asymmetric layouts, compelling photography, strong visual storytelling and a more unique brand personality.

These are starting directions, not rigid requirements.

Use creative judgement to develop genuinely different concepts.

## Mockup requirements

Do not provide only written descriptions.

Produce actual viewable mockups using suitable local frontend prototypes, rendered screenshots or available design tooling.

Present each design with:

- Full desktop view.
- Mobile view.
- Main strengths.
- Potential weaknesses.
- Accessibility considerations.
- Differences from the other concepts.

Where feasible, provide a local comparison page showing all four designs.

Use synthetic data in previews.

Avoid inventing real user testimonials or business statistics.

## Owner feedback loop

After producing the mockups, STOP and ask me to review them.

Ask focused questions, including:

1. Which overall design do I prefer?
2. Which hero section?
3. Which navigation?
4. Which typography and colour direction?
5. How much photography versus product imagery?
6. Which feature presentation?
7. Which call-to-action design?
8. Which mobile layout?
9. Which sections should be combined from different concepts?
10. What feels missing?

Allow me to select parts from several designs.

Do not force me to choose only one complete mockup.

Iterate based on feedback.

If useful, create hybrid concepts.

Continue this collaborative process until I explicitly approve the final design.

**Do not implement the final homepage before owner design approval.**

Repository-level audit, design prototypes and mockups may be committed before approval.

---

# 6. HERO SECTION

Create a compelling hero that immediately communicates the value of Jobjakt.

The message should focus on making job searching easier, more organised and less repetitive.

Explore headline directions such as:

- Your job search, organised.
- Find opportunities. Build your future.
- Everything you need for your next career move.
- Less admin. More opportunity.
- A smarter way to manage your job search.

These are suggestions, not final copy.

Develop alternatives and present the strongest options.

The hero should include:

- Main headline.
- Supporting text.
- Clear primary CTA.
- Appropriate secondary CTA.
- Genuine application preview.
- Responsive image composition.
- Appropriate trust messaging.
- Strong contrast and visual hierarchy.

The primary CTA should generally lead to registration.

A secondary CTA could lead to a product tour or feature overview.

Do not advertise a free trial, free plan or subscription benefit unless confirmed.

Avoid fabricated claims, such as invented user counts, success rates or testimonials.

---

# 7. PROFESSIONAL PHOTOGRAPHY AND VISUAL ASSETS

The new homepage must include carefully chosen imagery where it improves communication and visual appeal.

Use a considered combination of:

1. Real application screenshots.
2. Professional photographs.
3. Original illustrations.
4. Subtle icons.
5. Product interface demonstrations.
6. Appropriately restrained decorative graphics.

## Photography

Represent a wide range of professions.

Possible subjects include:

- Teacher working in a classroom.
- Chef in a professional kitchen.
- Nurse or care worker.
- Electrician or skilled tradesperson.
- Office administrator.
- Retail worker.
- Warehouse employee.
- Engineer.
- Software developer.
- Graduate preparing for an interview.

Use natural, modern imagery.

Avoid stereotypical or excessively artificial corporate stock photography.

Avoid making the homepage visually overwhelming.

Use imagery to tell a coherent story, not simply to fill space.

## Image sourcing and rights

Use only imagery that is original, appropriately licensed or explicitly authorised for the intended commercial use.

Verify and document licences, attribution requirements and permitted modifications.

If image-generation tooling is available, original conceptual artwork or non-identifiable marketing imagery may be created where appropriate.

Generated images must not be presented as authentic photographs of actual customers or users.

Do not use copyrighted artwork or photographs without suitable permission.

Do not download or commit font files without confirming appropriate licensing.

## Image optimisation

Implement:

- Appropriate image dimensions.
- Responsive image variants.
- Modern formats such as WebP or AVIF where supported.
- Lazy loading below the fold.
- Appropriate loading priority for the hero image.
- Meaningful alt text.
- Stable layout dimensions.
- Avoidance of unnecessary cumulative layout shift.

Produce a visual-asset register documenting source, licence, purpose and usage.

---

# 8. GENUINE JOBBJAKT PRODUCT SCREENSHOTS

This is particularly important.

The homepage must showcase the **real redesigned Jobjakt application**.

Capture screenshots from an isolated development/test environment using realistic synthetic accounts.

Suggested screenshots:

- Dashboard.
- Job application tracker.
- Kanban board.
- Job details.
- CV Editor.
- CV template library.
- Career Profile.
- CV Import review.
- Job discovery, if accepted and available.
- Saved searches, if accepted and available.

Use attractive but realistic synthetic content covering different professions.

For example:

- Teacher applying to schools.
- Chef applying to restaurants.
- Nurse applying to a hospital.
- Electrician applying to a maintenance company.
- Developer applying to a software company.

Do not use actual private user records.

Do not show secret values, personal CVs, real account information or sensitive administrator data.

Do not fabricate a product interface and present it as an actual screenshot.

Clearly separate conceptual illustrations from real application screenshots.

Capture desktop and mobile variants as appropriate.

Store screenshot references in a central asset manifest.

Make it easy to replace screenshots for future releases.

---

# 9. HOMEPAGE INFORMATION ARCHITECTURE

Develop the final section order during design review.

Evaluate the following content.

## 9.1 Hero

Explain what Jobjakt does and why it matters.

## 9.2 How Jobjakt Works

Show a simple journey:

1. Create your account.
2. Set up your Career Profile.
3. Create or import your CV.
4. Discover or add jobs.
5. Track your applications.
6. Manage interviews, follow-ups and next steps.

Only include steps supported by currently released functionality.

Keep the explanation understandable for nontechnical users.

## 9.3 Job Discovery

Show the benefits of the accepted job-search functionality.

Potentially highlight:

- Country preferences.
- Multiple job sources.
- Location filters.
- Job-title suggestions.
- In-app job descriptions.
- Search by occupation and skills.
- Saved searches.
- Alerts.

Only present implemented and released capabilities as available.

## 9.4 Application Tracking

Show how users can organise opportunities, applications and follow-ups.

Demonstrate the actual accepted Kanban/table and application-detail experiences.

## 9.5 CV Builder

Showcase:

- CV creation.
- Multiple templates.
- Live preview.
- Customisation.
- Career Profile integration.
- PDF export.
- Existing CV management.

Use real visuals.

## 9.6 CV Import

Demonstrate the accepted import experience:

- Upload PDF/DOCX.
- Extract career information.
- Review extracted fields.
- Correct information.
- Approve imports.
- Continue into CV editing.

Do not advertise unqualified live AI inference.

## 9.7 Personalised Dashboard

Show application organisation and useful next steps.

Highlight supported dashboard personalisation.

Do not advertise unimplemented automation.

## 9.8 Cover Letters and Documents

Explain how Jobjakt helps users manage career documents.

Show the accepted document workflow.

## 9.9 Automation and Reminders

Describe available automation accurately.

Do not promise proactive notifications or external integrations that are not released.

## 9.10 Privacy and Trust

Explain the verified privacy and security protections in accessible language.

Do not claim unsupported certifications, compliance guarantees or security audits.

## 9.11 Pricing

Present actual subscription tiers and their real entitlements.

Make differences understandable.

Do not hardcode outdated prices.

## 9.12 FAQ

Answer realistic questions, such as:

- What is Jobjakt?
- Who is it for?
- Can I import an existing CV?
- Can I track applications?
- Is it available in my country?
- Which languages are supported?
- Can I export my CV?
- What does the free plan include?
- How is my information handled?

Only include questions with verified answers.

## 9.13 Final CTA

Finish with a strong registration invitation.

Keep it welcoming and straightforward.

---

# 10. MULTILINGUAL SUPPORT — CORE REQUIREMENT

The public website must integrate with Jobjakt's internationalisation architecture.

**English should always be available alongside the applicable local language or languages of the selected country, when those translations are actually supported.**

This must not be a hardcoded Norway-only or English-only marketing experience.

## Language selector

Display languages using:

**Native language name — English language name**

Examples:

- English
- Norsk bokmål — Norwegian Bokmål
- Norsk nynorsk — Norwegian Nynorsk
- Svenska — Swedish
- Dansk — Danish
- Deutsch — German
- Français — French
- Nederlands — Dutch
- Cymraeg — Welsh

Use accurate locale-specific naming.

Distinguish Norwegian Bokmål from Norwegian Nynorsk.

## Language prioritisation

For a visitor selecting Norway, prioritise:

- English.
- Norwegian Bokmål.
- Norwegian Nynorsk, when fully supported.

For Sweden:

- English.
- Swedish.

For the United Kingdom:

- English.
- Welsh, where fully supported and relevant.

For Germany:

- English.
- German.

For multilingual countries, support several appropriate local languages.

Allow users to choose another supported language even when it is not the primary language of their country.

Do not use country as a permanent restriction on language choice.

## Language independence

Preserve three distinct settings:

1. Jobjakt application interface language.
2. Preferred job advertisement languages.
3. CV and cover-letter language.

Do not automatically overwrite job-search or document-language preferences when a visitor changes the marketing-site language.

## Translation architecture

Inspect and reuse Jobjakt's actual translation system.

Create maintainable translation resources.

Avoid scattered hardcoded strings.

Translate:

- Navigation.
- Hero.
- Feature sections.
- CTAs.
- Pricing.
- FAQ.
- Footer.
- Errors.
- Form labels.
- Accessibility descriptions.
- SEO metadata.
- Country-specific content.

Support appropriate grammar, pluralisation and locale formatting.

Do not treat machine-generated translation as automatically production ready.

Prepare translations for human review.

## Translation completeness

Create automated tests for:

- Missing keys.
- Placeholder mismatches.
- Untranslated sections.
- Invalid locale mappings.
- Fallback handling.
- Broken navigation.
- Text overflow.
- Accessibility labels.

Do not advertise a language as supported until its necessary content is complete and accepted.

For incomplete translations, retain an accurate fallback and explicitly mark the locale as not ready for public launch.

---

# 11. INTERNATIONAL COUNTRY LANDING PAGES

Prepare Jobjakt for country-specific marketing pages.

Initial target markets:

- Norway.
- Sweden.
- United Kingdom.

Use one shared homepage architecture with market-specific content.

Do not build three entirely separate websites.

Country-specific variations may include:

- Headlines.
- Local occupations.
- Available job sources.
- Local languages.
- Relevant screenshots.
- Pricing/currency.
- FAQs.
- Country-specific calls to action.

Use actual country-specific product availability.

For example, do not claim FINN integration is available merely because Norway is selected.

## Routing

Design a clean routing structure that distinguishes:

- Country/market.
- Content language.
- Individual page.

Avoid ambiguity between country codes and language codes.

For example, `no` as a country and `nb` as a written-language code must not be conflated.

Provide appropriate canonical and alternate-language URLs.

Keep navigation and existing authentication routes working.

Do not create unnecessary duplicate pages.

---

# 12. MODULAR CONTENT ARCHITECTURE

The homepage must be maintainable for future product releases.

Do not hardcode marketing content throughout unrelated UI components.

Create reusable sections and structured content definitions.

Suggested components:

- MarketingHeader
- HeroSection
- ProductPreview
- FeatureShowcase
- FeatureGrid
- ProfessionShowcase
- HowItWorks
- CVBuilderShowcase
- JobDiscoveryShowcase
- DashboardShowcase
- TestimonialSection, only if genuine approved testimonials exist
- PricingSection
- FAQSection
- LanguageSelector
- CountrySelector
- CallToAction
- MarketingFooter

Adapt component names to existing repository conventions.

Avoid introducing unnecessary abstractions.

## Feature catalogue

Create a central feature catalogue.

Include appropriate metadata:

- Feature ID.
- Title.
- Description.
- Category.
- Screenshot references.
- CTA.
- Supported countries.
- Supported languages.
- Subscription availability.
- Implementation status.
- Acceptance status.
- Production release status.
- Marketing approval status.

Only show publicly available claims where all applicable release and marketing approvals are satisfied.

Prevent internal feature-development status from automatically publishing marketing claims.

## Content management

Prefer a repository-managed structured content system using TypeScript, JSON or established localisation resources.

Do not introduce a separate CMS unless justified.

Document how an administrator-managed marketing CMS could be added later.

Support version control and content rollback.

---

# 13. SEO AND DISCOVERABILITY

Implement a complete SEO review.

Include:

- Descriptive page titles.
- Meta descriptions.
- Semantic heading hierarchy.
- Canonical URLs.
- Accurate hreflang links.
- Country and language targeting.
- Open Graph metadata.
- Social preview images.
- XML sitemap.
- Robots directives.
- Internal linking.
- Useful structured data where valid.
- Crawlable feature descriptions.
- Accessible link text.

Research relevant search intent around:

- Job application tracker.
- CV Builder.
- Resume Builder.
- Career Profile.
- Job search organiser.
- Job application management.
- Norwegian job search.
- International job discovery.
- Profession-neutral CV tools.

Also consider relevant local-language search terminology.

Do not keyword-stuff pages.

Do not publish low-quality, near-identical country pages solely to capture search traffic.

Verify whether the existing frontend rendering architecture provides crawlable page content.

If changes to rendering or prerendering are needed, assess their feasibility and deployment compatibility before implementation.

Do not disrupt authenticated application routing.

Produce a documented SEO baseline and post-implementation comparison.

---

# 14. PERFORMANCE REQUIREMENTS

The website should load quickly and feel responsive.

Avoid a homepage dominated by heavy animation, oversized videos or unnecessary JavaScript.

Optimise:

- Largest Contentful Paint.
- Interaction to Next Paint.
- Cumulative Layout Shift.
- Image loading.
- Font loading.
- Route bundles.
- Code splitting.
- Hydration where relevant.
- Cache policy.
- Mobile performance.

Set explicit performance budgets based on the existing architecture and realistic test environments.

Measure actual results.

Do not claim a specific Lighthouse score without running the test.

Use tasteful animations only where they improve understanding.

Respect reduced-motion settings.

---

# 15. ACCESSIBILITY

Target WCAG 2.2 AA-compatible implementation and validate the applicable success criteria.

Include:

- Semantic HTML.
- Correct heading structure.
- Keyboard navigation.
- Visible focus.
- Accessible mobile navigation.
- Accessible language selector.
- Form labels.
- Meaningful alt text.
- Sufficient colour contrast.
- Reduced-motion support.
- Zoom and text resizing.
- Proper screen-reader announcements where necessary.
- No hover-only essential functionality.
- Accessible carousels if used.

Run automated accessibility checks.

Prepare a human review checklist for anything automation cannot verify.

Do not claim complete accessibility compliance solely from automated tests.

---

# 16. RESPONSIVE EXPERIENCE

Mobile is just as important as desktop.

Build intentional layouts for:

- Large desktop.
- Laptop.
- Tablet.
- Small tablet.
- Mobile portrait.
- Mobile landscape.

Do not simply shrink desktop designs.

Verify:

- Navigation.
- Hero readability.
- Screenshot presentation.
- Image cropping.
- CTA visibility.
- Feature grids.
- Pricing tables.
- Language selectors.
- Footer.
- Touch targets.
- Typography.
- Performance.

Ensure the user can understand Jobjakt's value and register comfortably from a phone.

---

# 17. REGISTRATION AND CONVERSION

The homepage should encourage registration without manipulative UX.

Inspect the actual signup flow.

Verify that registration CTAs work and lead to the correct destination.

Where supported, align messaging with the application's first-time experience:

Registration → Dashboard → Optional Guided Setup.

Do not create a second conflicting onboarding journey.

Keep registration straightforward.

Avoid:

- Fake urgency.
- Fabricated testimonials.
- Misleading pricing.
- Hidden subscription information.
- Excessive popups.
- False scarcity.
- Unsupported privacy promises.

Consider privacy-respecting measurement of marketing performance where appropriately implemented and consented to.

Do not add invasive analytics without approval.

---

# 18. PRICING AND SUBSCRIPTIONS

Read the actual subscription implementation.

Use the currently accepted plan configuration as the source of truth.

Display:

- Available plans.
- Actual prices.
- Billing periods.
- Included features.
- Meaningful limits.
- Registration/upgrading actions.

Account for locale-specific currency presentation only where actually supported.

Do not infer that payment in NOK, SEK or GBP is supported merely because a country page exists.

Do not invent discounts, free trials or feature entitlements.

Include accurate tax and billing wording where required and verified.

Test pricing consistency across homepage, checkout and account settings.

---

# 19. SECURITY AND PRIVACY

The public homepage must not compromise the application.

Review:

- Public/private route boundaries.
- XSS.
- Unsafe external content.
- Image upload and asset processing where applicable.
- Link handling.
- Content Security Policy implications.
- Third-party scripts.
- Consent requirements.
- Accidental exposure of private routes.
- Sensitive information in screenshots.
- Environment-variable leakage.
- Dependency security.
- Untrusted translated content.

Do not add unnecessary tracking scripts or remote assets.

Avoid insecure embeds.

Do not expose unpublished feature flags or administration details through public marketing content.

Use synthetic data for all screenshots and demonstrations.

---

# 20. OWNER REVIEW AND APPROVAL GATES

There must be explicit checkpoints.

## LAUNCH-00 — Existing-site audit

Inspect the actual homepage, accepted functionality and technical constraints.

## LAUNCH-01 — Visual concepts

Produce at least four desktop/mobile design concepts.

Show me the concepts and ask for preferences.

**STOP for owner selection.**

## LAUNCH-02 — Final design approval

Combine my preferred elements.

Show refined designs.

Repeat until approved.

**STOP for final visual approval.**

## LAUNCH-03 — Homepage foundation

Implement approved layout, navigation, typography, hero and responsive structure.

## LAUNCH-04 — Product screenshots and imagery

Capture genuine product images, prepare approved photography/illustrations and optimise assets.

## LAUNCH-05 — Feature content and conversion

Implement product showcases, workflows, pricing, FAQs and calls to action.

## LAUNCH-06 — Multilingual implementation

Implement translation resources, language switching and supported-language verification.

## LAUNCH-07 — International market architecture

Implement supported country variations and appropriate SEO metadata.

Do not publicly activate incomplete country or language pages.

## LAUNCH-08 — SEO, accessibility and performance

Complete technical optimisation, testing and remediation.

## LAUNCH-09 — Final integration acceptance

Run all relevant regression tests and produce a release-readiness report.

Commit and push validated development checkpoints.

Do not treat approval of a visual mockup as permission to publish the site.

---

# 21. FULL TESTING REQUIREMENTS

Run the repository's applicable test suites.

Include:

- Frontend component tests.
- Browser automation.
- Responsive layout tests.
- Navigation.
- Registration links.
- Authentication boundary checks.
- Language selection.
- Translation completeness.
- Country-specific content.
- Feature availability.
- Pricing accuracy.
- Accessibility automation.
- SEO metadata.
- Sitemap and canonical URLs.
- Screenshot asset checks.
- Image licence manifest checks.
- Performance testing.
- TypeScript.
- Lint.
- Production build.
- Security scans.
- Existing application regression coverage where affected.

Test real browser rendering, not just component snapshots.

Inspect screenshots at representative viewport sizes.

Use visual comparison against the approved mockups.

Do not change reference screenshots simply to conceal a regression.

Document test results honestly.

---

# 22. MARKETING RELEASE VALIDATION

Before declaring the redesign ready, establish a marketing feature-claim matrix.

For every marketed capability record:

- Marketing claim.
- Associated product feature.
- Actual implementation state.
- Acceptance evidence.
- Production deployment state.
- Subscription entitlement.
- Country availability.
- Language availability.
- Supporting screenshot.
- Approval status.

A feature may be shown as available only if all required checks pass.

If a capability remains disabled or not deployed, exclude it from current-availability claims.

Do not claim international integrations, AI functionality or subscription features are live without evidence.

---

# 23. REQUIRED DOCUMENTATION

Create:

`docs/launch-site/`

Required deliverables:

1. `HOMEPAGE_AUDIT.md`
2. `DESIGN_CONCEPTS.md`
3. `OWNER_DESIGN_DECISIONS.md`
4. `FINAL_DESIGN_SPEC.md`
5. `CONTENT_ARCHITECTURE.md`
6. `FEATURE_CATALOGUE.md`
7. `SCREENSHOT_AND_ASSET_MANIFEST.md`
8. `IMAGE_LICENSING.md`
9. `INTERNATIONALISATION.md`
10. `COUNTRY_LANDING_PAGES.md`
11. `SEO_STRATEGY.md`
12. `ACCESSIBILITY.md`
13. `PERFORMANCE.md`
14. `MARKETING_CLAIM_VALIDATION.md`
15. `TEST_RESULTS.md`
16. `ACCEPTANCE.md`
17. `RELEASE_HANDOFF.md`

Use existing established repository conventions if equivalent files already exist.

Avoid duplicating authoritative documents unnecessarily.

Preserve historical acceptance evidence.

---

# 24. FINAL ACCEPTANCE CRITERIA

Issue independent verdicts for:

- Homepage visual design.
- Owner design approval.
- Desktop implementation.
- Mobile implementation.
- Product screenshot accuracy.
- Image licensing.
- Feature marketing accuracy.
- English localisation.
- Existing Norwegian localisation.
- Additional supported languages.
- Country-specific landing pages.
- Pricing accuracy.
- Registration flow.
- Accessibility.
- SEO.
- Performance.
- Security.
- Regression tests.
- Production readiness.

Use:

PASS / CONDITIONAL / BLOCKED / FAIL.

For every unresolved item, record:

- Exact issue.
- User impact.
- Severity.
- Required action.
- Whether it blocks development, marketing approval or production.

Do not declare incomplete languages or countries fully launched.

---

# 25. RELEASE PROCESS

After completion, prepare a repeatable marketing-update process.

For each future Jobjakt release:

1. Identify newly released features.
2. Update the feature catalogue.
3. Capture new screenshots where necessary.
4. Update copy.
5. Update language resources.
6. Update country availability.
7. Verify pricing.
8. Validate SEO.
9. Validate accessibility.
10. Obtain marketing approval.
11. Publish as part of an authorised release.

Make this process easy for future maintainers to follow.

Do not automatically publish newly implemented functionality.

---

# 26. AUTONOMY AND HARD RESTRICTIONS

You may autonomously:

- Inspect the repository.
- Research design patterns.
- Audit the existing homepage.
- Create visual mockups.
- Build local prototypes.
- Capture synthetic screenshots.
- Prepare original or appropriately licensed imagery.
- Write architecture documentation.
- Implement approved frontend designs.
- Write tests.
- Fix bounded regressions.
- Commit changes.
- Push to authorised development branches.

You must obtain owner approval before:

- Selecting the final visual design.
- Starting final design implementation.
- Introducing paid third-party services.
- Accepting material security exceptions.
- Performing destructive changes.
- Merging into main.
- Publishing marketing content.
- Deploying production.

Do not:

- Modify production databases.
- Change production Docker infrastructure.
- Restart production services.
- Deploy unfinished features.
- Advertise blocked AI functionality as available.
- Fabricate screenshots, testimonials, statistics or pricing.
- Use unlicensed imagery.
- Replace private product data with real user information.
- Trigger production through a main-branch merge.

---

# 27. FIRST EXECUTION INSTRUCTIONS

Begin immediately with:

**LAUNCH-00 — Homepage Audit**

Then proceed to:

**LAUNCH-01 — Four High-Fidelity Design Concepts**

Research the current application, determine its accepted feature inventory, prepare the design concepts and create viewable mockups.

Each concept must include desktop and mobile designs with product screenshots and appropriate imagery.

Use realistic synthetic data.

Present the four concepts clearly.

Ask me specific design questions and allow me to select or combine individual sections.

**STOP after presenting the initial design concepts.**

Do not begin final homepage implementation until I approve the chosen design.

After approval, complete all remaining phases autonomously through validated checkpoints.

Commit and push each validated checkpoint.

Finish with full acceptance documentation and a release-ready development branch.

**Never merge into `main` or deploy production without my explicit approval.**

---

# FINAL OBJECTIVE

Create a genuinely excellent international SaaS marketing website for Jobjakt.

It should be:

- Beautiful.
- Professional.
- Modern.
- Friendly.
- Clear.
- Inclusive of all professions.
- Multilingual.
- Mobile-first.
- Accessible.
- Fast.
- SEO-friendly.
- Trustworthy.
- Easy to maintain.
- Accurate to the released product.

Use a compelling combination of genuine Jobjakt application screenshots, carefully selected professional photography, original illustrations and strong typography.

Allow me to guide the design through iterative visual mockups.

The final result should feel like a mature, polished product ready to launch internationally.

**Begin with the audit and four visual mockups. Ask for my design feedback before implementation.**