Custom web applications: client portals, configurators and business tools

• Make a specific task easier for customers or employees.
• Organise data and access according to actual responsibilities.
• Start with a useful version that can be tested and developed further.

Useful software helps someone do something more easily: compare a configuration, submit a complete application, check a status or prepare a job. We start with that task and its exceptions. Who is involved? With what information? Who can change the result? What happens if something is missing or two people act simultaneously?

This approach avoids multiplying screens that reproduce the problems of existing spreadsheets. A dashboard does not help if its data arrives late; a client area simplifies nothing if the team has to upload every file manually again. Information flow matters as much as presentation.

Possible projects include a client portal, request management, a configurator, booking with specific rules or an internal tracking interface. If an existing product already meets the need, configuring or integrating it may be preferable. Custom development should justify its cost through the uses it enables.

The comparison focuses on genuinely essential functions, acceptable limitations and running costs. Custom development provides freedom but also brings maintenance responsibilities. An off-the-shelf tool can launch faster while imposing subscriptions, export constraints or integration limits. We explain these trade-offs before the decision.

On a small screen, scroll the table horizontally.

An initial prototype can be limited to one important function. It allows observation of actual use before funding additional modules. Success criteria and conditions for progressing to the next stage are agreed at the outset.

A React interface can provide an application's screens and interactions. A database, such as PostgreSQL through Supabase, can store records, relationships and statuses. A CMS may remain useful for publishing public pages; a CRM can retain sales tracking. The choice is about organising these responsibilities, not accumulating technology names.

The React documentation also supports adding React progressively to an existing project. We can therefore assess a specific module without rebuilding the whole website. For a complete application, navigation, rendering and hosting choices depend partly on whether there are public pages to be found on Google or screens reserved for logged-in users.

Planning describes the data held in each tool and how it is updated. A contact-detail change must be handled predictably; two tools should not endlessly send conflicting versions back to each other. Export capabilities, documentation and client access are planned to allow another provider to take over later.

Imagine a renovation company exchanging plans, photos and proposals by email. Customers regularly ask which version needs approval. The team spends time searching for documents and explaining the next step. The application's first objective would be to make the project understandable to the customer and easier for the project manager to track.

The initial version includes client access, a list of expected documents, approved documents, project status and a conversation thread. Each client sees only their own project. A project manager can edit assigned projects; a supervisor has a broader view according to the agreed permissions. A notification signals a change without exposing a confidential document in its content.

We test the journey with an incomplete file, a replaced document, a user who loses access and a failed notification. The history should help explain what happened. A CRM connection can later avoid manual record creation, but is added only if it provides enough benefit. This scenario is illustrative and does not represent a client reference.

A hidden button does not protect data. We define read, create, update and delete permissions by role, then verify them on the server or in the database. With Supabase, Row Level Security rules can control access to rows, among other things. Their activation and content must match the project; they are not simply a box to tick.

Acceptance testing uses several accounts to attempt to access another user's records, change a prohibited field or retrieve a private file. Privileged keys are not delivered to the browser. Forms validate incoming data; file handling is controlled by size, format and permissions. Administration access and account recovery form part of the scope to define.

We also specify information retention, backups, restoration and the logs needed for diagnosis. Sensitive data and industry-specific obligations are identified during planning. Security relies on appropriate choices, tests and ongoing oversight, without promising invulnerability.

An application can receive shop orders, create a record from the CRM or send information to an invoicing tool. For each API connection, we specify the trigger, exchanged fields, permissions and failure handling. A request sent several times must not create multiple records or trigger multiple payments.

AI can help classify an enquiry, find information in authorised documents or propose a summary. Its use is evaluated on representative examples, including cases where it is wrong or lacks the information. Important actions remain subject to the planned checks and approvals. A model's response does not automatically become an authorised instruction for your tools.

The quote distinguishes implementation of the integration from usage of the services involved. Limits, response times, subscriptions and data processing conditions are examined before selection. Our AI solutions and CRM and automation pages explain these complementary projects.

Indicators depend on the targeted task. For a portal, we can track the proportion of complete records, clarification requests, time taken for a stage and users who actually complete their journey. For a configurator, we examine usable selections and quotes arising from them. The number of accounts created is insufficient evidence of usefulness.

Before development, we establish a baseline over a representative period. After launch, the same method allows comparison: time spent on a similar record, errors to correct and user feedback. Application events can be matched with operational tracking, limiting collected information to what is necessary.

When estimating return on investment, time saved is valued only if it genuinely frees useful capacity or reduces a cost. The same saving must not be counted twice alongside the assumed revenue it might enable. Implementation, subscriptions, hosting, support and maintenance enter the calculation. The assessment may also show that a function is rarely used and should be simplified before adding others.

An application is priced according to roles, rules, data, integrations and availability requirements. Standard website foundations at €290, €590 or €990 excluding VAT are not application packages. We separate planning, the chosen version and possible future developments, with understandable acceptance criteria. Producing code faster with AI does not remove design work or checks.

Delivery includes the elements specified in the quote: deployed version, agreed access, user documentation, custom code and information needed to operate it. Third-party component licences and subscriptions are identified. The client team must know who manages users, incidents, backups and future updates.

You register, pay for and renew the domain name through your own account. You can manage hosting yourself or entrust it to Gloria under the chosen option; maintenance is defined separately. To discuss your application, describe a specific task, the people involved and your current tools. We can compare custom development with other solutions for your website and business.

For a regulated activity, professional constraints and the countries involved influence the journey, collected information and access. Together, we identify the necessary legal or professional-conduct approvals. Development that meets a technical specification does not replace this validation of professional practice.

Does a web application work on a phone?

It can be designed for mobile browsers, with adapted and tested journeys. A native application distributed through app stores, offline operation or certain phone functions are separate requirements to include in the scope.

Can I keep my current website and CRM?

Often yes, after checking their integration capabilities. The application can complement these tools. We specify where each piece of data is maintained and how changes circulate, to avoid duplicates and conflicting edits.

Does Supabase remove the need to develop security?

No. Available services make certain functions easier, but permissions, database rules, file access and privileged operations still need to be designed and tested. Default settings do not constitute security validation for the project.

Can we start with a small version?

Yes. We select an important task, a few users and success criteria. The first version must allow real, safe use. Secondary functions follow if results and feedback justify the investment.