Vibecode Saply
track this build5 steps, step by step0%KINDA · weekend project
A capable coding agent can build the personal core: extract a clean, text-based CV, structure or tailor it with an LLM, and render a branded DOCX. It will work on tidy CVs and silently drop data on the rest. Saply's value is extraction accuracy across thousands of real-world CV layouts, tuned so no field goes missing on a client-facing document, plus the integrations that keep recruiters inside Word, their email, and their ATS.
the project pack4 files · fastest path to a working personal build
You are building a lean indie version of Saply. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Saply indie build ## Goal Build the smallest trustworthy replacement for the core Saply workflow for one developer or a tiny team. ## Scope Upload a text-based PDF or DOCX, extract structured candidate data, optionally tailor it to a job, and render a branded DOCX. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - extraction accuracy across thousands of real-world CV layouts, tuned on years of data so nothing is silently dropped - OCR for scanned and image-based CVs - the AI agent that edits any CV in plain language directly inside Word and Google Docs - Word, Google Docs, email, and ATS integrations (Bullhorn, Carerix, Spott, Loxo) - EU tender templates (Europass, DIGIT-TM III, ITUSS21) plus anonymisation and translation - ISO 27001 certified handling of security-sensitive candidate data - bulk processing, team workflows, SLA, and enterprise support If those capabilities are essential, use Reactive Resume instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build brief Build me a local CV formatting pipeline to replace Saply for personal use. Requirements: - A Node + Express app on localhost:4173 with one page to upload a PDF or DOCX, choose a file from templates/, add an optional job description, and run the job. - Extract DOCX text with mammoth and PDF text with pdftotext. Detect image-only files and stop with a clear message instead of producing an empty CV. - Send extracted text to an LLM API of your choice, key from .env, using a strict JSON schema for contact details, summary, skills, experience, education, and certificates. - Never invent employers, dates, qualifications, or skills. Missing values stay null, and every tailored claim must be supported by the source CV. - Render the JSON into the selected tagged Word template using docxtemplater and PizZip, preserving its fonts, colors, tables, headers, footers, and repeating experience rows. - When a job description is present, show a 0-100 match score, strengths, gaps, and questions. Rewrite the summary and bullets only when a Tailor checkbox is enabled. - Save job metadata and structured JSON in SQLite via better-sqlite3. Delete uploaded source files and generated documents after 24 hours. - Bind to localhost only, with no accounts or telemetry. Data leaves the machine only for the documented LLM call. - Out of scope: OCR for scanned CVs, Word or Google Docs add-ins, ATS/email integrations, bulk processing, collaboration, and enterprise compliance controls. - Include a sample tagged template, two fixture CVs, extraction/render smoke tests, and a README covering setup, .env, template tags, retention, and the honest limitations. - Be aware of the hard part: CVs vary wildly in structure (two-column layouts, tables, sidebars, mixed date formats), and a schema that runs fine on the fixtures will silently miss fields on real-world CVs. Test on messy inputs and document what gets dropped. ## Required capabilities - LLM API key - PDF and DOCX text extraction - tagged DOCX template - document rendering - local job storage ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a lean indie version of Saply. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Saply indie build ## Goal Build the smallest trustworthy replacement for the core Saply workflow for one developer or a tiny team. ## Scope Upload a text-based PDF or DOCX, extract structured candidate data, optionally tailor it to a job, and render a branded DOCX. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - extraction accuracy across thousands of real-world CV layouts, tuned on years of data so nothing is silently dropped - OCR for scanned and image-based CVs - the AI agent that edits any CV in plain language directly inside Word and Google Docs - Word, Google Docs, email, and ATS integrations (Bullhorn, Carerix, Spott, Loxo) - EU tender templates (Europass, DIGIT-TM III, ITUSS21) plus anonymisation and translation - ISO 27001 certified handling of security-sensitive candidate data - bulk processing, team workflows, SLA, and enterprise support If those capabilities are essential, use Reactive Resume instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build brief Build me a local CV formatting pipeline to replace Saply for personal use. Requirements: - A Node + Express app on localhost:4173 with one page to upload a PDF or DOCX, choose a file from templates/, add an optional job description, and run the job. - Extract DOCX text with mammoth and PDF text with pdftotext. Detect image-only files and stop with a clear message instead of producing an empty CV. - Send extracted text to an LLM API of your choice, key from .env, using a strict JSON schema for contact details, summary, skills, experience, education, and certificates. - Never invent employers, dates, qualifications, or skills. Missing values stay null, and every tailored claim must be supported by the source CV. - Render the JSON into the selected tagged Word template using docxtemplater and PizZip, preserving its fonts, colors, tables, headers, footers, and repeating experience rows. - When a job description is present, show a 0-100 match score, strengths, gaps, and questions. Rewrite the summary and bullets only when a Tailor checkbox is enabled. - Save job metadata and structured JSON in SQLite via better-sqlite3. Delete uploaded source files and generated documents after 24 hours. - Bind to localhost only, with no accounts or telemetry. Data leaves the machine only for the documented LLM call. - Out of scope: OCR for scanned CVs, Word or Google Docs add-ins, ATS/email integrations, bulk processing, collaboration, and enterprise compliance controls. - Include a sample tagged template, two fixture CVs, extraction/render smoke tests, and a README covering setup, .env, template tags, retention, and the honest limitations. - Be aware of the hard part: CVs vary wildly in structure (two-column layouts, tables, sidebars, mixed date formats), and a schema that runs fine on the fixtures will silently miss fields on real-world CVs. Test on messy inputs and document what gets dropped. ## Required capabilities - LLM API key - PDF and DOCX text extraction - tagged DOCX template - document rendering - local job storage ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a production product version of Saply. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== PRODUCT.md ===== # Saply product brief ## Problem A capable coding agent can build the personal core: extract a clean, text-based CV, structure or tailor it with an LLM, and render a branded DOCX. It will work on tidy CVs and silently drop data on the rest. Saply's value is extraction accuracy across thousands of real-world CV layouts, tuned so no field goes missing on a client-facing document, plus the integrations that keep recruiters inside Word, their email, and their ATS. ## Product outcome Upload a text-based PDF or DOCX, extract structured candidate data, optionally tailor it to a job, and render a branded DOCX. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - LLM API key - PDF and DOCX text extraction - tagged DOCX template - document rendering - local job storage ## Explicit non-goals for v1 - extraction accuracy across thousands of real-world CV layouts, tuned on years of data so nothing is silently dropped - OCR for scanned and image-based CVs - the AI agent that edits any CV in plain language directly inside Word and Google Docs - Word, Google Docs, email, and ATS integrations (Bullhorn, Carerix, Spott, Loxo) - EU tender templates (Europass, DIGIT-TM III, ITUSS21) plus anonymisation and translation - ISO 27001 certified handling of security-sensitive candidate data - bulk processing, team workflows, SLA, and enterprise support ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees. ===== ARCHITECTURE.md ===== # Architecture ## Starting brief Build me a local CV formatting pipeline to replace Saply for personal use. Requirements: - A Node + Express app on localhost:4173 with one page to upload a PDF or DOCX, choose a file from templates/, add an optional job description, and run the job. - Extract DOCX text with mammoth and PDF text with pdftotext. Detect image-only files and stop with a clear message instead of producing an empty CV. - Send extracted text to an LLM API of your choice, key from .env, using a strict JSON schema for contact details, summary, skills, experience, education, and certificates. - Never invent employers, dates, qualifications, or skills. Missing values stay null, and every tailored claim must be supported by the source CV. - Render the JSON into the selected tagged Word template using docxtemplater and PizZip, preserving its fonts, colors, tables, headers, footers, and repeating experience rows. - When a job description is present, show a 0-100 match score, strengths, gaps, and questions. Rewrite the summary and bullets only when a Tailor checkbox is enabled. - Save job metadata and structured JSON in SQLite via better-sqlite3. Delete uploaded source files and generated documents after 24 hours. - Bind to localhost only, with no accounts or telemetry. Data leaves the machine only for the documented LLM call. - Out of scope: OCR for scanned CVs, Word or Google Docs add-ins, ATS/email integrations, bulk processing, collaboration, and enterprise compliance controls. - Include a sample tagged template, two fixture CVs, extraction/render smoke tests, and a README covering setup, .env, template tags, retention, and the honest limitations. - Be aware of the hard part: CVs vary wildly in structure (two-column layouts, tables, sidebars, mixed date formats), and a schema that runs fine on the fixtures will silently miss fields on real-world CVs. Test on messy inputs and document what gets dropped. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it. ===== AGENTS.md ===== # Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone. ===== MILESTONES.md ===== # Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations. ===== OPERATIONS.md ===== # Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted Saply capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
README.md
# Saply indie build ## Goal Build the smallest trustworthy replacement for the core Saply workflow for one developer or a tiny team. ## Scope Upload a text-based PDF or DOCX, extract structured candidate data, optionally tailor it to a job, and render a branded DOCX. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - extraction accuracy across thousands of real-world CV layouts, tuned on years of data so nothing is silently dropped - OCR for scanned and image-based CVs - the AI agent that edits any CV in plain language directly inside Word and Google Docs - Word, Google Docs, email, and ATS integrations (Bullhorn, Carerix, Spott, Loxo) - EU tender templates (Europass, DIGIT-TM III, ITUSS21) plus anonymisation and translation - ISO 27001 certified handling of security-sensitive candidate data - bulk processing, team workflows, SLA, and enterprise support If those capabilities are essential, use Reactive Resume instead of pretending the gap is solved.
AGENTS.md
# Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs".
BUILD_PLAN.md
# Build plan ## Original build brief Build me a local CV formatting pipeline to replace Saply for personal use. Requirements: - A Node + Express app on localhost:4173 with one page to upload a PDF or DOCX, choose a file from templates/, add an optional job description, and run the job. - Extract DOCX text with mammoth and PDF text with pdftotext. Detect image-only files and stop with a clear message instead of producing an empty CV. - Send extracted text to an LLM API of your choice, key from .env, using a strict JSON schema for contact details, summary, skills, experience, education, and certificates. - Never invent employers, dates, qualifications, or skills. Missing values stay null, and every tailored claim must be supported by the source CV. - Render the JSON into the selected tagged Word template using docxtemplater and PizZip, preserving its fonts, colors, tables, headers, footers, and repeating experience rows. - When a job description is present, show a 0-100 match score, strengths, gaps, and questions. Rewrite the summary and bullets only when a Tailor checkbox is enabled. - Save job metadata and structured JSON in SQLite via better-sqlite3. Delete uploaded source files and generated documents after 24 hours. - Bind to localhost only, with no accounts or telemetry. Data leaves the machine only for the documented LLM call. - Out of scope: OCR for scanned CVs, Word or Google Docs add-ins, ATS/email integrations, bulk processing, collaboration, and enterprise compliance controls. - Include a sample tagged template, two fixture CVs, extraction/render smoke tests, and a README covering setup, .env, template tags, retention, and the honest limitations. - Be aware of the hard part: CVs vary wildly in structure (two-column layouts, tables, sidebars, mixed date formats), and a schema that runs fine on the fixtures will silently miss fields on real-world CVs. Test on messy inputs and document what gets dropped. ## Required capabilities - LLM API key - PDF and DOCX text extraction - tagged DOCX template - document rendering - local job storage ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden.
.env.example
# Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
PRODUCT.md
# Saply product brief ## Problem A capable coding agent can build the personal core: extract a clean, text-based CV, structure or tailor it with an LLM, and render a branded DOCX. It will work on tidy CVs and silently drop data on the rest. Saply's value is extraction accuracy across thousands of real-world CV layouts, tuned so no field goes missing on a client-facing document, plus the integrations that keep recruiters inside Word, their email, and their ATS. ## Product outcome Upload a text-based PDF or DOCX, extract structured candidate data, optionally tailor it to a job, and render a branded DOCX. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - LLM API key - PDF and DOCX text extraction - tagged DOCX template - document rendering - local job storage ## Explicit non-goals for v1 - extraction accuracy across thousands of real-world CV layouts, tuned on years of data so nothing is silently dropped - OCR for scanned and image-based CVs - the AI agent that edits any CV in plain language directly inside Word and Google Docs - Word, Google Docs, email, and ATS integrations (Bullhorn, Carerix, Spott, Loxo) - EU tender templates (Europass, DIGIT-TM III, ITUSS21) plus anonymisation and translation - ISO 27001 certified handling of security-sensitive candidate data - bulk processing, team workflows, SLA, and enterprise support ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees.
ARCHITECTURE.md
# Architecture ## Starting brief Build me a local CV formatting pipeline to replace Saply for personal use. Requirements: - A Node + Express app on localhost:4173 with one page to upload a PDF or DOCX, choose a file from templates/, add an optional job description, and run the job. - Extract DOCX text with mammoth and PDF text with pdftotext. Detect image-only files and stop with a clear message instead of producing an empty CV. - Send extracted text to an LLM API of your choice, key from .env, using a strict JSON schema for contact details, summary, skills, experience, education, and certificates. - Never invent employers, dates, qualifications, or skills. Missing values stay null, and every tailored claim must be supported by the source CV. - Render the JSON into the selected tagged Word template using docxtemplater and PizZip, preserving its fonts, colors, tables, headers, footers, and repeating experience rows. - When a job description is present, show a 0-100 match score, strengths, gaps, and questions. Rewrite the summary and bullets only when a Tailor checkbox is enabled. - Save job metadata and structured JSON in SQLite via better-sqlite3. Delete uploaded source files and generated documents after 24 hours. - Bind to localhost only, with no accounts or telemetry. Data leaves the machine only for the documented LLM call. - Out of scope: OCR for scanned CVs, Word or Google Docs add-ins, ATS/email integrations, bulk processing, collaboration, and enterprise compliance controls. - Include a sample tagged template, two fixture CVs, extraction/render smoke tests, and a README covering setup, .env, template tags, retention, and the honest limitations. - Be aware of the hard part: CVs vary wildly in structure (two-column layouts, tables, sidebars, mixed date formats), and a schema that runs fine on the fixtures will silently miss fields on real-world CVs. Test on messy inputs and document what gets dropped. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it.
AGENTS.md
# Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone.
MILESTONES.md
# Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations.
OPERATIONS.md
# Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted Saply capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
$ choose a build depth, inspect the files, then open the complete pack in your agent
A recruiter cannot ship a client CV with a missing employer or certification, and cannot lose a minute fine-tuning output: in staffing, quality and speed win the placement. Teams pay for extraction that does not miss data across wildly varied CVs, output that is right the first time in their own and EU tender templates, and the ease of working directly inside Word, Google Docs, email, and their ATS. CVs are also security-sensitive documents, and certified handling is part of what agencies are buying.
xextraction accuracy across thousands of real-world CV layouts, tuned on years of data so nothing is silently dropped
xOCR for scanned and image-based CVs
xthe AI agent that edits any CV in plain language directly inside Word and Google Docs
xWord, Google Docs, email, and ATS integrations (Bullhorn, Carerix, Spott, Loxo)
xEU tender templates (Europass, DIGIT-TM III, ITUSS21) plus anonymisation and translation
xISO 27001 certified handling of security-sensitive candidate data
xbulk processing, team workflows, SLA, and enterprise support
share on X ↗"I just replaced Saply ($230/mo) with one prompt"
Don't feel like building it? These folks already made it free.
Resume MatcherUpload a master CV, paste a job ad, get a tailored PDF; the staffing dashboard is what you do not get.open source↗no votes, no pay-to-list · just what's real
Vibecode Saply
Kinda. The core of Saply is buildable in a weekend with the prompt on this page, but there are real gaps: extraction accuracy across thousands of real-world CV layouts, tuned on years of data so nothing is silently dropped, OCR for scanned and image-based CVs. Read the honest list above before committing.
How much does Saply cost?
Saply costs about $230/month (Pro, checked 2026-07-31), which is $2760 per year.
What do I lose by replacing Saply?
Honestly: extraction accuracy across thousands of real-world CV layouts, tuned on years of data so nothing is silently dropped; OCR for scanned and image-based CVs; the AI agent that edits any CV in plain language directly inside Word and Google Docs; Word, Google Docs, email, and ATS integrations (Bullhorn, Carerix, Spott, Loxo); EU tender templates (Europass, DIGIT-TM III, ITUSS21) plus anonymisation and translation; ISO 27001 certified handling of security-sensitive candidate data; bulk processing, team workflows, SLA, and enterprise support. If any of those are load-bearing for you, keep paying.
Is there an open-source alternative to Saply?
Yes: Resume Matcher (Upload a master CV, paste a job ad, get a tailored PDF; the staffing dashboard is what you do not get.) The prompt is for when you want it exactly your way.