Var med och skapa en bedrägerifri värld

You'd own a large part of what customers see when they use VerifyPDF: the upload flow, document history, API key management and the screens that explain why a PDF looks risky. The dashboard is React 18, Vite, MUI, Redux Toolkit, React Router, Axios, motion and i18next. This marketing site is Astro 6 with React islands, so there is also room to improve the public product experience when it matters.

Key Responsibilities:

You'd ship product UI that people rely on while reviewing sensitive documents. That means upload states that do not lie, result pages that explain fraud signals clearly and account screens that make quotas, billing and API usage easy to understand.

You'd work close to the FastAPI backend and public REST API. The frontend has to handle async document processing, polling, errors, retries and edge cases around large files without turning the interface into a mess. Accessibility and performance matter because customers use this during live operations, not as a toy demo.

You'd also clean up older frontend areas as you touch them. Some screens need sharper state handling, better tests and less copy-paste. We support multiple languages through i18next, so text, layout and date handling need to survive outside English.

Requirements:

What We Offer:

You'd work on the backend that takes a PDF from upload to fraud verdict. The core stack is Python, FastAPI, DynamoDB, S3, SQS, Elastic Beanstalk, Firebase auth, Stripe and a handful of Python Lambdas for scheduled and event work. The product looks simple from the outside. Under the hood it has quotas, async processing, webhooks, test-mode API keys, uploads, thumbnails, emails and a fraud pipeline with more than 50 indicators.

Key Responsibilities:

Your main focus would be the public API and dashboard API. You'd improve request handling, quota enforcement, document status polling, webhook delivery and the worker path that processes documents from SQS. Small reliability fixes count here. A one-line idempotency bug can cost real money or send a customer the wrong signal.

You'd work in the fraud detection pipeline too: metadata extraction, PDF structure checks, OCR fallbacks, OpenAI classification, SageMaker inference and the scoring models that become fraud risk, trust score and risk band. You do not need to be a PDF forensics expert on day one, but you should like systems where the details matter.

You'd also own production hygiene: tests, logging, Sentry, slow paths, bad retries and the boring safeguards that stop queues, S3 writes and billing counters from drifting apart.

Requirements:

What We Offer:

This role sits close to the part of VerifyPDF that matters most: deciding whether a submitted document can be trusted. We already check metadata, PDF structure, fonts, incremental updates, suspicious producers, OCR output, visual signals and template matches. We want someone who can make those signals better, test them properly and turn messy evidence into a verdict customers can understand.

Key Responsibilities:

You'd work on document classification, signal extraction, evaluation sets, prompt and model behavior, false-positive review and the scoring path that produces trust scores and risk bands. Some weeks this is applied ML. Some weeks it is reading strange PDFs, finding why our pipeline missed something and writing the fix yourself.

You'd build tools that make fraud analysis less subjective: repeatable evals, regression tests for known fraud patterns, better evidence summaries and safer fallbacks when OCR or model output is weak. You'd work with Python, FastAPI, pdfplumber, pdfminer, PyMuPDF, OpenAI, SageMaker inference, scikit-learn and the existing PDF forensics code.

You'd also help decide when AI should not be used. If a deterministic PDF check is more reliable than a model, we should use the deterministic check. The goal is not to add AI everywhere. The goal is to catch more fraud and explain the result better.

Requirements:

What We Offer:

This is for someone who likes building the whole slice. A customer uploads a bank statement. The backend queues it, processes it, scores it and stores the result. The dashboard has to show what happened, what looks suspicious and what the customer should do next. You'd work across that path instead of being boxed into one layer.

Key Responsibilities:

You'd build features across the React dashboard and FastAPI backend: upload improvements, document detail pages, API key management, team workflows, result explanations, plan limits and customer-facing settings. You'd care about whether a compliance analyst can read the page and make a decision without asking support what the score means.

You'd also tighten the seams between systems. The dashboard uses React 18, MUI, Redux Toolkit, Axios and i18next. The backend uses Python, FastAPI, DynamoDB, S3, SQS, Firebase auth and Stripe. Some work will be greenfield. Some will be cleaning up old assumptions that no longer match the product.

The job is practical. If a workflow is confusing, you should be able to trace the API, fix the response shape, adjust the UI and write the test. You do not need permission from five teams to improve the product.

Requirements:

What We Offer:

VerifyPDF needs a stronger platform around the fraud engine. The API is live, customers submit real documents, the worker tier processes them asynchronously and the system has to explain what happened later. This role is about making that machinery more reliable, observable and easier to improve.

Key Responsibilities:

You'd work on the infrastructure around document processing: SQS workers, retry behavior, DLQs, S3 storage paths, DynamoDB access patterns, usage counters, webhook delivery, Sentry signals and operational tooling. The work is part backend engineering, part platform engineering and part "why did this customer's file behave differently from every other file today?"

You'd also build the trust infrastructure around AI: eval runs, regression checks, model output logging, safe rollouts and dashboards that make failures obvious. If a model, OCR step or PDF parser starts drifting, we should know before a customer does.

There is a lot of room to make things cleaner. Some parts are already solid. Some are held together by production scars. We want someone who can improve the system without pretending a rewrite is the only respectable answer.

Requirements:

What We Offer:

This is the EMEA field engineering role we actually need. Customers do not buy document verification in the abstract. They have an onboarding flow, a lending process, a claims queue, a tenant screen or a compliance review that already exists. Your job is to understand that workflow, build the missing pieces and bring the useful patterns back into VerifyPDF.

Key Responsibilities:

You'd lead technical discovery with customer teams, scope integrations, build prototypes and take the serious ones into production. That could mean a webhook flow for a lender, API test-mode tooling for a fintech, a dashboard workflow for a compliance team or a small internal tool that proves where fake documents are slipping through.

You'd write production code across Python and React when that is the fastest way to make progress. You'd also know when not to build. Sometimes the right answer is better documentation, a safer API response, a clearer result page or a blunt conversation about what the customer is trying to automate.

You'd feed what you learn back into product and engineering. If three customers need the same integration pattern, it should become a reusable capability. If a fraud signal makes sense to our engineers but not to a risk analyst, the product needs clearer evidence, not more jargon.

Requirements:

What We Offer:

This is the North America field engineering role we actually need. Customers do not buy document verification in the abstract. They have an onboarding flow, a lending process, a claims queue, a tenant screen or a compliance review that already exists. Your job is to understand that workflow, build the missing pieces and bring the useful patterns back into VerifyPDF.

Key Responsibilities:

You'd lead technical discovery with customer teams, scope integrations, build prototypes and take the serious ones into production. That could mean a webhook flow for a lender, API test-mode tooling for a fintech, a dashboard workflow for a compliance team or a small internal tool that proves where fake documents are slipping through.

You'd write production code across Python and React when that is the fastest way to make progress. You'd also know when not to build. Sometimes the right answer is better documentation, a safer API response, a clearer result page or a blunt conversation about what the customer is trying to automate.

You'd feed what you learn back into product and engineering. If three customers need the same integration pattern, it should become a reusable capability. If a fraud signal makes sense to our engineers but not to a risk analyst, the product needs clearer evidence, not more jargon.

Requirements:

What We Offer: