Custom software and integrations, built to order

What is an integration?

An integration is a small program that moves data between two systems, for example orders from a web shop into inventory. It fetches the data through an API, an export file or the database, checks it, converts it into the format of the target system and raises an alert when something goes wrong.

What we build

Most software problems in small and mid-sized businesses fall into one of three drawers: a tool is missing that doesn’t exist off the shelf. Two systems don’t know each other, and someone types data from A to B. Or a ready-made system would be the answer, but nobody has time to choose it, set it up, and bring the old data along. All three are our daily work, as a small developer team with an office in Berlin-Schöneweide.

Having an integration built

Accounting here, industry software there, and Excel plus manual work in between. We program the interface: orders from WhatsApp Business straight into the till, the booking system into your accounting, the web shop into inventory, invoice data into DATEV. Where the systems offer an API, we use it. Where they don’t, we work with export files or directly with the database.

Every integration is cut small, documented, and comes with defined behaviour for when something goes wrong. Whether it runs as its own service or as a workflow in n8n, we decide with you based on data volume and maintainability. If whole processes should run on their own beyond the interface, such as receipts or requests, see our page on AI automation.

How we build an integration

Every record takes the same path. For each step we decide in advance what happens on failure.

1. Fetch: the integration polls the source system on a schedule, or a webhook tells it as soon as something new arrives.
2. Check: fixed rules validate required fields, formats and plausibility, for example whether an item number exists in the target system.
3. Convert: fields are mapped into the target format according to the agreed field mapping.
4. Write: the record is transferred completely or not at all, so you never get half an order or half a booking.
5. Confirm: a record only counts as done once the target system acknowledges it. Every run is logged.

The error path branches off at steps 2 and 4. A record that fails the check goes to a review list with the reason, and the others carry on. If the target system does not respond, the record waits in a queue and the integration retries at growing intervals. If that still fails after the agreed number of attempts, a named person gets a message. Nothing is lost and nothing is created twice.

Access methods and formats in brief

Syncing only what changed, and handling conflicts

An integration usually transfers only what changed since the last run (delta sync), detected by a change timestamp, a sequence number or the webhook itself. Each record keeps a fixed mapping between its ID in system A and its ID in system B, so a second run after an outage creates no duplicates. When the same record changed in both systems, say a customer address in the shop and in the CRM, a rule decided up front says which system leads for which field. Cases the rule cannot settle go to the review list, and a person decides.

Monitoring, logs and alerts

Each run logs when it ran, how many records it moved and which ones failed with which error. Where traceability matters, for booking data for instance, we add an audit trail of which run changed which record when, and what was there before. Monitoring checks that runs actually happen; if one is missing or errors pile up, a message goes out by email or to your team chat. Who receives it, someone on your side or ours, is part of the handover.

Connecting older systems

A home-grown Access database, a FileMaker solution or a shared Excel list does not have to be replaced to be connected. Access can be read and written over ODBC. FileMaker Server has its own Data API, and older versions are reachable over ODBC too. An Excel file works if it lives in a fixed place and its columns stay the same. Often the better step is moving the list into a small database your team keeps editing in the browser.

Which systems we connect

The kinds of systems repeat: inventory and ERP, web shop, CRM, point of sale, accounting, calendars and booking systems, plus industry software with its own database. Whether a specific product can be connected we check in the first call, using its documentation or a sample export.

Custom integration, n8n or a ready-made connector?

We recommend the simplest route that meets your requirements.

Custom software and web applications

Staff-scheduling tools, a lean CRM that brings calls, emails and bookings together, a POS connected to your accounting, a multilingual ordering flow in the browser. When a good ready-made solution exists (often Shyftplan, Crewmeister or Papershift for scheduling, SumUp, Lightspeed or helloCash at the till), we set it up and adapt it. When it doesn’t, we build something custom. And tell you beforehand what it costs.

Setting up ready-made systems and migrating data

Often the best software is one that already exists. We help you choose, set the system up, move the data over from the old system or from Excel, and check after the move that everything arrived. If a connection to the rest of your software is still missing afterwards, we build it as part of the same job.

From first call to handover

1. First call, 15 minutes: you describe which data should go where. We tell you whether and how that works.
2. Scoping and quote: we look at the access options (API documentation or sample exports) and draft the field mapping. Scope, cost and timeframe are in the quote.
3. Build: we work in small steps and show progress, so you see early whether the data arrives correctly.
4. Test run: before go-live the integration runs on test data or anonymised copies of your real data, in a test environment where the systems offer one. You check the results and sign off.
5. Go-live and handover: we switch over, watch the first runs and compare samples across both systems, then hand over documentation and access.

What you get at the end

• Field mapping: which field in system A becomes which field in system B, including every conversion
• Data-flow diagram with all systems involved and the error path
• OpenAPI description if we provide an API ourselves
• Test run log
• Operations guide: how to check runs, resend a record and who gets alerted
• Source code in a repository on your account

After go-live: maintenance and API changes

Integrations depend on systems that keep changing. Vendors update their APIs, retire old versions or renew their sign-in methods. If you want, we take on maintenance: we follow vendor announcements, adapt the integration in time and respond when monitoring raises an alert. Scope and response time are then part of the quote.

Code, access and exit

Code, access and documentation belong to you. The source code sits in a repository on your account, access to servers and services is in your name, and the documentation lets another developer continue without us. We use common tools and open formats so you can switch at any time.

Data protection and security in your project

These measures apply to your projects:

• Servers are in the EU by default; on request we run the integration on your own servers.
• Each integration gets only the permissions it needs, through its own account instead of a personal one.
• Data is encrypted in transit, and passwords and API keys are stored encrypted in a vault, never in the code.
• Where we process personal data, we sign a data processing agreement (AV-Vertrag) with a list of subprocessors.

Based in Berlin-Schöneweide, working across DACH

Our office is in Berlin-Schöneweide. We are happy to meet businesses in Berlin and Brandenburg in person; with everyone else in Germany, Austria and Switzerland we work over video calls.