Guide

Custom software 2026: what has changed

What's different about custom software in 2026 compared to two years ago — legally, technically, and regarding what actually pays off for small businesses.

Quote on requestfrom 8 weeks to first versionAs of 2026
In short

Two things changed for custom software in 2026: the transparency requirements of the EU AI Act have been in effect since August, and search engines are answering more and more questions directly in the results. Technically, reliability has improved most of all — which doesn't mean every project makes sense.

01 — Current

What changed recently

Two developments shape the decision in 2026: First, the transparency requirements of the EU AI Act have been in effect since August — anyone communicating with an AI system must be able to recognize it. Second, search itself now answers more and more questions directly, which changes the value of having your own easily findable information source.

For custom software, this means in practice: labeling is mandatory, not a stylistic choice, and the content the system works with is the same content cited in search results and generated answers. If you prepare it properly once, you use it twice.

Technically, reliability has improved most of all. What was still an experiment two years ago is today a plannable implementation in many cases — which doesn't mean every project makes sense.

02 — Legal situation

EU AI Act: what applies

Since August 2026, the transparency requirements from Article 50 of the EU AI Act apply: Anyone communicating directly with an AI system must be able to recognize it. We build in the labeling as standard.

The AI Act doesn't distinguish by company size: A sole proprietorship with an AI system in customer contact is affected just as much as a corporation. What matters is purpose and risk, not headcount.

There's also the obligation to ensure adequate AI competence for the people working with it. That's not an examination requirement, but it should be documented — a training session with a participant list is the simplest proof.

03 — Benefits

What it actually delivers

  • Time that's missing elsewhere. Eventually, a sprawling landscape of spreadsheets holds the business together. Only one person knows it, it has no permissions, no history, and no backup.
  • Consistent quality. A system doesn't have a bad day and doesn't skip a step — regardless of who's currently in the office.
  • Traceability. What runs automatically is documented. That helps with handovers, vacation coverage, and in case of disputes.
  • Availability outside business hours. A significant portion of inquiries arise in the evening and on weekends — where until now no one was responding.
  • A side effect hardly anyone plans for: During setup, it regularly becomes apparent that processes in the business are unclear. Clarifying that is often more valuable than the automation itself.

04 — Questions

Frequently asked questions

What if we discover new requirements during development?

That's normal and planned for, because we work in small steps. A new requirement is incorporated into the next step, instead of stalling the entire project.

How do we avoid the project going off the rails?

Small steps with usable results, fixed budgets per step, and the option to exit after each step. Large fixed-price projects over twelve months are the most reliable path to disappointment — for both sides.

What happens if we no longer work together?

You have the code, documentation, and access. We deliberately use widespread technologies so that a switch is possible without someone having to rebuild everything.

Can we start with a spreadsheet?

Often yes, and that's a good test. If the spreadsheet maps the process and only fails due to multi-user capability, permissions, or data volume, the requirement is clear and the project is calculable.

Does this run on our own servers or in the cloud?

Both are possible. For most businesses, a cloud solution is lower-maintenance; where data must not leave the premises, we set it up on your own infrastructure.

Who owns the source code?

You do, completely, upon payment. That's in the contract. You can take it to any other developer — that's the point.

When does custom software pay off compared to standard software?

When your process is a genuine competitive advantage, when standard software only fits seventy percent and the rest ends up as manual work, or when license costs per user exceed the development cost over a few years. If it's only about convenience, standard software is cheaper.

Next step

We'll look at your starting position.

Tell us what's eating up time today. That becomes an assessment with effort and benefit — and only then an offer.