Flutter or native: how we decide for a new app
Most apps should be built once in Flutter. Some should not. Here is the short checklist we run through with every client before writing a line of code.

When a client says they want “their own AI”, they usually mean one of three things. Sorting out which one, early, saves a lot of money.
You take a model like GPT or Claude, give it a system prompt that says “you are the assistant for Acme Ltd”, and put a chat window on the website. It costs very little and takes days to set up.
It is also where most disappointing AI projects live. The model knows nothing about your products, your prices or your policies, so it guesses — politely and confidently. It cannot look anything up, cannot take an action, and every answer is a liability if a customer relies on it.
This level is fine for low-stakes use: FAQ-style questions on a marketing site, internal brainstorming, drafting. If that is the job, we will tell you so and keep it cheap.
The step that makes AI useful is grounding it in your data. Your documentation, product catalogue, past support tickets, contracts and policies are indexed so that, for every question, the relevant passages are retrieved and the model answers from them, citing where the answer came from. (The technique is called retrieval-augmented generation, but the name matters less than the result.)
The practical differences people notice:
Most “custom AI” projects we build are this level, and it is the one with the clearest return.
The next step is letting the assistant act: look up an order in your CRM, book an appointment, create a ticket, answer the phone and transfer when it should. This is where “assistant” becomes “agent”.
It is also where design discipline matters most. Every action needs a permission model (what can it do alone, what needs a human to approve), logging you can audit, and a fallback when it is unsure. Done carefully, it takes real work off your team. Done carelessly, it sends the wrong email to the wrong customer at scale.
People often assume “our own AI” means training a model from scratch or fine-tuning one on their data. For most businesses that is the last step, not the first. Fine-tuning changes how a model writes — its tone, its format, its handling of a specialised vocabulary. It is poor at teaching the model facts, which go stale. Grounding (Level 2) handles facts; fine-tuning is worth it later, when you have thousands of real examples of the output you want.
One thing we are firm about: your data and your AI’s configuration should live in your cloud account or on your servers, under your control, not inside a vendor’s subscription. If you stop working with us, everything keeps running and you own all of it. That is true of every project we build, AI included.
If you are not sure which bucket you are in, a short call usually settles it.
More from the studio.
Most apps should be built once in Flutter. Some should not. Here is the short checklist we run through with every client before writing a line of code.
Hourly billing moves the risk onto you. A fixed price moves it onto us, which is where it belongs. Here is what goes into ours, what is excluded, and how changes are handled without drama.
An AI that answers your phone is no longer science fiction, but it is not a receptionist either. Here is where voice assistants earn their keep, where they fail, and how we design the hand-off.
A free 30-minute call with a senior engineer. You leave with a plan and a price range, whether or not you hire us.