Building business software with AI: pitfalls and practical checks

From the first demo to everyday work: twelve checkpoints, a fictional workshop and examples for checking calculations, data, access, costs and recovery.

A customer record opens and a quote takes shape: the business application you are building with AI is becoming real. What matters on Monday morning is less visible: the right amount, the right recipient, information that stays saved and a way to keep working after a failure.

This guide follows a fictional workshop run by Camille, a small business replacing its quote-tracking spreadsheet. Camille prepares offers; Sam organises the work. They want to find customers, track responses and stop copying the same information. They are not Maestro customers, and this is not a project we have tested.

Each pitfall leads to a practical check. You can ask these questions without knowing how to program. Some answers require a technical professional, especially before using real customer data or opening the application to several people.

1. Building from a request that leaves too much open

“I want to manage my quotes” leaves many decisions unresolved. Do you need to find a document, calculate its amount, send it or track acceptance? AI can suggest something that looks coherent but does not match your way of working. The first warning sign is simple: everyone describes the application's job differently.

Camille makes the need specific: at the end of the day, she wants to see offers sent more than a week ago and decide which ones to follow up. This first version does not need to create invoices or take payments. That boundary keeps the first version focused on one complete function.

Write down the current process using an invented example: a customer requests work, Camille prepares an offer, the customer replies and Sam receives the planned date. Note where information arrives, who changes it and what proves that a step is complete. Include an exception, such as a cancelled offer.

Ask the person who will perform the task to read this text. If Sam understands something different, correct the document before the screen. The non-technical requirements guide helps collect these rules without turning your project into endless paperwork.

2. Mistaking a demonstration for a ready application

A demonstration shows a selected journey. It may use pre-filled examples, simulate sending or retain information only during the visit. That is not necessarily a problem: it helps people discuss an idea. The difficulty starts when you rely on it for work without knowing what actually functions.

Camille creates an offer and sees a confirmation. She closes the application, opens it again and looks for the document. This short journey reveals something that the attractive screen could not: is the entry still there? She also compares the saved offer with the information she entered.

Try the complete journey

• Create a fictional customer and an offer belonging to that customer.
• Close and reopen the application, then find both records.
• Change a detail, save it and check the generated document.
• Cancel an offer and observe the lists in which it appears.

Ask the person building the tool to distinguish what is operational, simulated and still missing. Keep that answer with the project. A “sent” message should correspond to a result you can observe using a test address you control. Otherwise, sending remains unverified and should not be used for a real follow-up.

3. Believing a reported result without examining the evidence

AI can announce that everything works after checking only part of a journey. An automated test can also repeat the same incorrect rule as the program. If both discount delivery when you meant to exclude it, a green indicator does not answer your need.

In our fictional example, the work costs €200, delivery costs €30 and a 10% discount applies only to the work. The expected amount before tax is therefore €210: €180 for the work and €30 for delivery. This is an arithmetic example, not a tax or accounting template for quotes.

Write that result down before requesting the change. Then compare the amount on screen, the saved amount and the customer document. Add an offer without a discount and another without delivery. You are now comparing several situations against a known result.

Ask which checks have not been performed too. A written limitation helps you decide; vague certainty does not. The guide to writing tests before code explains how to keep these examples for future changes.

4. Confusing signing in with protecting records

A sign-in screen does not explain who can read or change what. In the workshop, Sam needs the schedule and contact details relevant to the work. Camille may want certain commercial information reserved for a different role. Describe this division before simply asking for “user accounts”.

Prepare fictional accounts and records in an authorised test environment. For each role, write down the visible information and permitted actions. Ask the technical professional to verify that list, including situations in which an action should be refused. Do not run these checks on real customer accounts.

OWASP recommends limiting permissions to what is needed and checking each request where the data is protected. Hiding a button does not replace that check.

Camille now has a specific question: “Using a test account for field work, can we see the permitted appointments without accessing restricted commercial information? Can you document the check?” Without an answer, postpone adding real records.

Plan for someone leaving as well: who removes access, and who checks it? Identify the owner of the administration account. If everything depends on an address belonging to an unavailable contractor, you have found a dependency to resolve before launch.

5. Assuming “local” means “no data leaves”

Where a project is kept, where AI processes a request and where the finished application stores its data are three different questions. A tool installed on your computer can contact an AI provider. The application it helps build may also use remote services.

Camille does not need to send her real customer list to explain the shape of a quote. She prepares invented names, addresses and amounts. She retains everyday difficulties, though: two people with the same name, an empty field and a cancelled offer. The test data remains useful without reproducing her records.

The CNIL advises choosing AI according to its use and the data transmitted. Before sending real information, have a qualified person review the provider's terms and the rules relevant to your activity.

Ask for a readable explanation: which files can the assistant read, what may be transmitted, to which provider and under which settings? A screenshot sent to request help may already contain a name or address. Check what you attach to a conversation too.

Do not paste a password or access key into your requirements document. Ask the technical professional to arrange how these are stored and replaced. If a secret has been shared by mistake, have the key revoked and replaced or the affected password changed. Deleting the message alone does not remove access already obtained.

6. Adding a feature without checking the existing ones again

One change can affect several places: data entry, calculations, documents and tracking lists. A familiar symptom is a feature that finally works alongside another that no longer does. You discover it late if nobody repeats the usual journey after the change.

Camille requests a discount on the work. She also specifies that delivery charges stay unchanged, an offer without a discount keeps its total and the acceptance status remains the same. These points describe what must remain true around the new feature instead of leaving the assistant to guess.

A short change record

• Requested change: a discount on the work.
• Rules preserved: delivery, previous amounts and statuses.
• Examples to repeat: standard offer, discounted offer and cancelled offer.
• Decision: accept the version or request a specific correction.

Before the work starts, ask for a retrievable state of the project. Afterwards, perform the checks on a working copy. The guide to fixes that break something else explains this habit. If going back affects data entered since the change, ask how it will be handled: restoring an older code version does not automatically recover the work done in between.

7. Budgeting for creation and forgetting daily operation

The subscription does not necessarily represent the complete cost. The workshop may need to pay for AI, hosting, messages or maintenance work. The time Camille spends checking rules and correcting data is part of the real effort too.

Separate building costs from the expenses needed to keep working. An application may cost little during a demonstration, then more as users, documents or requests to a service increase. Avoid extrapolating a short trial's cost to an entire year without stating the assumptions.

• Building: scoping, AI trials, revisions, checks and technical help.
• Running: services used, storage, backups and support.
• Changing: new requests, adaptation to external services and checks after changes.

Camille sets a decision point before each new batch of work. She records the expense observed during the trial, what was achieved and what still needs paying for. A written budget limit helps her choose whether to continue, reduce the request or seek advice; it does not create a technical spending cap at the provider.

Check alerts, genuinely enforced limits and the selected service's billing terms separately. The application budget guide helps prepare that discussion.

8. Having the files without knowing what can be taken over

Code ownership, rights to the elements used and the ability to start the application again deserve separate answers. Possessing a folder of files does not, by itself, tell you which accounts are required or what conditions accompany a library, image or service.

Ask for an inventory of the project: code, documents, added components, services and required access. For each third-party element, keep its origin and available licence information. Have uncertain terms examined by a qualified person before commercial use; this guide does not determine the rights attached to your project.

Camille then asks for a practical handover: “If someone else takes over the tool, what must I give them so they can start it with test data?” The expected answer describes files and steps. “Everything belongs to you” does not replace that practical preparation.

The code ownership and handover guide explores this distinction. Keep important accounts under the business's control and document who can administer them. The aim is to make a handover possible without depending on memories of a long conversation with an assistant or contractor.

9. Discovering too late that no exit was prepared

An export and a backup serve different needs. An export helps you read or move information. A backup should allow you to recover a usable state with the necessary elements. A downloaded file may be missing attachments, relationships between records or settings.

In Camille's example, we prepare three fictional customers, their offers and a few attached documents. The technical professional creates an export, then explains how each offer remains linked to its customer. A list of names alone is insufficient if amounts and acceptance history disappear along the way.

ANSSI recommends preparing restoration and practising it regularly. It also highlights including what is needed to reinstall and configure applications. The presence of a backup therefore does not, by itself, prove a successful recovery.

Ask for a trial separate from the everyday tool: get a copy running again, find the expected records and note what is missing. Camille checks the business content; a technical professional organises the operation without overwriting working data. Keep the result and the steps in writing.

Finally, define the acceptable amount of lost work and interruption time for your business. Losing a day's entries may be manageable in a trial and far less acceptable after launch. If replacing an existing tool, prepare the transfer of Excel data before removing access to the old one.

10. Promising teamwork without arranging how information is shared

An application running on one computer does not show how two people will work together. They may use different copies, overwrite a change or see different statuses. With the help of the person designing the tool, decide where shared information lives and how each person accesses it.

Camille and Sam open a fictional offer. Camille changes the planned date while Sam updates the contact. Which information should be kept? How do they know that someone else has changed the record? The phrase “collaborative application” does not answer those questions.

Also ask what happens without a connection and when the network returns, if that use is planned. Data entry may have to wait until reconnection. Users need to understand that choice, and it must fit their actual work.

A local application does not remove these decisions, and it does not establish that Maestro provides server-free collaboration between users. Always distinguish the capabilities of the building tool from those of your future application. Have sharing, accounts and simultaneous changes documented before choosing the solution.

11. Launching without anyone responsible for what follows

The first day of use brings new questions: who receives errors, who decides whether a problem blocks work and who can fix the application? Without an available person responsible, an ordinary difficulty can bring the workshop to a standstill.

Start with a scope you can observe. Camille tries quote follow-ups using fictional data, then organises limited use once the appropriate checks have been completed. At every stage, clearly identify the reference tool so that two conflicting lists are not used at the same time.

Prepare understandable fallback instructions: whom to tell about an error, what to record without exposing confidential data and how to continue authorised work. Plan component updates with the technical professional as well. A finished application is not necessarily something you can forget about for years.

Sensitive processing, payments and regulated activities need support appropriate to their stakes. Choosing a small first version helps you learn; it does not automatically reduce the consequences of an error involving the data it handles.

12. Keep a decision sheet before moving on

For your own project, copy the following lines and complete them with someone who understands the work. Replace “it's fine” with an observable result, a date or an unknown that needs resolving.

• Priority use: which action should become simpler, and for whom?
• Essential rule: which result did we calculate or define beforehand?
• Evidence: which complete journey have we actually tried?
• Data and access: what did we verify, and who is dealing with the unknowns?
• Spending: which amount or event triggers a new decision?
• Recovery: when was a copy restored, and with what result?
• Next steps: who receives incidents and who authorises going live?

In the fictional workshop, a successful screen is enough to continue discussing the need. It is not enough to send real offers. Each piece of evidence adds a specific reason to proceed; each important unknown identifies work still to complete. You can ask an assistant or a contractor to report progress this way.

Maestro brings together project scoping, building and approvals. Its Mac beta is available by invitation: the application is free, with AI usage charged separately. See the Maestro introduction for current conditions. This framework helps organise discussions; deciding to use your software depends on checks appropriate to your activity.

Back to contents