NILSON
← Services

AI development · Switzerland

AI developer in Switzerland.

I integrate language models into products built for production: data extraction from documents, classification, structured generation, workflow automation, retrieval-augmented answers where they are justified — with deterministic validation of outputs, measurable evaluation, observability of every call and cost control. I do not sell “AI”; I build the product around it. To be precise: none of my products in production depends on an LLM today. What they prove is the rules engines and workflows an AI step plugs into.

Talk about an AI projectRead: when should a SaaS use AI ↓Contact form

Updated

In brief

Where
Zürich, Switzerland — remote across Switzerland and Europe
Use cases
Extraction · classification · structured generation · workflows · RAG · human-in-the-loop
Models
Anthropic, OpenAI, Google, Mistral APIs — chosen per task, swappable, with fallback
Guardrails
Typed, validated outputs · evaluation on a test set · observability · per-call budgets
Format
Fixed fee, price agreed upfront — often one feature inside a v1 or an automation system
Data
Hosting and providers chosen for Swiss FADP / GDPR; no training on your data
Proof
No product in production depends on an LLM today — the products cited show the deterministic structure

Most AI projects fail for a reason that has nothing to do with the model: nobody built the system around it. Where the documents go, who is allowed to see them, what happens when the output is wrong, what each request costs, how you know yesterday’s version was better. That system is what I build.

My starting point is that of a full-stack developer who has built deterministic decision engines — tax, air passenger law, scoring — and therefore knows where a probabilistic model adds something and where it would destroy trust. The aim is a product with AI inside it, not a chatbot demo; when the need is first a process to automate, the business process automation page is the right way in.

01 — Use cases

What AI does well inside a product

The tasks where a language model replaces weeks of hand-written rules or repetitive human work, and where an error can be caught.

Structured extraction
Turning a PDF, an email, an invoice, a statement or a form into typed fields — with an enforced output schema, a confidence per field and human review when confidence is low.
Classification and routing
Sorting requests, tickets, documents or replies into the right queue or process. The model proposes; a deterministic rule decides the sensitive cases.
Structured generation
Producing a letter, a summary, a proposal or a report from validated data — with a template, constraints and JSON output that feeds the rest of the system, not free text.
Workflow automation
Chaining extraction, decision and action (open a case, send an email, update a status) with retried steps on failure and a log of what was done.
Agentic workflows — where justified
An agent that calls tools makes sense when the task is open-ended and verifiable. Otherwise a deterministic pipeline with one LLM call per step costs less, tests better and can be explained.
Retrieval-augmented generation — where justified
Answering from your documents: chunking, embeddings in Postgres (pgvector), hybrid search, citations. Useful when the corpus changes often; pointless when a relational database and a query would do.
Human-in-the-loop
A review queue where a person approves, corrects or rejects — and where every correction becomes an evaluation example. It is what lets you ship before the model is perfect.

02 — Limits

When AI should not be used

A probabilistic model does not belong everywhere. These cases come up in almost every scope call.

Decisions that must be justifiable
Eligibility, tax computation, compensation amounts, compliance: the answer has to be reproducible and traceable. On Horvera and Atamatax, the decision is a versioned rules engine that shows its trace. AI can prepare the facts, never deliver the verdict.
What a SQL query already does
If the question is “how many customers paid this month”, the answer is a query, not a model. Adding an LLM adds cost, latency and a source of error.
When the error costs more than the gain
A wrong summary in an internal tool gets fixed; a wrong clause in a contract sent to a customer does not. Without possible human review, you do not automate.
When you cannot evaluate
Without about fifty real examples with the known correct answer, you will never know whether the system works or whether it regressed. The evaluation is built before the feature.
Data you are not allowed to send
Health, identity, trade secrets: the provider, the hosting region and the retention are decided before the first line of code — sometimes the answer is “no external LLM”.

03 — Implementation

How I implement an AI feature

Every model call is a typed function: a validated input, a prompt versioned in the code, an output schema (JSON) validated with Zod, a model chosen for the task and swappable by configuration, a fallback if the provider is down or the output is invalid. The rest of the application never deals with free text.

Evaluation ships with the feature, not after it: a set of real examples, a score, and a run on every prompt or model change. Every human correction in production joins that set. It is what lets you switch models with confidence when a better or cheaper one appears.

Observability covers every call: input, output, model, latency, tokens, cost, prompt version — in PostHog or a Postgres log depending on sensitivity. Budgets are explicit: a cap per user, per day, per feature, with graceful degradation instead of a surprise invoice.

The deterministic surrounds the probabilistic. Business rules, thresholds, permissions and calculations remain tested code; the model fills the gaps rules cannot. What holds for an eligibility engine holds for an invoice extractor: the structure is fixed, only the reading is learned.

04 — Stack

The stack for a production AI product

  • Next.js (App Router) and TypeScript — the application, server actions, webhook routes.
  • Postgres — the data, the call history, pgvector for semantic search when RAG is justified.
  • Model APIs — Anthropic, OpenAI, Google or Mistral behind an abstraction layer (Vercel AI SDK or a direct client), with structured outputs and typed tools.
  • Zod — validation of every input and every model output.
  • Queues and jobs — asynchronous processing of long documents, retries, idempotency.
  • PostHog or a Postgres log — traces, costs, evaluations, human feedback.
  • Stripe, Resend, Vercel — as for any SaaS: the AI feature lives inside a complete product.

05 — Hire?

Hire an AI engineer, or commission a feature?

Hire an AI engineer if AI is at the core of what you sell and you will ship AI features every month: evaluating, switching models and watching costs is continuous work. For a defined feature — extracting fields from one kind of document, classifying requests — a fixed-fee project delivers the feature, its evaluation set and its documentation.

An AI engineer and an automation consultant do different jobs: the consultant recommends tools, the engineer builds the system and answers for how it works. The hire-or-outsource guide helps decide.

Is this the right service?

This makes sense if

  • You have a flow of documents, requests or text that people handle by hand today, and real examples to evaluate against.
  • The AI feature belongs to a product — accounts, data, payments — that you want to build or extend properly.
  • You want to know, with numbers, whether the model works, what it costs and what happens when it is wrong.
  • You need an honest judgement on what should stay deterministic.

It is not the right service if

  • You want a generic chatbot dropped on a website — no-code tools do that for a few francs a month.
  • You want to train or fine-tune a foundation model — a different craft, and rarely necessary.
  • The final decision must be made by the model with no review and no trace.
  • You have no real examples and no way to get any.

Proof — products I built and run

My own products, with their actual state. No client project is published yet.

How it works

Four steps, fixed scope, price agreed upfront.

  1. 01

    Diagnose

    20 minutes, free. Business model, workflows, risks and product scope. If I’m the wrong person, I say so.

  2. 02

    Architect and propose

    Within 48h: data model, system boundaries, integrations, UX — and one fixed fee with dated milestones. No “starting at”.

  3. 03

    Build

    4 to 6 weeks of controlled iterations. A demo every Friday on a Vercel preview. You watch the system grow live — no black box.

  4. 04

    Launch

    Payments, analytics, deployment, operational workflows. You leave with the repo, the accounts, the pipeline — and 30 days of 24h replies.

  5. 05

    Improve

    Measured iteration on real usage: a fresh fixed-fee scope per increment, or nothing if your team takes over. No hidden dependency.

The full process, guarantees and prices →

Frequently asked questions

  • When should a SaaS use AI?

    When a task is done by hand today on text or documents, when an error can be caught or reviewed, and when real examples exist to evaluate against. Not when the answer is already a database query, and not when the decision has to be justifiable line by line.

  • When should you use RAG — and when not?

    RAG is useful when the answer depends on a changing corpus of documents and needs citations. It is pointless when the data is structured and a query would do, and dangerous when documents hold contradictory versions with no governance. Often, a good data schema makes RAG unnecessary.

  • How do you guarantee an AI output is correct?

    You do not guarantee; you measure and you fence. Structured output validated against a schema, deterministic rules for sensitive cases, an evaluation set run on every change, human review on low confidence, and a log of every call to understand errors.

  • How much does an AI feature cost?

    Two separate costs. Development: a well-fenced extraction or classification feature fits inside a v1 fixed fee or a dedicated 2-to-4-week sprint. Operation: from a few cents to a few francs per document depending on the model, capped by explicit budgets. Both are priced before work starts.

  • Is my data sent to OpenAI or Anthropic?

    Only what is necessary, to the provider chosen for the task, under terms that exclude training on your data, with the hosting region and retention documented. For sensitive data, the “no external provider” option is examined during scoping.

  • Which model do you use?

    The one that passes the evaluation at the best cost for the task — often a fast model for classification and a more capable one for complex extraction. The architecture makes the model swappable by configuration, with a fallback when the provider is unavailable.

  • What is the difference between an AI engineer and an automation consultant?

    The consultant recommends tools and processes; the engineer builds the system and answers for how it works: data, rules, integrations, evaluation of the model’s output. I do the latter, fixed fee.

  • Do you have AI features in production?

    Not in my own products today: they run on deterministic rules engines. That is said here rather than presenting a rules engine as AI. What I build around an AI step — validation, evaluation, human review, a log — is the same discipline as those engines.

Further reading

Other services

An AI feature to put in production?

Describe the task, the volume and what happens today when it is done badly. Twenty minutes is enough to say whether AI is the right answer — and if not, what to build instead.

Talk about an AI projectScope it with the calculator

danilson.daveigaramos.pro@gmail.com · Reply within 24h, Mon–Fri.