Business applications

Business applications wherever work takes place

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.

01

Websites

Panels of customers, employees, suppliers and partners.

02

Mobile work

Registration of events, photos, statuses and documents in the field.

03

Process layer

Simple interface over FileMaker, ERP or a set of services.

01Applications

Web applications and portals

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.

Event planning screen with reservation list and summary in FileMaker Pro
Sample FileMaker Pro event application. We design the scope of the portal and participants' rights separately.
02Applications

Mobile applications and work at the station

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.

List of scooters and their locations on the map in FileMaker Go on iPad
FileMaker Go example on iPad: list of scooter fleet with locations on map.
03Applications

Desktop applications and existing environments

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.

04Applications

Design, construction and acceptance

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.

We check the task before we expand the system
  1. Scenario

    Who works, on what device and with what data?

  2. Prototype

    Crossing the screen on a real example.

  3. Test

    Correct course, mistake, break and return to work.

  4. Reception

    Agreed result and instructions for the user.

05Offline and synchronization

Offline work and application data synchronization

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.

The user knows the status

Visible information about the last refresh, pending changes and data requiring decisions.

Data has an owner

The change made by the other person does not disappear when syncing. We establish the merger or resolution rule in advance.

06React, PostgreSQL and PWA

Frontend, backend and application database

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.

React and Next.js

Your own interface, forms, filters and roles for clients and your team.

PostgreSQL

A relational database for application data, with transactions and consistency rules.

PWA

Mobile tasks, installation and explicit form submission status.

Claris FileMaker

An operational application environment connected to a portal or other services.

Comparison

Selecting an application for the workplace

Selecting an application for the workplace
VariantWhen it helpsWhat needs to be decided
Web application / portalAccess from a browser for your team or clients.Roles, sessions, devices and weak connection handling.
PWASelected functions of installation and offline work in the web application.Supported browsers, local data and sync.
FileMaker GoA tailored workflow on iPhone and iPad.Mobile systems, access licenses and data exchange methods.
Computer applicationWork at the position and cooperation with its surroundings.Operating system, installation, devices and updates.

Questions and answers

Before making a decision

Can one application support both computer and phone?

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.

Can the application be connected to the current system?

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

Show a task that should be easier.

Specify users, devices and workplace. We will select the access method and prepare the scope of the first working course.

Discuss the application