News

Build an App With AI: What Works, What Doesn't

04 October 2026 · DigifyNow

Auf Deutsch lesen

When you build an app with AI, a language model turns a plain-language description into code for the screens and the database. That's enough for a clickable prototype. Once real data is involved, a person has to define access rights, move API keys to a server, review and test the generated code, and follow the store rules, including Apple's rules against apps with too little functionality of their own. DigifyNow uses AI as a tool in projects. It doesn't replace architecture or code review.

Can you build an app with AI, and what do you actually get?

Yes, with limits. Most people who build an app with AI today use a language model that turns a plain-language description into code: screens, forms, database tables and sometimes a connection to a login service. The model predicts the most likely next piece of code. It doesn't check whether that code matches how your business actually works. For a clickable prototype, that's often enough after just a few hours. You can use it to show your team how a workflow should look and collect feedback before you spend money on the real build. Things change once real customer data, multiple user roles or an App Store release come in. Then you're dealing with access rights, error handling, updates and maintenance. A generator won't think about any of that by itself, because it's rarely in the description. The phrase also has a second meaning: an app that has AI built in, such as an assistant that sorts incoming requests. You can do both at once, but each needs different decisions, so we cover them separately below.

Building an app with AI: where do generated apps fail in practice?

The problems with AI-generated apps are rarely exotic. Usually the missing pieces are the ones you can't see in a prototype. These are the patterns we run into when we're asked to take over or review this kind of app:

• An open database: Many generators use a Postgres backend. If Row Level Security isn't turned on there, or the rules are written wrong, any logged-in user can read or change other people's records.
• API keys in the app code: Anyone can read what's inside the app package, because an APK or IPA file can be unpacked. Keys for AI or payment services belong on a server.
• Made-up libraries: Language models sometimes suggest packages that don't exist. Attackers register those names on purpose. This is called slopsquatting.
• Store rejection: Apple's App Review Guidelines require an app to do something useful of its own. Apps that just wrap a website get rejected. So do apps that are obviously built from templates and look a lot like other apps.
• Code nobody can maintain: Every change made by prompt regenerates code. Without automated tests, something else breaks and nobody notices.

None of this is an argument against AI as a tool. It just shows that code review, testing and deliberate architecture are still human work.

How does DigifyNow use AI in app development?

At DigifyNow, AI writes routine code and builds first prototypes. People make the decisions that affect your data and access rights. Here's the process:

1. Map the workflow: who uses the app, which few core tasks it should handle, and what data it creates.
2. Build a clickable prototype, partly with AI, and walk through it with the people who'll use it before any production code gets written.
3. Define the data model and roles by hand: who can read, edit or delete which records.
4. Build in short iterations: AI assistants write the boilerplate code, and every piece goes through code review and automated tests.
5. Release: submission to Apple. For new personal Google Play developer accounts, Google requires a closed test with a minimum number of testers over a set period before launch.
6. Operations: updates for new iOS and Android versions, monitoring and bug fixes.

We plan an MVP with the core features in weeks, not months. That's what we've seen in our own projects, not a promise for yours. We can only say how long your project will take after an assessment, because roles, integrations and the store review shape the schedule more than writing the code does. If the schedule keeps growing during planning, the MVP usually still has too many features and needs to be cut down further. Reports or an admin area, for example, can move to phase two. We cover the full process of building an app, including how to choose a platform, in a separate article on the app development process.

What does an app need if it has AI features built in?

If the app itself uses AI, for example to describe photos in damage reports or sort customer requests, the calls to the language model go through your own server, not straight from the app. There are three reasons for this. The API key stays out of the app package, you can set a request limit per user, and every request gets logged. Language models often take several seconds to answer, so we stream responses piece by piece and users don't stare at a blank screen. If the AI provider processes personal data on your behalf, the GDPR requires a data processing agreement. And sometimes AI just isn't worth it. If fixed if-then rules can handle the task, a rule is cheaper, faster and easier to trace. If you want a system to carry out several steps on its own, it helps to know how to build an AI agent and where the limits are.

On top of that, there's the EU AI Act. It includes transparency obligations. For example, users should be able to tell that they're interacting with an AI, and providers of systems that generate synthetic text, images, audio or video have to take their own measures for that. Providers and deployers also take measures to support the AI literacy of the staff who work with the system. They don't have to guarantee any particular level of skill. The stricter rules for high-risk systems phase in later. Which obligations and deadlines apply to your specific system is best clarified with legal counsel. Whether your use is permitted depends on how you run it, and no technology can promise you that.

Who builds apps in the Westerwald region?

DigifyNow is based in Unnau in the Westerwald region of Germany. The team works across Germany, with a focus on the Westerwald, Koblenz and Siegerland. For local companies, that means we can map the workflow on site, wherever the app will actually be used: in the workshop, the warehouse or out in the field. That's often when we notice that a form has to work on a phone while wearing gloves, or that there's no Wi-Fi in the building. In that case the app needs an offline mode that stores data locally and syncs it later. What we can show you: the party game app Festino, a product of DigifyNow, which is live in the App Store and on Google Play, and a custom back office with CRM for Mundo Marketing. Not every idea needs an app in the stores. If the tool is only used internally on computers and tablets, a web app in the browser is often enough. That way you skip the store review and the testing phase. There's more on app development in the Westerwald on the page about our service area.

How do you spot a good app developer in the Westerwald?

Whether an app developer in the Westerwald or anywhere else is right for you comes down to a few specific questions you can ask before signing anything. The answers should be things you can verify, not just things that sound nice:

• Published apps: Are there apps you can download yourself from the App Store or Google Play? A screenshot doesn't count.
• Source code rights: Does the contract say what usage rights you get to the code and that it will be handed over to you?
• AI-generated code: Is every piece reviewed and tested before it goes live? Ask them to walk you through it.
• Support after launch: Who responds when an iOS update breaks something, and how is that set up?
• Honest no's: Will the developer tell you when a web app is enough or when a custom app isn't worth it?

If any of these answers is evasive, treat it as a red flag, no matter how good the prototype looks.

App development agency in the Westerwald or freelancer: which fits?

It depends on how much you need besides the code. A freelancer is a good fit when the task is clearly defined, say a new feature in an existing app, and you have someone in-house who handles servers, store accounts and maintenance. An app development agency covers concept, design, backend, store submission and operations in one place. That also means the project doesn't depend on one person who might be on vacation or out sick. DigifyNow is small on purpose: Jesper Schmidt, Christian Schiebl and Miles Pandel. You talk to the people who actually build the app. The downside is that very large projects with many teams working in parallel aren't a good fit for a team this small. And if all you really need is a website with a contact form, an app agency is the wrong place to start. What drives the effort, such as roles, integrations or offline support, is covered in our article on app development cost. Whichever you choose, have the Apple and Google store accounts set up in your own company's name, not the provider's.

Request a free assessment of your project