DEV Community: Matthias | StudioMeyer

What Is Actually Inside Our Client Projects

Matthias | StudioMeyer — Mon, 09 Nov 2026 16:10:18 +0000

When someone asks what we do, the short answer is "websites and AI systems". It is true and it says nothing. It sounds like everybody else.

The long answer is more interesting, and it consists of the projects themselves. A booking form that walks people through a sign-up in three steps, because a single-page sign-up loses too many of them. A site in five languages where the fifth language was not glued on at the end. A tool a real estate office uses to record its properties out at the plot rather than at a desk. Those are decisions, not features.

This series goes through the projects one at a time. Each gets its own piece covering what is inside it and why it was built that way. Here is the overview.

It Is Not Only About Humans Anymore

The biggest difference to websites from two years ago is invisible. A page today is read not only by visitors but by machines. Someone asks ChatGPT about a boating school on Mallorca, a breakfast cafe in Sa Coma, a wedding planner on Maui. The model answers from whatever it was able to read.

So every site we build gets a machine layer. Structured data, so it is clear what an opening-hours block is and what a price is. A file that explains in plain text to a language model what the site is about. Clean language markup, so the Spanish version is not treated as a duplicate of the German one. This costs almost nothing while building and is nearly impossible to retrofit, because it sits in the structure rather than in the design.

For some clients it goes further. Behind the site sits a connector through which an assistant in ChatGPT or Claude can query real data instead of guessing. Courses and dates. Properties and search profiles. That is the point where a website stops being a brochure.

The Websites

Bootsfahrschule Palma Mallorca. Three languages, with a sign-up form in three steps, an automatic confirmation email and a separate form for exam data. Photo gallery in a masonry layout, map, chatbot. Every booking triggers a notification, so nobody waits two days for a reply.

MVC Properties. Premium real estate in Palma. Parallax hero, a pin timeline for the featured properties, tilt cards, filters. Plus an AI chat for direct enquiries, a WhatsApp route and a password-protected internal area. The contact form sits as a glass surface over an image of the cathedral.

Veridaro. Not a website project but a complete product: landing page, Stripe checkout with automatic onboarding, protected self-service dashboard with analytics, QR generator, PDF export, digital menu editor, magic-link login, mailing with tracking and a partner programme. All from one hand, because a product only works when it runs without its operator.

Dito Cafe. A small site for a cafeteria in Sa Coma, and small sites are the hardest. Three languages, photo gallery, daily menu, a section with directions and opening hours, the Spanish legal texts. Built so a second location can be added cleanly later instead of bolted on beside it.

Alma Balear. Five languages, and properly so: German, English, Spanish, French, Catalan. Editorial gallery, team area with QR codes that save as a contact on your phone, a magazine layer with its own article pages, two office locations. Images run through a dedicated cache at the edge of the network, so the site stays fast even with a lot of photos.

Impresol Media Solutions. A publisher and an advertising agency in one, with content to match. Travel magazines you leaf through directly in the browser. A catalog of publications and maps with its own detail pages. Apps showcase, blog, partner and client walls, AI chat. The hardest part was the move from the old site, more on that below.

Ancient Hawaiian Weddings. Our first client in the United States, a wedding planner on Maui. Bilingual English and German, ceremony packages with an à-la-carte catalog, gallery, a page-turning lookbook, reviews, blog, FAQ, inquiry form, AI chat.

The Part You Can Get Wrong In A Relaunch

Two of these projects were moves from an existing site. That is where most relaunches burn money, and you only notice weeks later.

A site that has been running for years has built up addresses that other people link to and that Google knows. If the new site uses different addresses, the old ones run into nothing. Years of accumulation are gone, and quietly so. Nobody gets an error message, the traffic simply sags.

The remedy is unspectacular: a list mapping every old address to its new equivalent, built before the switch. At Impresol that list ran long, because every inside page of every magazine has an address of its own. Building that list is dull work and the most valuable part of the whole project.

The Tools Behind The Sites

For several clients the work does not stop at the website.

A real estate office records its properties in a dedicated tool we built for it, operated at the plot rather than at a desk. A copywriting studio in Germany works inside an AI workplace in the browser, with an assistant next to it that keeps its clients and their style rules in mind across months. A consulting business runs a complete AI system on a server of its own. A rental office had its familiar assistant application wired up so that memory, contact management and inbox all meet inside it, without changing how the work is done.

What connects those four is one decision: the assistant prepares, the human decides. None of these setups sends an email on its own. It puts the draft on the table, and the draft was the part that was work.

Why We Treat Ourselves As A Client

Everything we run for clients runs at our place first. Our own agent fleet checks our sites at night, our visibility inside the models and our servers, and writes a report in the morning. That is not a marketing sentence, it is the condition for knowing where things break.

A system you only operate at other people's places, you know from the manual. A system that wakes you at six in the morning with a problem, you actually know.

Where This Goes

Every project on this list gets its own piece. Not as a glossy reference but as a description of what was built and why. Anyone wondering what this would look like for them will find more substance in the individual pieces than on any services page.

And whenever a decision comes up that could have gone the other way, it is written down. Those are the interesting part.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

The Best Workplace Is The One Somebody Already Uses

Matthias | StudioMeyer — Mon, 26 Oct 2026 19:54:42 +0000

Most digitisation projects do not fail on the technology. They fail because somebody is supposed to open a new application and stops doing it after three weeks.

That is not laziness. A new interface costs attention, and attention is the scarcest resource in daily business. If the new tool does not give back more than it costs immediately, habit wins. Every time.

So for a rental office we deliberately built nothing new.

The Constraint Was The Most Interesting Part

The brief was: no second program, no new vendor, no training. The assistant application that is open all day anyway stays the interface.

That sounds like a restriction and is in truth a good requirement. It forces the question to be asked differently. Not: which interface do we build. But: what is the existing one missing so it can carry the working day.

The answer was access. The application could talk, but it knew nothing. No memory, no client data, no inbox.

Connected Rather Than Rebuilt

So we connected the existing assistant application to what was missing. For a while now that runs over an open standard for attaching such applications to external tools. The user notices none of it. To them it is the same application as before, it can just suddenly do more.

Four things were attached.

A memory that keeps tenants, property histories, ongoing cases and agreements over the long term. In rentals that is the actual lever, because almost every case here has a backstory. Who has moved out before, which property had trouble with the heating, what was agreed last time.

A contact system where contacts, enquiries and statuses are maintained straight out of the conversation. Not in a second window, but in the one you are already typing in.

The existing inbox, from which incoming messages are read and draft replies prepared. Approval and sending remain exclusively with the office.

And an image generator for property visualisations and listing graphics, in the same session where the matching copy is written. That is one of the few places where text and image genuinely belong together: whoever is phrasing the listing knows which picture fits it.

The Configuration Is The Difference

On top comes something that sounds like a detail and tips the balance: a base instruction tailored to the business.

An assistant without a role answers generically. It does not know this is about rentals rather than sales, that certain phrasings are house standard and others are not, that an enquiry follows a fixed process. It cannot know, it is written nowhere.

Written down, the quality of answers changes noticeably without anything about the technology being different. In setups like this that is regularly the most effective hour of work in the entire project.

Where Things Sit

Memory and contacts run on our servers in Europe, with a separate data space per client. The credentials for the inbox live exclusively in the local configuration on the work machine, not centrally with us.

Each of the four connections can be switched off individually without the application itself noticing. That is a side effect of the open standard and practically more important than it sounds: whoever no longer wants something takes it out, and the rest keeps running.

Why This Route Is More Often The Right One

There are cases where a dedicated build makes sense. When many people work in it, when specific processes have to be mapped, when the data may not leave the house.

In all other cases the existing application plus a few connections is the faster and more durable route. No training effort, no second interface, no migration. And the business is productive the next day rather than in six weeks.

The best workplace is rarely the one you build. Usually it is the one somebody already opens every day.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

A Platform Where Every Profile Introduces Its Agent

Matthias | StudioMeyer — Sat, 24 Oct 2026 18:03:22 +0000

Universal marketplaces almost always die at the same spot. Not at supply and not at money, but at finding.

As soon as a marketplace offers more than one kind of thing, the filter bar becomes unusable. A property needs different fields than a service, a book different ones than a tradesperson. You can either build a form that does everything and suits nobody, or split into categories until it turns back into a set of small marketplaces.

That is why there are portals for property, portals for services and portals for classifieds, but hardly one for all of it together.

MeetMyAgent is our attempt at solving that differently.

The Machine Operates The Filters

The idea behind it is simple. The problem was never that there are too many filters. The problem was that a human had to operate them.

An AI can read a filter structure that describes itself and build a precise query from it. It invents no fields, because it read beforehand which ones exist. That makes something scale that does not scale for humans: the more content arrives, the more precise the filters get instead of the more cluttered.

That is the actual reason the platform can be universal rather than confined to one industry.

Listing Is Free, Money Only At The Deal

The second decision concerns money, and it is the one people argue about longest.

Charge providers before they have earned anything and you get few providers. An empty marketplace attracts no demand, and without demand no providers come. That is the cold-start problem, and it has finished off far better funded platforms.

So: listing costs nothing. For anyone, permanently. Money moves only at the point where value has actually been created, or for extra visibility somebody books voluntarily.

The Name Is The Programme

"Meet my agent" means literally: every profile introduces its agent to the world.

Behind that sits an assumption about the next few years. If people increasingly search, buy and enquire through an assistant, then marketplaces will soon not only put humans in front of each other but their agents. One searches, the other answers.

So the whole platform is built from the start to be fully operable both through the interface and through an interface for machines. Whatever a human can do in the browser, an agent can do too, and the other way round. That is a hard rule, not a roadmap item for later.

Two things stay hard-wired in that. First, it is always visible whether a human or an agent acted. Second, wherever money is involved, a human decides. An agent closing contracts on its own is not a vision of the future, it is a liability problem.

The Side Effect We Wanted On Purpose

Every listing and every article on the platform is prepared for machines at the same level as our own website: cleanly structured, server-rendered, with a plain-text version for language models.

Which means the marketplace is itself good food for AI crawlers. Whoever lists there is not only found on the platform but has an additional, well-readable address on the web.

For us that is the most honest part of the offer. We promise nobody that a language model will cite them, because nobody can promise that. We make sure the technical preconditions are right, and we measure what happens.

What We Deliberately Do Not Do

We are not an agent zoo. There are directories where you can browse AI agents like a catalogue. That is entertaining and has no stake in anything.

The difference is backing: with us there is a person or a company with a real offer behind every agent. The agent is not the attraction, it is the interface.

Whether that works out is open. It is the bet this platform rests on, and we would rather write it down here than pretend it has already been won.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

Not A Chatbot, But A System That Keeps Running

Matthias | StudioMeyer — Fri, 23 Oct 2026 03:06:12 +0000

There is a difference between an assistant you call up and a system that runs.

The assistant has to be fetched. You remember it exists, open it, explain the situation, get an answer, close it. Next time you start over. After a few weeks you use it for phrasings and nothing else.

A system that runs does not have to be fetched. It is already there when you open your machine in the morning, and it has been working in the meantime.

For a consulting business on Mallorca we set up such a system.

The Server Belongs To The Client

The unspectacular part first: all of it runs on a dedicated server in a German data centre. Not at our place, not in a shared account, but on a machine that belongs to the client, with their own credentials.

Application, database and backups sit there. What goes to the language model leaves the EU, because that is where the model runs, and we write that distinction down on every project before it starts. There is no reason to obscure it and many reasons to say it plainly.

In practice a dedicated server means we can keep developing without anybody having to upload their data somewhere new. And when the collaboration ends, the server and its contents stay with the client.

Memory Is The Foundation, Not A Feature

The core of this system is a memory that carries across weeks and months. Conversations, clients, projects, decisions taken and the small agreements you otherwise go hunting for in old mail.

The effect is hard to overstate. Without memory you explain the backstory to the assistant on every task. That costs more time than the task itself, which is why people stop. With memory you explain once, and two months later the assistant brings the connection back on its own.

That makes memory not an add-on but the reason the system gets used at all. Everything else hangs off it.

The Mail Gets Read Before Anybody Looks At It

The most visible part in daily use is how the mail is handled.

The system fetches the inbox itself, reads every new message, sorts it and puts a draft reply next to the relevant ones. Not a suggestion out of thin air, but one built on what memory holds about the sender and the matter.

And then it stops. It sends nothing. The draft sits there, the human reads, edits, sends or discards.

We draw that line in every system we build, and it is not caution on principle. The draft is the work, sending is a button. Give away the work and keep the button and you gain nearly everything while risking nothing. Give away both and you risk the relationship with the recipient to save one click.

The system takes the preparatory part off the table. The rest, the place where experience and judgement are needed, stays with the owner. That is also the part they get paid for.

One System, Not Three Islands

The most common mistake in setups like this is that three things end up running side by side: a chatbot, a mail tool and a pile of notes somewhere. Each works on its own, none knows about the others.

Here memory, mail and assistant share the same context. When a client's mail arrives in the morning, the draft already carries what was discussed in the last conversation, without anybody looking it up. That is the actual gain, and it does not come from a special feature but from the parts being connected.

Nothing Experimental

The substructure is deliberately boring. Ubuntu, Docker, PostgreSQL, Claude as the model, our own memory server, a connection to the existing mailbox.

That is the same setup we run for ourselves and for other clients. We do not build anybody a special construction only they have and only we understand. The reason is self-interested: a system we run many times over, we know by its failure modes. A one-off you get to know at the client's place, and that is the most expensive way to learn.

What Such A System Is Not

It is not a replacement for an employee. It has no judgement, no responsibility and no idea what is really going on between two people.

What it can do is the part of the work that consists of remembering, preparing and gathering. In a consulting business that part is larger than you think, and it is also the one left lying around in the evening.

That is exactly where such a system belongs. Not where decisions get made.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

How Do You Measure Whether An AI Knows Your Site?

Matthias | StudioMeyer — Sun, 18 Oct 2026 15:48:39 +0000

With search engines the situation is comfortable. There are tools showing which terms a site appears for, at which position, how often it gets clicked. You can argue about accuracy, but there are numbers.

With language models there is almost none of that. When somebody asks ChatGPT about a boating school on Mallorca, the site owner sees nothing of it. No hit in the log, no notification, nothing. The answer forms, the user reads it, and whether a particular site appeared in it is known to nobody but the user.

That is a real problem, because part of search is shifting exactly there right now.

The Only Honest Method Is To Ask

You cannot measure what you cannot see. So you ask yourself.

The tool puts to the models exactly the questions a customer would ask. Not "do you know this company", because a model will almost always answer that pleasantly. But the open question somebody would actually type: which provider for this thing in this area.

Then the answer gets evaluated. Does the site appear. In which position. Who stands next to it. And with which description, because being named with a wrong description is worse than not being named.

That is a sample, not a census, and it is reported as exactly that. Anyone claiming otherwise is selling a precision that does not exist.

The Second Half: Is The Site Readable At All

The second part of the tool does not look outward but at the site itself.

Can a machine take in the content at all. Are opening hours, prices and offers marked up as structured data or do they sit there as running text. Is there a plain-text version for language models. Are the language versions cleanly separated. Does the site accidentally block the crawlers of the AI providers.

This part is the more thankless and the more important one. A site can have excellent content: if a model cannot read it cleanly, it does not exist in that world.

And it is the part you can actually influence. Whether a model names somebody is the model's decision. Whether the preconditions are right is yours.

What We Explicitly Do Not Promise

There is a market by now for promises in this direction. Guaranteed mention in AI answers, position one at ChatGPT, optimisation for a specific model.

That is unserious, for one simple reason: nobody outside those companies knows how the selection comes about, and it changes with every model version. Guaranteeing a mention means guaranteeing something you do not control.

What can honestly be said is: we make sure everything readable is easy to read, we measure regularly, and we show the curve. That is less than a promise and more than most deliver.

Why This Has To Be A Tool

Done by hand, a measurement like this has two drawbacks, both expensive. It costs time every time, so you do it too rarely. And it is not comparable, because the questions are phrased slightly differently each round. A comparison over time needs identical questions, otherwise you are measuring your own phrasing.

So, a tool: same questions, fixed grid, history. It runs for our own site, for client sites, and can be subscribed to.

The Case Nobody Expects

The more awkward possibility is not "does not appear" but "appears, but wrong": the model names a business but files it under the wrong industry, quotes a service that no longer exists, or confuses it with a similarly named one.

That is the good news in bad packaging. Being named wrongly is easier to repair than not appearing at all. In both cases the route is the same: make sure the unambiguous, structured answer is easier to find than the poor guess.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

What The Monday Report Says, And Who Wrote It

Matthias | StudioMeyer — Tue, 13 Oct 2026 21:06:19 +0000

Most websites never see anyone check them again after launch. Not out of negligence. It simply does not pay to have somebody look once a week at a site that is probably fine.

Everybody knows the result. A form has been broken for two months. A page has been loading three times slower since an update. A competitor has taken a topic you could have owned yourself. All things you would fix in five minutes on the day they happen, and that you cannot even find eight weeks later.

That is exactly what we built agents for. They now run along on most of our client sites, and the report lands in the inbox on Monday.

What An Agent Means Here

The word is currently used for everything, so briefly and concretely: an agent for us is a program with a single job that starts on a schedule, fetches its own data, evaluates it with a language model and leaves a result behind.

No chat window. Nobody types anything. They run at night, each with its own assignment, on our servers in Germany.

The specialisation matters. An agent meant to check everything checks nothing properly. One that looks exclusively at visitor numbers knows its numbers and notices when one of them steps out of line.

What The Report Says

On visitors: how many came, from where, what they clicked, where they dropped off. Not a graveyard of tables but three paragraphs with what stands out. A report nobody reads is not a service.

On competition, the question is what comparable players nearby are doing right now, which topics pull for them, where they are weak. That is where the concrete suggestions come from about what should go on the site next. It is the part that most often leads to an action.

On AI visibility, the question is whether the site is cited by language models, on which questions, and which sources stand next to it. That question did not exist two years ago. Today it matters more to some businesses than their position on Google, because a user who gets an answer in a chat never looks at a results list. Whoever does not appear there does not exist in that transaction.

On technical health it is about slow images, missing labels, broken structured data, pages that accidentally stopped being indexed. These faults never announce themselves. They cost visibility quietly, and you only find them if somebody looks regularly.

The Point Where This Differs From A Tool

There are services that will send you those numbers too. The difference comes after.

When one of our agents finds something that needs fixing, we set the fix in motion. The client does not get a list of findings plus the job of dealing with them. They get the information that it was noticed and the news that it was handled.

That is the entire difference between a monitoring tool and being looked after. A tool creates work. Being looked after takes it away. For a business with neither the time nor the interest to study charts, that is the only difference that counts.

Where The Data Comes From, And Where It Stays

The sources are the usual ones: the search engine console, the webmaster tools, the analytics tool of the site in question, and the site itself.

Consolidated, that data sits in our system with a separate data space per client. It is not passed to third parties for their own purposes. The report is written by a language model, and anyone wanting a copy of their data or the account deleted gets both.

We say deliberately that the reports are written by a model. A report pretending somebody wrote it by hand would be a small lie with the drawback of eventually being found out.

We Are Our Own Hardest Case

Everything described here runs on our own sites first. The agents check our sites, our visibility inside the models and our servers every night, and are on the table with a report in the morning.

That is not a marketing sentence, it is the reason we know the failure modes. A system you only operate at other people's places, you know from the manual. A system that catches you out early in the morning with a real problem, you actually know.

And honestly: we see the uncomfortable findings at our own place first. That is the proof that the thing works, and at the same time a good reason not to switch it off.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

A Tool That Gets Used Outdoors

Matthias | StudioMeyer — Sun, 11 Oct 2026 23:27:05 +0000

Most software for small businesses is designed for a desk. Large screen, stable connection, quiet, time.

For a real estate office on Mallorca we built a tool for recording properties. And the place where that happens is not a desk. It is a finca in the interior, at midday, on a half-empty battery and poor reception.

That sounds like a detail. In fact nearly every decision inside the thing follows from it.

Built For The Phone, Not For The Screen

Input runs step by step rather than as one long form, and it is made for a thumb, not for a mouse.

Photos come straight from the camera. The location is taken from the device rather than typing an address that, for a plot in the interior, often does not exist. Everything saves itself continuously, and a started draft can be picked up later on the same device.

That self-saving is not a convenience but the condition for the tool being used at all. Anyone standing outside who loses half an hour of work because the connection drops does not open it a second time.

What Fits In No Field Still Needs A Place

The most important part is not a field but a note trail.

Every property carries knowledge that cannot be pressed into categories. The access road is difficult in winter. The neighbour is thinking about selling too. The permit is in progress, but not in the usual way.

A rigid form either forces that into an ill-fitting field or loses it. So a note can be added to any property at any time, without structure, without required fields. That is the catch-all for everything you cannot foresee at design time, and without it the tool would be unusable in practice.

Photos Get Resized, Not Beautified

A deliberate decision that needs explaining in the age of image generators: the tool resizes and compresses photos, and nothing else.

No brightening, no sky replacement, no removing of objects in the way. Technically that would be easy. It is still wrong, for two reasons. One is legal: showing a property differently from how it is puts you in territory where somebody eventually stands there with a lawyer. The other is practical: the prospect will stand in front of the house at some point. The gap between picture and reality is exactly the moment an appointment falls apart.

The Data Belongs To The Office

The tool can export the properties as a table and in the exchange format the large property portals read.

That sounds like a side note and is a matter of principle. Anyone maintaining their properties in a system they cannot get them out of again has made themselves dependent. The vendor can then raise the price, and you pay, because moving would cost more.

So for tools we build for clients the rule is: there has to be a way out. Not as a concession but as a design feature. A client who could leave at any time and stays anyway is the only kind of client worth having.

Roles, Because Not Everyone May Do Everything

A real estate office does not consist only of agents. There are people who find and record properties out in the field, and people who decide what goes on sale.

That separation sits inside the tool. Whoever records creates drafts and sees their own. Whoever is responsible sees everything and publishes. Between them runs a clear path from draft through review to active listing, on to reserved, sold, archived.

Without those stages you immediately get dead entries: half-finished records where nobody knows whether they are still current. With them, everybody sees at a glance where something stands.

Operable From The Chat As Well

The newer part: the tool can also be operated from an AI assistant. Instead of opening the interface, you can ask which properties are currently in review, or create a new search profile.

The benefit is not the convenience but the distance. An office tool gets opened when you have time. A question gets asked in passing. Anything that lowers the barrier between "I should" and "done" decides whether a system gets used or quietly falls idle.

What I Take From This

Before designing software for a business, you should know where it will be used. Not what it should be able to do.

A tool for the desk and a tool for outdoors look identical on a requirements list. They get built completely differently. Skip that question and you build something that convinces in the demo and sits untouched in daily work.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

An AI Workplace That Opens In A Browser

Matthias | StudioMeyer — Sun, 11 Oct 2026 01:57:04 +0000

Most people use AI in a chat window in the browser tab next door. You type a question, copy the answer, paste it into a document. That works and is manual labour in the long run.

The next step is not a better model but a different place. The assistant should not sit next to the work, it should sit inside it.

For a copywriting studio in Germany we built exactly that: a complete workplace that opens in a browser, with the assistant right beside it.

What It Feels Like

You open an address, type a password, you are in. On the left a familiar editor window with the files, on the right a chat where the assistant thinks along. No installation, no program that has to live on one particular machine.

In practice that means the workplace is the same on the Mac at home as on the iPad on a train and on a borrowed machine in a hotel. There is no version that is newer on one device than another, and nothing you can forget to bring.

For a one-person business that is worth more than any extra feature. The alternative, a workplace that exists on exactly one laptop, is an outage waiting to happen.

The Assistant Sees The Files, Not Just The Text

The real difference to a chat window is access to documents.

A client sends a briefing as a Word file, a spreadsheet with target group data, a PDF with requirements. The assistant reads that directly, without anybody copying text out. And it writes back the same way: a Word document with headings, lists and formatting, not a block of text you tidy up by hand afterwards.

That sounds like a small thing and is the point where the time saving actually appears. Copy and paste costs only a minute in any single case. Across a month of jobs it is the difference between a tool and a toy.

The inbox is connected as well, though in one direction. The assistant can read the mail and prepare replies. It sends nothing. That is not a technical limit but a decision, and the most important one in the whole setup.

Memory Is The Part That Stays

A chat window starts from scratch with every conversation. In copywriting that is the most expensive drawback there is, because knowledge about a client is precisely what you get paid for.

So this workplace has a memory attached. It keeps clients, style rules, earlier decisions and agreements across weeks and months. On the next job the assistant knows which client needs which tone, what worked last time and what is off-limits.

That changes the nature of the collaboration. Without memory you explain the context again before every task, and eventually you stop and do it yourself. With memory, explaining pays off, because it happens once and then holds.

Two Guard Rails That Were Not Negotiable

The first concerns files. The assistant cannot delete anything unintentionally and cannot blindly overwrite a file. Anyone letting a language model work inside a directory of real client work has to build that barrier before doing anything useful with it. Otherwise the question is not whether, but when.

The second concerns style. Before every reply the assistant is handed the house style rules. Sounds trivial, but it is the difference between usable drafts and the smooth default tone everybody recognises instantly. A copywriter whose drafts sound like a text kit gets nothing out of the tool.

Where The Data Sits, And What That Actually Means

The server stands in Germany and belongs to the studio. The credentials for mailbox and documents live exclusively there and do not run through our systems.

What belongs in the same breath, honestly: whatever is sent to the language model leaves the EU, because that is where the model runs. This distinction gets blurred a lot. So on every project like this we write down what leaves the server and what does not, and the client reads it before the start, not afterwards.

Whatever access is needed for maintenance is written down in the project, traceable, and under the owner's control. That belongs settled before the start, not afterwards.

Who This Fits

Not everybody. If you use AI occasionally for a phrasing, you do not need a server of your own.

The setup pays off when three things come together: you work with it daily, you work with documents rather than only text, and it involves clients whose preferences you do not want to explain from scratch every time.

Then the maths tips over. And the difference is not that the assistant gets smarter. It is finally standing in the right place.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

A Learning Platform Run By Agents

Matthias | StudioMeyer — Tue, 29 Sep 2026 19:06:05 +0000

The most interesting part of our learning platform is not the content. It is the question of who makes it.

The Academy is a site with lessons, recipes and guides for building your own AI systems, in six levels from the entry point to your own MCP server. It has no editorial team in the usual sense. It has a group of agents, each with a role.

The Roles

There is one that researches what is moving out there. One that turns that into topic proposals. One that writes. One that reviews what was written and is allowed to reject it. One that watches the numbers, meaning what gets read and what sits idle. And one that checks whether the site appears in AI answers at all.

That division is the actual trick. An agent reviewing its own text finds nothing. It just decided the text was good, otherwise it would have written it differently. Self-review works about as well with language models as with humans.

Separating Makes The Difference

As soon as writing and reviewing are two different agents with two different assignments, something happens.

The reviewer has no reason to defend the text. Its assignment is to find weak spots, and it finds them. Not because it is smarter, but because it is looking from somewhere else.

That same pattern now sits underneath almost everything we build with agents. One agent that builds and a second that refutes. Where the second is explicitly told to find something, not to "have a look".

What Stays With The Human Anyway

Three things.

The structure of the whole. Which six levels exist and what belongs in which is a didactic decision. An agent can propose gaps, but the build of a course is an opinion about how people learn.

The release. No text goes live without a human. That is not a question of quality but of liability: what stands on a page is the operator's responsibility, not the model's.

And the tone. A model writes correctly and interchangeably. The difference between an explanation that lands and one that is accurate is still handmade.

Why The Topic Agent Is Tied To The Structure

An agent proposing topics while only looking at what is currently in season produces pieces about whatever is currently in season. That is not a course, that is a news ticker.

So it hangs off the course structure rather than the news cycle. It proposes what is missing at a given level, not what is being searched for a lot. Fewer proposals, and usable ones.

What It Is Good For

The Academy sells nothing. It is free and needs no account.

The reason we run it anyway is twofold. First, it is the best rehearsal we have: whatever we claim about memory-first working and agent patterns has to stand there in a form somebody without our backstory understands. Anyone who cannot explain something has not understood it.

Second, it is the evidence. A learning platform run by exactly the kind of system it explains is a different kind of proof than a reference list.

When the operation slips, you see it there first. That is uncomfortable and precisely the point.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

An Agent Fleet, Sorted By Job

Matthias | StudioMeyer — Tue, 29 Sep 2026 17:26:56 +0000

"We have agents" is about as informative as "we have software". The question is what they do, when they run and who notices when one stalls.

Ours grew into a fleet step by step. Not planned but grown: every single one came into being because a job was too regular to do by hand and too ambiguous to pour into a script.

This piece describes the groups, not each individual. A list of all the names would be an enumeration without insight.

The Rule Behind The Split

An agent has one job. Not two.

That sounds like bureaucracy and is the reason the fleet works. An agent meant to check analytics and also watch competitors does both mediocrely, and when the result is poor you do not know which half caused it.

Two agents with one assignment each are sharper and, more importantly, judgeable separately. You can improve one without touching the other.

The Groups

Leadership are agents that summarise rather than work themselves. They read what the others produced overnight and turn it into a report of what needs attention. Without that layer you would get a pile of separate notifications in the morning and read none of them.

Engineering looks at the code and the systems. What has grown, where warnings pile up, which dependency has a known hole, where the architecture has drifted from what is documented.

Content covers research, topic proposals, drafts, review. Always with separate roles for writing and reviewing, because an agent reviewing its own text finds nothing.

Visibility covers search engine standings, mentions in AI answers, visitor numbers, what competitors are doing. This group runs for our own sites and for client sites.

Operations handles servers, backups, certificates, containers, cost. The most thankless group, because its best day is the one where it reports nothing.

Review consists of agents whose only purpose is to attack the others' work. They write nothing and build nothing. They look for faults in whatever just got finished.

The last group is the one that delivers most.

Why The Reviewer Needs A Role Of Its Own

A model that built something and is then asked whether it is good says yes. Not out of malice, but because it just built the thing the way it thought was right.

A reviewer with its own assignment behaves differently, especially when the assignment is not "review" but "refute". The hardest findings come from that group, including on things that had already passed other checks.

It gets better still when the reviewer comes from a different model family than the builder. Two models from the same house make similar mistakes and overlook each other.

What Happens At Night

Most of it runs when nobody is around. That has a practical reason: an agent that takes a long time for a pass is in the way during the day, and nobody likes waiting for a report.

In the morning the result is there. Not as raw data but as text with what stands out. A report consisting of numbers without interpretation stops being read after two weeks.

What They Are Not Allowed To Do

None of these agents sends a mail to a client. None changes anything on a client site without a human in between. None deletes anything.

That is the hardest boundary in the whole setup, and it is deliberately enforced technically rather than merely stated as an instruction. An instruction is a request. A tool an agent does not have in the first place is a boundary.

The Number, And Why It Is Not Here

It would be easy to name a figure. It sounds good and is almost always misleading.

Count files and you get a large number that includes helper parts and sub-agents which never run alone. Count only what starts on a schedule and it is fewer. Count what produces something daily that a person reads and it is fewer still.

All three numbers are correct and mean different things. So we would rather name the groups and what they do. Anyone who needs a figure should always ask what was counted.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

EU-Sovereign AI: Why We Don't Put Inference in the US Cloud

Matthias | StudioMeyer — Sun, 27 Sep 2026 21:03:01 +0000

When we build a chatbot for a client project, generate a product image or clone a voice, something happens in the background that almost nobody talks about: the actual compute work runs on servers in the United States, nearly every time. Replicate, fal.ai, OpenAI, Together, half the industry sits there. For a German tax firm or a hotelier on Mallorca, that means their prompts, images and sometimes customer data travel across the Atlantic and back. This is the blind spot of the current AI wave, and we deliberately handle it differently.

What AI inference actually is

Short and without jargon: an AI model has two phases of life. Training is the expensive, one-time part where the model learns. Inference is what happens millions of times afterwards, every time someone asks a question, generates an image or turns a voice message into text. Every chatbot sentence, every generated photo, every text-to-speech readout runs an inference.

That compute work needs specialized graphics cards that very few companies run themselves. So you rent them as an API from a provider. You send the prompt, get the result back, pay per use. Convenient, cheap, scalable. And in the vast majority of cases, that provider's server sits in Northern Virginia, not in Frankfurt.

Why the US cloud is a real GDPR problem

This isn't a gut feeling, it's the legal reality. Two things interlock here.

First, the US CLOUD Act of 2018. It obliges US companies to give US authorities access to data on request, no matter where in the world that data physically sits. A US provider with a data center in Ireland is just as affected as one in Texas. The server location alone does not solve the problem.

Second, the shaky legal basis for the data transfer itself. In 2020, the European Court of Justice struck down the then-current Privacy Shield in its Schrems II ruling. Its successor, the EU-US Data Privacy Framework of July 2023, is already under fire again, with a member of the European Parliament having filed a challenge before the EU's General Court. Anyone basing their data processing today on this single adequacy decision is building on a foundation that has already wobbled twice in recent years.

For most small businesses this stayed abstract for a long time. With AI it becomes concrete, because suddenly real content flows through these pipelines: a patient's email to the practice chatbot, a property photo sent off for editing, a guest's recorded voice message. These are exactly the kind of data the GDPR is meant to protect.

What EU-sovereign inference means

The countermovement is called sovereign AI. The core idea is simple: the compute, the models and the contracting party all sit in Europe, are subject to European law and to no CLOUD Act. Your data does not leave the European legal space.

To be honest, sovereignty here is a spectrum, not a switch. Some providers run their own hardware in European data centers, others route through European regions of larger cloud providers, and still others aggregate third-party models and put a European contract and billing layer on top. The practical gain is the same in all cases: a European point of contact, GDPR-native contracts, data residency in the EU, and a provider who understands why that is not a mere formality.

An example right on our doorstep: Socaity

When a project needs image, voice or video generation, we look for the compute in Europe first. One of the providers we work with for this happens to sit five minutes from our office, in Palma de Mallorca: Socaity.

Socaity bundles AI models for image, video, voice, 3D and text recognition behind a single API, with European routing, one contracting party and one invoice. The approach is deliberately built to be EU-sovereign, the company is based in Palma, the data processing is GDPR-native. Instead of signing up with five different US services and clarifying data processing with each one separately, you get one European gateway to many models.

For us this is more than a technical footnote. It is a concrete piece of infrastructure from our own ecosystem, built by a founder who comes from twenty years of hand-written code and treats sovereignty not as a marketing label but as an architectural decision. Exactly the kind of partner we want to work with.

What this means for your project

Concretely, it means the question of where the servers sit belongs in the planning phase, not in the privacy policy at the end. Before a chatbot or an image pipeline enters a project, we clarify where the content gets processed. For anything involving personal or sensitive data, the European option is the default, not the exception.

That rarely costs more and delivers two things at once: legal calm and an honest selling point. A hotelier who can tell guests that their requests never leave the EU has a trust argument a US pipeline will never provide. It fits the way we build anyway: the websites we ship are hosted on European servers, GDPR-compliant and without tracking cookies. The inference layer is the logical continuation of the same stance.

Honestly: the limits

To keep it fair. Europe's providers are smaller today than the US giants. The model selection is sometimes narrower, some new models appear on US platforms first, and part of the EU providers themselves pass larger catalogs through in the background. Anyone looking for the absolute biggest model buffet at the lowest price per call still often lands at a US service for now.

So the honest trade-off isn't "EU always and everywhere," but: where personal data flows, legal certainty outweighs the last cent of price difference. Where it's about purely internal, anonymous experiments, a US service can be perfectly fine. We make that distinction per project, not by dogma.

The takeaway

The AI wave has a quiet side effect: it is currently sending a great deal of real customer data from a great many small companies through American data centers, usually without anyone having asked the question. For us, that question belongs in the first planning round, not in a footnote. European inference is mature enough today to be taken as the default without giving up quality. And the fact that one of the providers for it sits a few streets away in Palma only makes the decision easier. If you want to know how we implement this in a concrete project, get in touch or take a look at how we work.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.

How to Turn ChatGPT Into a Work System

Matthias | StudioMeyer — Fri, 25 Sep 2026 23:35:32 +0000

The answers are good. That is rarely the problem. The problem is that every new conversation starts from nothing, and you explain yourself again.

So you do the obvious thing. You write down everything important in the custom instructions, the field that travels with every conversation. Your role, your company, your tone, your clients, the things it got wrong last week. The field fills up. And somewhere along the way the answers get worse, not better, and it is hard to say exactly when that happened.

What follows is the other approach. Not better prompts, but a place for everything, so the assistant pulls what a task actually needs instead of carrying all of it all of the time.

A Chat Is Not a System

A chat is one conversation. A system is what stays when the conversation is closed.

The difference shows up in a small, ordinary test. Ask the same recurring task twice, four weeks apart, and compare. If the second answer is worse, or simply different in ways nobody decided, then nothing was ever built. The knowledge lived in a chat window, and chat windows are not storage.

Building a system means answering three questions once: how do we work, what are we working on, and what have we learned along the way. Each one belongs somewhere different. Almost all of the trouble comes from putting all three in the same place.

The Standing Instruction Is the Most Expensive Space You Have

Custom instructions apply to every conversation you have, immediately, including the ones already open. That is what makes them useful and that is what makes them dangerous. Everything in there is paid for in every single chat, whether the current task needs it or not.

So the standing instruction should answer exactly one question: how do we work together. How direct you want answers. Whether you want to be asked or told. What to do when something is uncertain. When to push back. Whether you want the reasoning or just the result.

What does not belong there: your price list, your client names, your project status, your product details. Not because it is secret, but because it is specific. A price list in the standing instruction is read during a task that has nothing to do with prices, and it goes stale without anyone noticing, because nobody rereads a field they wrote four months ago.

A good test: if a sentence would be equally true for a task you will never do, it belongs somewhere else.

One Project per Thing, Not per Tool

Projects in ChatGPT hold chats, files and their own instructions in one place, so you do not restate the background every time you open a new conversation.

The useful part is the separation. With project-only memory, conversations inside a project can reference other conversations in that same project, but not the ones outside it, and nothing outside can see in. That is not a small convenience. That is the difference between an assistant that keeps your two businesses apart and one that quietly mixes them.

The mistake worth avoiding is cutting projects by tool or by month. One project for writing, one for research, one for September. Those boundaries do not match how work actually arrives. Cut by subject instead: one client, one business, one product, one recurring job. When a task starts, the right project is obvious, and everything irrelevant stays closed.

Knowledge Goes in Files, Not in Instructions

A project takes files. That is where the actual knowledge belongs, and it is worth being deliberate about how it is split.

One file per subject, not one file for everything. How you position your business. What your brand sounds like. What you offer. How a particular recurring job gets done. Small files with obvious names beat one long document, because the assistant can be pointed at the right one, and because you can fix one without touching the others.

The reason is boring and decisive: the file you fix in passing stays true, and the file you have to rebuild does not. Knowledge that is annoying to correct becomes wrong knowledge.

Loading Everything Is Not the Same as Knowing Everything

This is the principle underneath all of it. Available context is not relevant context.

An assistant with access to your entire business is not more capable than one that opens the two files a task needs. It is less capable, because everything it reads competes for attention with everything else. A text for your homepage needs your positioning and your tone. It does not need last year's invoices, your client list, and a campaign from two summers ago.

In practice this means naming the thing when you start. Not a ritual, just a sentence: we are working on this client, this product, this job. The default state is that nothing specific is loaded, and that default is correct.

Write Down What It Learns, Where You Can Read It

Over months, the useful part is not what the assistant knows about the world. It is what it knows about your work. The decision you made and why. The assumption that turned out wrong. The preference that keeps coming back. The approach that failed.

Keep that in a file you can open. Four short files per subject work well: decisions, corrections, preferences, failures. One line each, dated, in the words you would actually search for later. Written at the end of a task, and only when something would genuinely change next time.

The discipline that matters is restraint. A log that grows after every task is unusable within weeks. If nothing came up, nothing gets written. And when a file entry and a current fact disagree, the current fact wins and the entry is history, not a contradiction to resolve.

The Built-In Memory Is a Second Source, Never the Truth

ChatGPT has its own memory: things you asked it to remember, plus impressions gathered from earlier chats. It curates that in the background, updating entries as time moves past them, and you can switch it off, delete single items, use a temporary chat, or look at which memories shaped a given answer.

Useful, and not something to build on. You cannot query it on demand, you cannot scope it to one subject, and you did not decide what went in. Treat it the way you would treat any source you do not control: a helpful addition, never the thing your work stands on. The honest test is whether your setup still works with memory switched off. If it does not, the memory is not helping you, it is holding something that should have been written down.

This is also where a promise gets made too easily. Structure makes good answers more likely. It does not make wrong answers impossible, and anyone who tells you otherwise is selling something.

Start With a Single Subject

Not with the whole build, but with the subject you work on most often.

Make the project. Put in three or four short files: what this is, how it sounds, what matters. Cut your standing instruction down to how you want to be worked with, and move everything factual into the project where it belongs. Then run one real task and watch what it opens.

The change you notice is not that the answers get smarter. It is that you stop explaining yourself. The work moves from writing prompts to filing things in the right place, and filing is a thing that stays done.

Originally published on studiomeyer.io. StudioMeyer is an AI-first digital studio building premium websites and intelligent automation for businesses.