Build an application: choosing between local and cloud tools

Separate four places: construction, project files, AI processing and the finished application. Compare access, costs and recovery through a practical trial.

You want to create an application: should you build on your computer or in a browser? Where do your AI requests go? Who keeps the files? How will people access the finished application? Choosing between a local and a cloud building tool starts with these answers, which can differ within the same product.

This guide follows a fictional small gallery. Inès prepares exhibitions, Paul welcomes visitors and Salomé works remotely. They want to track borrowed artworks, their location and their return. The people and situations are invented to compare practical choices; they do not represent a Maestro customer or a real customer project.

1. Separate the four places involved in your project

“Local” generally means that some of the work happens on your device. “Cloud” describes resources accessed remotely and operated on other computers. These words do not explain the whole journey of your project. An installed application can contact a remote service; a browser tool can still let you download your files.

• Building: the interface where you describe, change and try the project.
• Files: the code, images, documents and history needed to continue building it.
• AI processing: the place where your requests and any transmitted material are analysed.
• The finished application: what your users open, together with the information they enter there.

Inès could build on her Mac, keep the files in a backed-up folder, use a remote AI service and publish an application that all three colleagues can access. Those four places do not have to match. This is why a phrase such as “everything stays local” needs an explanation of the actual information flows.

Draw four boxes on a sheet of paper. In each, write the location, the account used and the person responsible. An empty box becomes a question to resolve before introducing real data. The drawing will also help you understand what stops working when a device, account or connection becomes unavailable.

2. Choose where you want to build

The building tool is your workshop. You use it to make requests, review proposals and examine changes. Start with how you work: always on the same computer, from several locations or with someone who occasionally helps? The everyday experience matters as much as the advertised feature list.

For Inès, a tool installed on her Mac may work well if she leads the project and wants easy access to her working folder. She still needs to check device compatibility, required software and how another person could take over. Installation itself need not be a problem; an unexplained installation process can be.

A cloud tool may let her open her environment from different compatible devices. She should check what remains available if her account is suspended, the service changes or she decides to work differently. A browser can simplify getting started, but it does not remove decisions about recovering and handing over the project.

During the trial, ask both solutions for the same change: add a “return to confirm” status for an artwork. Look at where the decision is recorded, how you review the result and what it takes to correct a mistake. Compare a complete task, rather than just the speed of the first screen.

3. Find the files you need to keep going

A picture of the result is not the project. Continuing development may require code, images, planning documents and instructions for running it. Information entered into the application is another set of material again. Ask the tool to show you these elements separately, using names you can understand.

Inès creates a trial project called “Gallery test”. She should be able to find the relevant files without guessing which folder contains the latest version. If the tool offers an export, she actually performs it. If the project is already on her computer, she checks the promised contents and asks how to run it elsewhere.

Having the files and being able to resume work easily are different things. Another person may need to install components, configure services or replace access credentials. Ask for an estimate of that work. The guide to ownership of AI-generated application code explores recovery and dependency questions.

Keep a simple comparison record: files recovered, missing elements, available instructions and help needed. A demonstrated handover tells you more than an “export” button whose output nobody has opened. You want to know what you could actually give someone when the person doing the building changes.

4. Understand what the AI provider receives

The location of the interface does not tell you where the AI runs. A request written on your computer may be sent to a remote provider, together with files or excerpts relevant to the response. What is sent depends on the assistant, settings and permitted actions. Ask for an explanation that matches your configuration.

The gallery therefore prepares an entirely fictional list of artworks for its first trial. It includes representative titles, dates and statuses, without contracts or a real lender’s contact details. That is enough to test the task. Copying the full administrative folder would add nothing to this first objective and make it harder to examine the exchanges.

Ask specific questions: what can be sent, to which provider, through which account and under what terms? If an answer remains unknown, keep the trial limited to material prepared for it. A professional subscription and a personal account may have different terms; do not treat them as interchangeable without checking.

5. Decide where the finished application will be used

Once construction is complete, Paul needs to view loans at reception and Salomé needs to prepare an exhibition from home. They do not necessarily need the tool Inès used to build the screens. They need a usable application, appropriate access and consistent information across their devices.

Consider three scenarios: an application used on one computer, an application available on the organisation’s own network, or a service accessible remotely to authorised people. Each requires different preparation. Choose from the places and situations in which people will use it, then have the corresponding technical solution confirmed.

In this fictional example, restricting the finished tool to Inès’s Mac would make Paul’s work difficult when she is away. A remotely accessible application could meet the need if its operation and access arrangements are prepared. It can still be built on the Mac. That does not automatically mean the Mac has to remain switched on.

The CNIL explains that cloud security also involves the customer. Have the provider’s responsibilities and your organisation’s tasks set out in writing.

The expected result is concrete: Paul opens the tool from his usual workstation, Salomé from hers, and both find the same test loan. Passing that check does not validate all security requirements, but it confirms that you are comparing the right way of using the application.

6. Test interruptions to the connection

“Works offline” might mean reading an already open page, creating new records or performing every task. Ask which actions remain possible and how users know a change has been saved. A general promise does not tell you what to expect on a day when the network is unreliable.

Prepare a test with fictional data. Open a record, disconnect, attempt a planned action and reconnect. Note the message shown and check the result from a second device. Do not carry out this experiment during real operations with a record that colleagues are already changing.

For the gallery, the minimum requirement might be viewing the list of artworks on site during a short outage. Recording a return offline and later reconciling it with other people’s changes is an additional requirement. It needs to be described, built and tested separately, including a rule for disagreements.

Also separate the loss of AI access from an outage of the finished application. You may be unable to ask agents for a change while the published application continues to work. Conversely, an essential service used by the application could fail while your building tool remains accessible.

7. Prepare sharing and simultaneous changes

Two people can participate in a project in different ways: discussing requirements, reviewing a screen, changing code or using the finished application. These four activities need different capabilities. Before looking for a “team” plan, name the activity that matters to you and show a real situation.

Inès can gather requests from Paul and Salomé, then pass them to the building tool. This arrangement does not require all three people to instruct the agents simultaneously. A joint session or demonstration environment may be enough to review a task, provided its access arrangements are suitable.

The finished application raises another question: what happens if Paul marks an artwork as returned while Salomé changes its location? Where the application was built does not resolve that conflict. It needs a working rule and tests with several accounts. A shared interface does not guarantee that every change is preserved correctly.

Write down who can build, who can approve and who can use the application. If your main concern is organising shared work, the guide to leading an application project helps assign decisions. Judge a tool’s price or simplicity against the access people actually need.

8. Include setup and maintenance

For a local solution, ask for the first-run requirements: compatible computer, available space, required accounts, requested permissions and someone who can help. Then ask how updates work. A solution that feels pleasant on day one can become frustrating if every change requires an improvised intervention.

For a cloud solution, also examine the remaining work: account setup, access configuration, any domain name, connected services and expense monitoring. An interface ready to open does not mean the finished application is ready for your team. Ask what is included and what will need to be added.

The gallery prepares a small operations notebook. It explains where to open the application, whom to contact during an outage and how to check that service has returned. Inès must not be the only person who knows where it is. A planned absence offers a chance to test the handover without waiting for an emergency.

9. Compare costs for the same scope

Separate the cost of building from the cost of everyday use. The first may include the tool, AI usage and assistance. The second may include hosting, connected services, maintenance and user accounts. Some subscriptions combine several items; ask which ones before concluding that a particular plan is cheaper.

• Getting started: requirements, setup, tests and any transfer of existing data.
• During construction: the tool, AI usage, assistance and time spent checking results.
• In service: any hosting, backups, necessary services and maintenance.
• When leaving: recovery of materials, transfer and getting the application running elsewhere.

Make two calculations using the actual quoted prices: one for your current team and one for changes you realistically expect. For the gallery, that might mean adding another exhibition space. Do not invent hundreds of future users just to make one option look better on paper.

Also ask how variable spending can be stopped. Who receives the alert? Who can pause AI requests or disable a service that is no longer needed? The application budget guide helps bring these items together. No universal price settles the local-versus-cloud decision without this scope.

10. Practise recovery before you need it

Choose a plausible reason to move: replacing a computer, changing the project lead or leaving a provider. Prepare the handover while everything works. Your contact can then demonstrate the steps calmly and explain which parts require their involvement.

For a locally built project, try a copy prepared for recovery without touching the original. For a cloud project, retrieve the permitted materials and inspect what you can run from them. In either case, ask specifically about the finished application’s data: its backup may be separate from the code backup.

Inès chooses three fictional records and an image, then asks to find them again after a recovery trial. Paul checks their contents, not just the file count. If information is missing, they record what it is and how to retrieve it. A promise of portability becomes an observable result.

11. Use a simple decision checklist

For each solution, write an answer and supporting evidence alongside the questions below. “To be confirmed” is a valid answer during comparison. Keep it visible in the final decision, with a person responsible and a check date. Avoid an overall score that hides an essential requirement among pleasant extras.

• Building: which devices can you work from, and what help is available?
• Project: which files do you recover, and who can demonstrate resuming work from them?
• AI: what material is sent elsewhere, and under which terms?
• Use: where does the finished application run, and who arranges access?
• Continuity: what remains possible without a connection or when a provider is unavailable?
• Costs: which items are fixed, variable, charged initially or associated with leaving?

The gallery starts with its requirements: three people need to view loans, one leads construction and the project must be transferable. A solution that meets these conditions deserves a trial. One that cannot explain project recovery remains on hold, even if its first screen is more impressive.

You may choose a combination: local construction, remote AI and a hosted application. You may choose a different arrangement. What matters is understanding, testing and assigning responsibility for the consequences, with limitations your organisation can accept.

12. Run a small trial before choosing

Take one situation: record a fictional loan, change its location and prepare its return. Add the checks that mattered in your comparison: access on the right devices, connection interruption, file recovery and handover to another person. Use the same scenario for each solution you compare.

Record what you observed and what was only claimed. A provider demonstration, your own test and a capability promised for later are different kinds of evidence. You can return to this record before signing, starting work or asking for support.

Maestro is one option for building on a Mac: the project and history are kept on your machine, with possible exchanges with the configured AI provider. Hosting and shared use of the finished application need separate preparation. Choosing Maestro does not, by itself, prove that your future tool will work without the internet.

As of 23 September 2026, Maestro is in an invitation-only beta for macOS 13 and later. The application is free during the beta, with AI usage charged separately; Windows is in development. Prepare your scenario with the application brief template, then compare what you will actually need to build and use.

Back to contents