Decide whether you need a custom application
A custom application makes sense when there is specific work that available tools do not handle adequately for your operation. Before building, describe the problem, who experiences it and how it is handled today. Compare adaptation, integration and maintenance effort with the benefit you want the application to deliver in practice.
Imagine a team distributing requests across spreadsheets and messages. Organising the existing tool more effectively might be enough. Alternatively, an interface bringing rules, availability and follow-up into one journey might be needed. The decision depends on observed work and limitations, rather than simply how easy it has become to generate an initial page.
In the book I wrote in 2022, I described a professional experience involving planning an application for laundries. The analysis helped question the project before moving forward. AI can now accelerate construction, but I still want to understand the need and the business conditions before investing in that execution.
If the problem mainly involves connecting tools, start with business process automation. An application adds an interface, users and maintenance responsibilities. Sometimes that layer has value; in other situations, a well-organised process is enough to improve the work without creating another product that someone has to maintain.
Write the behaviour before asking for code
An application plan should explain who uses it, what information they provide, which decisions the system makes and what result it delivers. Include exceptions and permission differences. AI can work from more concrete instructions when expected behaviour is written down and supported by examples that make the outcome possible to check.
In Sextas Ímpares #145, about building an application with Claude Code, preparation is part of the demonstration. The project involves users, scoring rules, schedules and integrations. These elements show that application development requires decisions beyond the visual appearance of the first screen. The class is available in Portuguese.
For a meeting request, for example, I would write what happens when availability is missing, when the same request arrives twice and when someone tries to view another person’s request. I would add who can change its status and who can only read it. These small decisions significantly change the implementation.
I develop that preparation in the article on planning an application with Claude Code before coding. Here, the focus is the complete journey towards daily use. The initial plan should remain available when changes arise, so the project does not depend on remembering a conversation with the AI tool.
Build a first version that supports learning
The first version should complete a useful journey with the controls required by its intended users. Choose a small objective and verify the sequence from beginning to end. That version lets you observe actual difficulties before adding reports, customisation and features for which you do not yet have enough evidence to set priorities.
In a request-management example, I would start with intake, authorised viewing, assignment and status updates. A dashboard containing dozens of metrics can wait until we understand the decisions the team needs to make. If information arrives incomplete, better charts do not resolve the initial difficulty of handling the request.
Ask AI for bounded changes and review the result after each one. A form change can affect validation, storage and error messages. Seeing the updated screen is only part of the review. Confirm that data reaches its destination correctly and remains accessible only to the people who should be able to see it.
An application may incorporate a model to interpret text, but it can also operate entirely through rules once built. In class #151, about tools for advertising management, that distinction is visible. Keeping it clear helps estimate costs and identify which parts require evaluation of generated responses during operation.
Review access and data before inviting users
Before inviting users, check how the application identifies each person, authorises actions and protects stored data. Test improper access using separate accounts and confirm that secrets never reach the browser. The review should cover the server and database, alongside the buttons and pages visible in the interface users interact with.
If a user changes the address of a request, the application should check authorisation again. Hiding the link does not protect the resource. Downloads and editing operations need the same treatment: each action must establish who is requesting it and what access that person holds for the specific resource.
My rules include explicit database permissions, server-side authorisation, resource-level access checks, protected keys and input validation. I explain them through examples on the page about security for applications developed with AI. These questions should accompany construction from the start, when changing the design is still relatively straightforward.
I also distinguish the development tool’s access from the finished product’s access. The Claude Code security documentation describes permissions and precautions for external content. Those mechanisms help control the tool, but do not replace reviewing the application built with it or checking what its users can do.
Test actual work and prepare publication
Tests should check important journeys, predictable errors and access boundaries before publication. Use representative examples, including incomplete data and repeated actions. Prepare production configuration, backups and a recovery method as well, so the team can respond when a change produces a result different from what was expected during development and review.
Ask someone to complete a task without explaining every click. Where do they hesitate? Do they understand the error when a field is missing? Can they return to their work after closing the page? These observations improve the product and reveal problems that a review by its builder alone may overlook.
Check mobile use, loading states and messages shown when an integration fails. An unresponsive button leaves users unsure whether to try again. If an operation creates a request or sends a message, the application should help distinguish what was completed from what still needs confirmation before another attempt is made.
Document required configuration without putting credentials in code. Before replacing a version already in use, confirm how to return to the previous one and handle any data changes. This preparation is part of the cost of running software in a business, even when writing its code happened quickly.
Treat maintenance as part of the project
An application in use needs error monitoring, dependency review and decisions about new features. Define who receives problems, who can publish changes and how a correction is verified. Maintenance should preserve project knowledge, including the reasons behind the rules that the team relies on when using the application in daily work.
When a change request arrives, return to the objective and existing behaviour. A new permission can make a task easier while exposing information to others. An integration can save copying while creating an external dependency. Discussing these consequences helps decide what should be added and how the change should be checked.
At Laboratório da IA, I review projects in two mentoring sessions per month. AI and business mentoring provides a setting for discussing decisions and difficulties as you develop your work. If the need is to prepare a team, AI training for businesses offers another route, with objectives and format based on the context.
For implementation support from the team, present the problem to SpartAds. Bring the current process, the intended users and what you have already tried. That makes it possible to assess the need for custom software and the work required to keep it useful beyond the first delivery.