Websites
Panels of customers, employees, suppliers and partners.
Business applications
An application should make a specific task easier: collect data, guide a user through a decision and securely pass the result to the right system.
Panels of customers, employees, suppliers and partners.
Registration of events, photos, statuses and documents in the field.
Simple interface over FileMaker, ERP or a set of services.
The browser-based interface can serve customers, employees, or partners. The user sees the necessary tasks and data, and the operations are transferred to a common process. The scope may include submissions, orders, files, approvals or reports.
A web application requires responsibility for the server, sessions, permissions and data access. Not every feature has to be on the public part of the company website.

A telephone, tablet or terminal is useful wherever information is created: upon receipt, in the warehouse, service center or on the production floor. We start the project with activities and working conditions - network coverage, use of a camera, scanner or operation with gloves.
We can choose Go, WebDirect or a separate web interface to suit the needs of the solution. Native requirements, distribution to devices, and offline work require separate assessment. We do not assume identical capabilities of all platforms.

Sometimes you need access to local files, devices or specific workstation functions. Then we check whether the task can be performed by an existing client or whether it requires an additional module.
When taking over an older application, we inventory dependencies and data. We check compatibility with the current environment, installation and updating methods, and the possibility of gradually replacing elements.
We describe roles and the most important scenarios, prepare screens, build logic and integrations. We then test permissions, correct and incorrect data, and behavior after loss of connectivity.
The implementation includes an agreed method of access, preparation of users and a plan for subsequent updates. The important result is a working process, not just a set of views.
Application handover may include hands-on training of users and administrators on their tasks. We are planning a pilot program for many branches, a sequence of launches and common rules for reporting problems. We determine the scope of independent changes to dictionaries, forms and rules before implementation.
Who works, on what device and with what data?
Crossing the screen on a real example.
Correct course, mistake, break and return to work.
Agreed result and instructions for the user.
First, we determine what the user must do without access to the server: read the instructions, save the form or change common data. The interface distinguishes between a local save and a confirmed send.
The return of connection requires the recognition of repetition and the principles of conflict resolution. Installing the application itself does not ensure offline operation. We also assess the scope of data on the device, logging out, loss of access and method of updating.
Visible information about the last refresh, pending changes and data requiring decisions.
The change made by the other person does not disappear when syncing. We establish the merger or resolution rule in advance.
We use React and Next.js to build portals and applications with extensive interaction. TypeScript helps maintain code consistency, and the server layer checks data and permissions. PostgreSQL can handle transactions, operation history, and reports.
The application can be extended with PWA features: installation on a device, selected data available offline and controlled synchronisation. If FileMaker serves as the company's backend, we connect the new interface to it through an API, keeping responsibility for the data in the agreed system.
React, Vue or Angular can work with a Laravel, ASP.NET Core, Django or Node.js backend. We do not bind screen selection to a single server language. The architecture should facilitate the development of business rules and integrations.
Your own interface, forms, filters and roles for clients and your team.
A relational database for application data, with transactions and consistency rules.
Mobile tasks, installation and explicit form submission status.
An operational application environment connected to a portal or other services.
Comparison
| Variant | When it helps | What needs to be decided |
|---|---|---|
| Web application / portal | Access from a browser for your team or clients. | Roles, sessions, devices and weak connection handling. |
| PWA | Selected functions of installation and offline work in the web application. | Supported browsers, local data and sync. |
| FileMaker Go | A tailored workflow on iPhone and iPad. | Mobile systems, access licenses and data exchange methods. |
| Computer application | Work at the position and cooperation with its surroundings. | Operating system, installation, devices and updates. |
Questions and answers
Yes, but tasks and the amount of information on screen may vary. We design a common process and matched views, and we check the capabilities of the devices separately.
First, we check the shared interfaces, permissions and data quality. Often, a new application can be a convenient layer of work on an existing system.
Let’s start with a conversation
Specify users, devices and workplace. We will select the access method and prepare the scope of the first working course.
Discuss the application