Skip to content
Grundlag

Why Grundlag?

A fair first question: most services already have an API. The ones you build yourself, you can give an API of your own. So what is left for Grundlag to solve?

For a single job against a single service, nothing — just call the API. That really is the right choice, and Grundlag does not try to change it. The cost shows up somewhere else: the moment you want to use your services together, and from more than one place.

You don’t use APIs — you use platforms

Section titled “You don’t use APIs — you use platforms”

Think about how you actually reach your services day to day. You rarely hand-call raw APIs. You reach them through platforms — a workflow automator, a coding agent, a spreadsheet, an app. And every platform speaks its own dialect.

Say you pick up a workflow tool like n8n. It brings all its supported services into one model, which is exactly what makes it powerful. Some of your services are built in; others aren’t, so you build custom nodes for them. Then you configure every one — credentials, endpoints, the little quirks. It works, and it’s great.

Now you want those same services available to Claude Code. But Claude Code doesn’t speak n8n nodes — it speaks MCP. So you go find an MCP server for each service, build the ones that don’t exist, and configure each service again. New platform tomorrow? Same process, a third time.

Your integration work and your configuration never accumulate. They reset with every platform. With N services and M platforms, you are on the hook for roughly N × M integrations — and the same credentials get re-entered M times over.

Grundlag is the catalogue

Section titled “Grundlag is the catalogue”

Grundlag turns that around. You integrate and configure each service once, as a provider on your own server. What you get is a catalogue: a set of capabilities in known, typed shapes — already authenticated, already configured — that belongs to you and travels with you.

Platforms then connect to the catalogue through thin adapters, not another round of integration:

  • A workflow tool? Point it at your server, and every action becomes a node, every event a trigger.
  • Claude Code? One MCP adapter exposes every action as a tool — no per-service setup.
  • A script? Import a typed client and call the same actions directly.
  • An app or an agent? The same catalogue, the same actions.

Add a new service later and you configure it once — it lights up across every platform, script, and agent you already use. Adopt a new platform and you write (or reuse) one adapter — your whole catalogue comes with it.

The math flips from N × M to N + M: N providers you build once, M adapters shared across all of them.

One configuration for your digital life

Section titled “One configuration for your digital life”

That is the whole point. Configure a service once, and it is exposed to any script, available to any agent, and usable from any platform that can speak one small adapter — one surface carrying all of your digital life, in a single configuration you own, rather than scattered, re-entered, and re-authorized inside every tool you happen to try.

And because the capabilities live in your catalogue instead of inside any one platform, you are never locked in: the data and actions are yours to point somewhere else — or out of Grundlag entirely.

Next

Section titled “Next”