Territorial Survey System

Context and problem

The system was intended for a territorial survey carried out in the field using tablets. It could not be designed as a desktop web application with a permanent connection. Connectivity could be interrupted or degraded during the operation, and users needed to retain their work.

The frontend had to be available in less than a month and ready for a specific operation. Technical decisions had to prioritize operational reliability, clear interaction, and delivery over unnecessary complexity.

The application integrated with an API developed in parallel with the frontend. It had to support progress during the survey by keeping drafts and persisting information progressively as conditions allowed.

Data capture experience and workflow

The frontend was organized around the actual survey workflow and tablet-based data capture. Clear interaction needed to support fieldwork without depending on ideal network conditions.

Analysis, schema, and architecture decisions were shared. My individual contribution was to bring that work into the interface and implement the frontend behavior required for the planned activity.

With less than a month available, I kept the scope focused: the goal was to clearly implement the path needed for the operation, rather than build generic frontend infrastructure.

My responsibility and constraints

I individually implemented the frontend in React and TypeScript, its integration with the API, and the draft and progressive persistence behavior needed for tablet use.

Another development team member implemented the backend in parallel with the frontend. Backend implementation and Android components were outside my individual responsibility.

The main constraints were the delivery deadline, the target device, and the possibility of limited connectivity during an activity that could not depend on a permanent connection.

Drafts and progressive persistence

A central decision was to avoid treating every interaction as an operation that had to complete immediately against the server. Work state could be retained through drafts and persisted progressively as conditions allowed.

This reduced dependence on a stable connection throughout the process and the risk of losing information already entered. The interface had to remain useful as connectivity varied.

This scope does not imply an offline-first architecture or a synchronization guarantee under every interruption. The decision addressed the specific survey conditions and integration with the API developed in parallel.

Public demo and limits

The sanitized public territorial survey demo lets visitors explore part of the frontend behavior with synthetic data, without exposing institutional information or private dependencies.

It is a reduced version of the original frontend: workflow branches, logic, data, and details of the real professional context were omitted or replaced. The demo is not equivalent to the complete system and cannot, on its own, verify the original operation or its real API integration.

Its purpose is to provide public evidence of part of the interface and data capture path. Evidence of field use belongs to the professional activity, rather than this demonstration.

Validation and outcome

The main validation was not only technical. The system was used in the real activity for which it had been developed, during a session lasting approximately six hours, on the intended devices and under the operational conditions for which it had been designed.

The activity was completed, and the data produced during the survey were subsequently delivered. That use validated that the workflow was usable on tablets and that the draft and persistence decisions were compatible with the field setting.

The six hours describe the activity's duration, not an SLA or a performance measurement. I do not attribute broader organizational impact to the system beyond that specific outcome: the frontend was delivered within the required timeframe and used to complete the planned operation.

What it demonstrates

• Turning real operational constraints, such as tablet use, fieldwork, and limited connectivity, into concrete frontend decisions.
• Implementing a React and TypeScript interface and integrating it with an API developed in parallel.
• Implementing drafts and progressive persistence to reduce dependence on a stable connection.
• Keeping scope focused and delivering, in less than a month, a frontend used in a real activity, rather than only a demonstration.

Technology and evidence

• React
• TypeScript

Primary technology: React · TypeScript · Vite · REST integration · Git · CI/build · GitHub Pages for the sanitized demo.

The project used an automated build process through CI. Public evidence includes the sanitized demo, two sanitized screenshots, and the derived conceptual diagram of progressive work preservation; private operational evidence belongs to the professional context and is not published in this case.

Privacy note

SANITIZED CASE STUDY

The original system belongs to a professional context. Names, data, endpoints, screenshots, and other internal details were omitted or replaced to avoid exposing institutional information.