Schweltai, a Valais startup for custom software and applied AI, founded by Marcos Fernandez

From business problem to AI in production.

Custom software, integrations and automation for companies in Switzerland. AI where it adds something, rules where they are enough, a person where a decision is needed.

Tell us about your project Try the demo

Founded by a developer formerly at Capgemini, Indra Group and Ricoh Europe.

A customer request, read by the demo engine

Message received

Hello,
My name is Emma Clarke. We are moving out of our 2.5-room flat (64 m²) in Crans-Montana and need an end-of-tenancy clean including windows on 12 December.
You can reach me on 079 000 11 22 or emma.clarke@example.com.
Thanks!

Extracted data

Customer
Emma Clarke
Service
End of tenancy + windows
Size
64 m²
Place
Crans-Montana
Date
12 December
Contact
+41 79 000 11 22
Quote
CHF 595
  1. Received
  2. Read
  3. Checked
  4. Priced
  5. To approve
Quote of CHF 595 ready, waiting for a person to approve it. A real rules engine, running in your browser. Nothing is sent.

One request, four tools, three rounds of retyping.

This is often how work moves through a small company. Scroll on: the same process, first as it is, then turned into a system.

The same process, before and after Before: an email, a spreadsheet, a CRM and invoicing, linked by three manual retyping steps. After: a service reads the request with rules and a checked AI model, updates the CRM directly, and invoicing after a person approves. retypingretypingretyping EmailSpreadsheetServiceRulesChecked AICRMInvoicingApproval
  • Rule same input, same result
  • AI for what varies too much, always checked
  • Integration exchange with your systems via API
  • Person decides where a mistake is costly

  1. A request arrives by email.

    Written freely, sometimes incomplete, in the customer’s language.

  2. Someone copies it into a spreadsheet.

    To track it and price it by hand, whenever there is time.

  3. Then into the CRM, then into invoicing.

    The same data typed three times. Every copy is a chance for a mistake, and nobody knows which version is right.

  4. The spreadsheet becomes a service.

    It reads every request as it arrives. Rules extract what is predictable; an AI model reads what varies too much, and its answer is checked.

  5. Your tools update themselves.

    Through APIs: the CRM and invoicing receive the same data, once, with a record of every exchange.

  6. A person approves what matters.

    The quote, the doubtful case, the exception. Everything else moves on without waiting.

Illustrative diagram. Every project starts from your real process, your tools and your exceptions.

A free-text message, processed end to end

The example of a cleaning company that receives requests written freely, in several languages. This small system reads them, checks what is missing, calculates the price, records the request through an API and prepares the replies; a person approves before anything is sent. It runs in your browser and nothing is sent. Pick an example or write your own message, then open each step.

Made-up rates, for the demo only.

The processing, step by step

Reception

Rule

The message is received as it is. A simple rule recognises the language from its most common words, so the customer gets a reply in their own.

Language detected
—
Length
—
Received at
—
  • Rule same input, same result
  • AI for what varies too much, always checked
  • Integration exchange with your systems via API
  • Person decides where a mistake is costly

Do requests, documents or data reach you as free text, and someone retypes them?

Describe your process to us

What we build

Often combined in one project. Technology is a means: it is chosen for the problem, never the other way round.

In practice With
Applied AI Reading documents and emails, extracting information, sorting requests, assistants and search across your documents. Always with a check, and only where a rule is not enough. Language models (LLMs) via API, agents, RAG, evaluation of results
Process automation Business processes automated end to end: trigger, checks, hand-off to the right systems, human approval for the exceptions. Workflows, scheduled jobs, message queues, notifications
Integrations and APIs Connections to your ERP, CRM, payments and third-party services; data kept in sync between systems, without retyping. REST, webhooks, Kafka, custom connectors
Applications and internal tools Custom web applications, internal tools, customer portals, platforms and SaaS products. Java, Spring Boot, React, TypeScript, Node.js, PostgreSQL
Mobile apps Apps for phones and tablets: installable from the browser (PWA) or published on the App Store and Google Play, as needed. PWA, React, React Native
Websites Fast, multilingual websites that rank well, connected to your tools so that no enquiry gets lost. HTML, CSS, JavaScript, React, a CMS if needed
Booking, payments and e-commerce Online booking linked to your calendar, online payments and shops, with automatic confirmations and emails. Calendars, online payment, custom shop or CMS
Production and data Deployment, hosting and monitoring; dashboards, automatic reports and data pipelines. Docker, Kubernetes, Cloud, CI/CD, SQL, Flyway
Maintenance and hosting Monthly subscription: security updates, backups, monitoring, fixes and small improvements, by someone who knows your system. Monitoring, backups, alerts, CI/CD
Audit and takeover of applications A review of an existing application (code, architecture, infrastructure, security), then fixes, modernisation and documentation. Code review, tests, migrations, documentation

And in your company, where does it get stuck?

Six common situations. Pick the one closest to yours: the process as it is today, the system that answers it, the place of AI and the place of a person, and what needs clarifying before a single line of code is written.

AI + automation

Today

Invoices, purchase orders or forms arrive as PDFs and by email; someone opens them one by one and copies amounts, references and dates.

Where it gets stuck

The volume grows faster than the team, typing mistakes go unnoticed, and documents sit waiting in the inbox.

What we build

Documents are read automatically, the information extracted and then checked. A person only looks at the doubtful cases.

The flow

  1. PDFs and emails
  2. AI extraction
  3. Consistency check
  4. Doubtful cases to a person
  5. Your system

AI or rules?

AI reads what changes from one sender to the next: layout, wording, languages. The checks stay rules: totals recalculated, VAT numbers, plausible amounts, duplicates.

Human oversight and risks

The risk: a value read wrongly but plausible. Every extraction carries a confidence level; below a threshold agreed together, the document goes to a person, and every correction is kept to measure quality.

To clarify before starting

  • How many documents a month, and how many different layouts?
  • Which data must be extracted, and where does it go next?
  • May the documents be processed outside your servers?

Typically built with

Large language models (LLMs) via API where documents vary too much, rules where they are enough.

That’s us too

Automation

Today

Every week, someone exports data from one tool, checks it in a spreadsheet, then sends it or retypes it elsewhere, always in the same order.

Where it gets stuck

Hours of work that add nothing, a process that stops when that person is away, and no record of what was done.

What we build

The process is automated end to end: trigger, checks, hand-off to the right systems. A person only steps in for the exceptions.

The flow

  1. Trigger
  2. Checks
  3. Target systems
  4. Exceptions to a person
  5. Run log

AI or rules?

Often no AI at all: if the steps are always the same, rules are more reliable, faster and cheaper. AI only comes in if a step needs to read free text.

Human oversight and risks

The risk: an automation that fails silently. Every run is logged, an error triggers an alert, and every exception reaches a person with its full context.

To clarify before starting

  • What triggers the process, and how often?
  • Which tools are involved, and do they have an API?
  • Who needs to know when something is out of the ordinary?

Typically built with

Java and Spring Boot, Python or Node.js, with a message queue when the volume calls for it.

That’s us too

Integration

Today

A customer is created in the CRM, then again in invoicing; an accepted quote is copied into the ERP.

Where it gets stuck

Data that drifts apart from one tool to the next, invoices sent to an old address, and time lost looking for the right version.

What we build

An API connection keeps customers, quotes and invoices in sync both ways, and logs every exchange.

The flow

  1. CRM
  2. Integration service
  3. Invoicing
  4. Exchange log

AI or rules?

No AI here: a synchronisation must be exact and predictable. It is a set of mapping rules between fields, written down and tested.

Human oversight and risks

The risk: two conflicting changes at the same moment. We define which system is the reference for each piece of data; a conflict is flagged instead of overwritten.

To clarify before starting

  • Which software, and which of them offer an API?
  • For each piece of data, which system is the reference?
  • Does the existing history need to be migrated?

Typically built with

REST APIs and webhooks, with a message queue such as Kafka if the volume calls for it.

That’s us too

Internal tool

Today

A request starts in an email, continues in a shared spreadsheet, gets approved by message and ends up in a folder.

Where it gets stuck

Nobody has the full picture: where the request stands, who approved it, which version is the right one.

What we build

An internal application brings the steps into one place: entry, tracking, approval and history, with permissions per person.

The flow

  1. Entry
  2. Process steps
  3. Approval
  4. History
  5. Dashboard

AI or rules?

AI is not the heart of it. It can help at the edges, for instance to summarise a long request or suggest a category; the steps and permissions stay rules.

Human oversight and risks

The risk: a tool that imposes a way of working that doesn’t match reality. It is built step by step, with the people who will use it, and every action is recorded.

To clarify before starting

  • Who is involved, at which step, with which permissions?
  • Which information must be visible, and to whom?
  • Which current tools should it replace or connect to?

Typically built with

React for the interface, Spring Boot and PostgreSQL behind it, with user and role management.

That’s us too

Custom platform

Today

A prototype, a mock-up or a first improvised tool shows that the idea works, but it won’t cope with more users or real payments.

Where it gets stuck

Rewriting without a plan is expensive; carrying on with a fragile base is more expensive still.

What we build

A complete web application built to grow: accounts and roles, business logic, APIs, payments if needed, deployed and monitored.

The flow

  1. Your users
  2. Web application
  3. API
  4. Database
  5. Continuous deployment

AI or rules?

AI is not an end in itself: it is added where it serves the product, for instance for search or assistance, behind an API that keeps it in check.

Human oversight and risks

The risk: building too much before having users. A first, limited version goes into production, then every step builds on real use. Security, permissions and backups from day one.

To clarify before starting

  • Who are the users, and what must they be able to do in the first version?
  • Are accounts, roles or payments needed?
  • Where should the application be hosted?

Typically built with

React for the interface, Java and Spring Boot or Node.js behind it, PostgreSQL, Docker and CI/CD.

That’s us too

Website

Today

The site is several years old, slow on mobile and in one language only; the few enquiries land in an inbox that nobody watches.

Where it gets stuck

Customers who can’t find you, or who leave before they understand what you do.

What we build

A fast, multilingual, well-ranked site whose enquiries land directly in your tools instead of getting lost in an inbox.

The flow

  1. Google search
  2. Multilingual site
  3. Enquiry form
  4. CRM or calendar
  5. Enquiry follow-up

AI or rules?

AI can help sort or pre-qualify the enquiries you receive, but the site first has to be fast, clear and easy to find.

Human oversight and risks

The risk: a beautiful site nobody finds. Performance, accessibility and search visibility are measured before launch, and every enquiry reaches the right person.

To clarify before starting

  • Who are your customers, and what are they looking for when they arrive?
  • In which languages?
  • Where should the enquiries arrive?

Typically built with

HTML, CSS and JavaScript or React depending on the project, technical SEO and accessibility.

That’s us too

A real project, in production

The website and booking system of La Petite Ménagère, a cleaning company in Valais. The same approach as in the cases above: rules where they are enough, a person where the decision is made.

Home page of lapetitemenagere.ch, in French: “Choisissez l’heure. Nous nous occupons du reste.” (Choose the time. We take care of the rest.), with the company’s mascot.
Booking calendar on lapetitemenagere.ch: four slots chosen on Thursday from 10:00 to 12:00, unavailable times hatched, and the request summary.
Screenshots of the live site. The calendar availability is an example.
Visit lapetitemenagere.ch

La Petite Ménagère

Professional cleaning, ValaisIn production

The need

Let customers book online, directly in the manager’s Google Calendar, without ever being offered a time that is already taken, and leave the decision with her: she confirms every appointment.

What we built

The website in six languages, the booking calendar, the server that connects it to the calendar, the emails to the customer and the manager, and automated deployment.

The flow

  1. The customer picks time slots
  2. Check: free, 2 h minimum, travel included
  3. Appointment “to confirm” in Google Calendar
  4. The manager confirms or declines from the email
  5. Confirmation to the customer, with a calendar file

AI or rules?

Rules, no AI: nothing here requires interpreting text. 30-minute slots, visits of at least 2 hours, 30 minutes of travel between two customers. The grid on screen and the acceptance of a request apply the same rule: what looks free is what gets accepted.

Human oversight and risks

Each requested day is decided separately: confirmed for one or two people (with two, the calendar only blocks about half the time) or declined, and the time becomes free again. The customer gets the answer in their own language.

Checked automatically

  • Ten customers request the same time at the same moment: only one gets it.
  • If Google Calendar does not respond, nothing is half-saved and the manager is notified.
  • What customers type is never interpreted as code in the emails.
  • Booking flow and accessibility tested in a real browser.
  • On every deployment, if the new version does not respond, the previous one comes back on its own.
  • Tests run on the same database as production, PostgreSQL. Every change to its structure is versioned, tested, then applied automatically on deployment.

Built with

React, TypeScript, Tailwind CSS · Java 17, Spring Boot, PostgreSQL, Flyway · Testcontainers, Docker, Playwright · Google Calendar API · GitHub Actions, Caddy

This page is a demonstration too

Software is judged by how it is built. Here is what your browser measured while loading this page.

This page, live

Fully loaded
…
Data transferred
…
Files loaded
…
Languages available
6
Trackers without your consent
…
Calls to external fonts
…

Real measurements from your browser (Performance API). They vary with connection and cache.

The same standard in every project

  • Versioned code covered by automated tests
  • Automated deployment (CI/CD) and reproducible environments with Docker
  • Security by design: authentication, role-based access, logging
  • Performance and accessibility measured, not assumed
  • AI built in with checks, where it adds something
  • Documentation and handover, so the system does not depend on a single person

Lighthouse audit, 17 October 2026: 100 for accessibility, best practices and SEO.

Portrait of Marcos Fernandez, founder of Schweltai

A Valais startup, one point of contact

Schweltai designs and builds custom software for businesses: applications, integrations, automation and applied AI. It was founded in 2026 by Marcos Fernandez, a full stack developer.

Marcos has been building enterprise software since 2022, first at large consulting and technology groups (Capgemini, Indra Group, Ricoh Europe), then for his own clients. Schweltai brings the same practices to businesses in the region: versioned and tested code, automated deployments, documentation, and a system someone else can take over.

Today he designs and writes the code for every project: you talk directly to the person who builds your system, in English, French or Spanish. What we build speaks to your customers in their own language: French, German, Italian, English, Spanish or Portuguese. The team will grow with the projects.

Founded
2026
Based in
Valais, Switzerland
Founder
Marcos Fernandez, full stack developer
Founder’s background
Capgemini, Indra Group, Ricoh Europe, since 2022
Working languages
English, French, Spanish
Multilingual projects
EN, FR, DE, IT, ES, PT
Technologies
Java, Spring Boot, React, TypeScript, Node.js, Python, PostgreSQL, Flyway, Docker, Testcontainers, Kubernetes, Kafka, Cloud, LLMs
Hosting
Our servers, your host or your cloud

How we work

Six steps, each with something concrete at the end.

  1. Understand

    We look together at how the work is done today, with the real files and real cases.

    You get A written description of the process and where it gets stuck.

  2. Design

    We propose a solution, an architecture and a realistic scope for a first phase.

    You get A diagram, a quote and a schedule.

  3. Build

    Development in stages, with versions you can try out.

    You get Usable versions as the project goes on.

  4. Integrate

    Connection to your existing tools and migration of your data.

    You get Tools that exchange their data.

  5. Go live

    Deployment on a server chosen together, with backups and monitoring.

    You get A system in service.

  6. Improve

    Support, fixes and changes as the way you work evolves.

    You get A system that keeps up with your business.

Frequently asked questions

How much does a project cost?

It depends on what needs building. The first conversation is free and without commitment; after that you get a quote for a clearly scoped first phase.

Do you use AI for everything?

No. When a simple rule is enough, we use a rule: it’s cheaper, faster and verifiable. AI is for data that varies too much, such as documents written in free form.

How do you avoid AI mistakes?

By giving it only what a rule cannot do, by checking every answer (format, plausible values, consistency with your data) and by sending doubtful cases to a person. Every decision is logged, so it can be verified and improved.

Does our data go to an AI provider?

Only if you agree, and only what is necessary. Depending on how sensitive the data is, we choose together a provider with suitable contractual guarantees, a model running on your own infrastructure, or no AI at all.

Can you take over an existing application?

Yes. We start by reviewing the code, architecture and infrastructure, then we decide together what to fix, modernise, automate or keep.

Which technologies do you work with?

The ones that fit the problem and your environment. Our foundation: Java, Spring Boot, React, TypeScript and PostgreSQL, with Docker, Kubernetes, Kafka and the cloud. Tests run against a real database (Testcontainers) and its schema evolves through versioned migrations (Flyway). We also use Node.js, Python or language models when they are a better fit. Every choice is explained and documented, so your system does not depend on a single person.

Where is the data hosted?

We decide together at the start: on a server we run, with your hosting provider or in your cloud.

Who works on my project?

Marcos Fernandez, the founder of Schweltai, designs and builds your system and remains your contact from start to finish, in English, French or Spanish. The team will grow with the projects; you will always know who is working on yours.

What happens after launch?

We offer a maintenance subscription: security updates, backups, monitoring, fixes and small improvements. If you prefer, your own team or another provider can take the system over: it is documented for that.

Isn’t a startup a risk?

Your system is built not to depend on anyone: versioned, tested and documented code, running on the infrastructure of your choice. If you ever change provider, another team can take it over.

Tell us what you want to build

A few lines are enough: the problem, the tools involved, what you would like to happen.

What happens next

  1. Marcos reads your message and replies personally, with specific questions or a first approach.
  2. If the project is a fit, we set up a first conversation, free and without obligation, with your real files and real cases.
  3. You receive a proposal for a clearly defined first step: scope, price and schedule.

Or directly

What you’re looking for

Your request

Nothing is sent from this site: the button opens your email app or WhatsApp with the text ready.