When the system you built yourself no longer holds
Base44, Lovable or Bubble let you build something that works, and quickly. The break comes later: when real users work with it, when a tax auditor asks questions, when an interface to the inventory system is needed, or when the one person who understands the system is unavailable. Attek Solutions turns a working prototype into software fit for daily operations and takes over development and operations on a rental basis.
No-code was not the mistake
Anyone who built their own system did something right: in a matter of weeks, they worked out what a classic requirements project would not have clarified in months. The prototype runs, colleagues use it, and the need is proven.
That is a better starting point than any requirements specification.
What these tools do not deliver is operations. They are designed to get to a working result quickly. They are not designed for that result to be used, audited and developed further by twenty people over five years. That is exactly where we come in.
We have collected which problems typically occur with AI app builders, and how the tools differ in that respect, in our Knowledge section: The five most common problems with AI app builders.
Where systems built in-house fail
Four patterns we see again in almost every intro call.
Everything depends on one person
The system works, but only one person understands it — and usually only at a functional level, not in technical detail. When that person is on holiday, falls ill or leaves the company, nobody can change anything any more. If the system fails, operations stop until that one person has time.
The reason for this is structural: a prompt history is not documentation. There are no tests, no test environment and no history from which a second person could understand why something was built the way it was. Changes go straight into live operation.
In practice this means that the most expensive person in the company does unpaid system maintenance in the evenings — and that there is an operational risk that appears in no risk assessment.
Legal requirements are unresolved
As soon as a system handles commercial transactions, the GoBD rules apply. A tax auditor then asks questions that a no-code system typically cannot answer:
- Is it traceable who changed which record and when — and is the original state still recognisable?
- Are accounting-relevant data stored in an unalterable form and available for the statutory retention period?
- Is there process documentation describing how the system works?
- Where is the data held, who has access, and is there a data processing agreement with the platform operator?
With several AI app builders the backend cannot even be exported. Anyone who cannot get at their own data also cannot prove what happens to it.
None of this makes a system built in-house automatically inadmissible. But it makes it a risk that only becomes visible when someone asks — and by then it is too late to put it right properly.
Interfaces do not work as expected
No-code platforms come with connectors for popular services: Google, Slack, Stripe. The systems a German mid-sized company has to connect to are different ones — DATEV, edlohn, an inventory system grown over years, a marketplace backend, an ERP.
These rarely speak modern APIs. More common are CSV files over SFTP, proprietary XML formats, certificate-based authentication or fixed transmission windows.
The difficult part is not the connection itself, but what comes after it: what happens when a transfer breaks off? When the same record arrives twice? When both sides have changed the same record? Without proper error handling, retry logic and conflict detection, you end up with data states nobody trusts any more.
Some requirements cannot be built at all
There are functions where no-code ends structurally, not just gradually:
Offline capability
The field technician in the basement, the driver with no reception, the building site with no network. That requires local data storage, synchronisation and a rule for which version wins when two devices have changed the same record.
Fine-grained permissions
When users are allowed to see not just different menus, but different sections of the same data.
Background processing
Nightly runs, bulk imports, recurring calculations.
Large data volumes
What runs smoothly with 500 records becomes unusable at 500,000.
Formally correct documents
Invoices, delivery notes and records with mandatory details and a defined layout.
What becomes of the prototype
The prototype is not thrown away. It is the most precise specification there can be — it shows not what someone would like to have, but what is actually used.
- 01Intro call, 30 minutes. You describe your problem. We tell you honestly whether custom software pays off for you or whether off-the-shelf software is the better choice.
- 02Personal demo. Instead of slides you get software: we take a problem you described in the intro call and show it to you as a working application. That way you judge from your own case whether the effort is worth it, before you sign anything.
- 03Requirements workshop. We go through your workflows until we have understood them completely. Free of charge.
- 04Signing the contract. After the requirements workshop you receive a fixed monthly price for your requirements, and we sign the contracts.
- 05First productive version after one to two months. This is when you start paying — not before.
- 06Operations and continued development. Your workflows now run automatically and your team gains time for the business. We take care of operations, maintenance and support.
It takes one to two months to reach the first productive version. You pay from the month it is in use — there is no setup fee and no upfront investment.
The process in detail — including what you contribute yourself →
No-code, in-house development or the rental model compared
| Option | No-code, built yourself | Hiring developers | Attek CSaaS |
|---|---|---|---|
| Time to the first version | days | 6–12 months | 1–2 months |
| Upfront investment | low | €10,000–100,000 | €0 |
| Who can change it | one person | the contracted service provider | Attek, 2 changes/month included |
| If that person is unavailable | standstill | — | — |
| GoBD and auditability | unresolved | feasible, costs extra | part of the build |
| Interfaces to DATEV, ERP, inventory systems | barely possible | feasible | part of the build |
| Offline capability | no | feasible | feasible |
| Who operates it | you | you | Attek |
| Running costs | platform fee | maintenance contract plus hourly rates | From €500/month, everything included |
Frequently asked questions
I built a CRM with Base44 and it is reaching its limits. What happens now?
Attek Solutions turns your prototype into a production-ready application. The existing version serves as the template: it shows which processes are actually needed. The new application is built on a durable foundation, your data is migrated, and we take over operations and continued development on a rental basis from €500 a month.
Can an app built with Lovable or Base44 be run productively in a company?
For internal tools with no legal requirements and few users, that works. As soon as commercial transactions, personal data, interfaces to existing systems or more than a handful of users come into play, these platforms lack essential prerequisites — above all traceability of changes, dependable error handling and the ability for more than one person to maintain the system.
When does no-code reach its limits?
At four points: when only one person can maintain the system, when legal record-keeping duties such as the GoBD rules apply, when interfaces to existing systems are needed, and with technically demanding requirements such as offline capability, fine-grained permissions or large data volumes.
Will my existing application be developed further or rebuilt?
As a rule, rebuilt. The prototype is kept as the functional template, the technical foundation is replaced — with several platforms the backend cannot be exported anyway. Your data is migrated in full.
Is an application built with an AI app builder GDPR-compliant?
That depends on the individual case and cannot be answered in general terms. At a minimum, the following need to be clarified: is there a data processing agreement with the platform operator? Where is the data processed? Are deletion periods implemented? Are technical and organisational measures in place? With platforms that offer no backend export, it is also hard to prove what happens to the data.
What happens to my existing data?
It is migrated. Where the platform allows an export, we migrate directly; otherwise via the interface or an integration. The data is not lost.
Can I keep using my prototype in parallel?
Yes. It keeps running until the new version is productive. There is no need for a cut-over date on which everything has to switch at once.
What does it cost?
Between €1,000 and €1,500 a month, depending on scope. The lower limit is €500. There is no setup fee, no upfront investment and no hourly rates — development, hosting, operations, maintenance and support are included in the monthly price.
We built our tool with Airtable and the data volume is getting too large. Does this apply to us too?
Yes. Airtable, Notion and comparable tools reach their limits as data volumes grow, because they are designed as spreadsheet tools and not as databases. The approach is the same.
Do you also build individual parts instead of replacing everything?
It is possible, but rarely sensible. If one part stays in a no-code platform, the associated problems stay too — traceability, operational reliability, dependence on one person. What can be separated well: replace the critical core process first, the rest later.
Show us what you have built.
In the intro call we look at your prototype and tell you what it can become — and whether the effort pays off for you. 30 minutes, free of charge.