TECHPRES.app is a production operating system for companies servicing fire-safety equipment. Softech designed the domain model, web management panel, technician workflow, job scheduling, hydrant and extinguisher registry, measurement handling, asset history and automated PDF protocol generation. The project later evolved from a dedicated implementation into a commercial SaaS product publicly available as TECHPRES.app. The current offer combines software with the optional FH-2 Connect device, which transmits measurement data over GSM/LTE. This case study focuses on system architecture, inspection lifecycle, documentation automation and productization. Earlier percentage-based KPIs are not published without a complete baseline and analytics source.
Business context and the situation before implementation
A fire-safety service company manages customer relationships, multiple sites, potentially thousands of service assets, recurring due dates, technician work, measurements and customer-facing documentation at the same time. The product therefore needs to behave like a vertical operating system rather than a simple asset register.
- Customer → site → sub-location → asset hierarchy.
- Hydrants and extinguishers require different service activities and data.
- Every inspection must preserve asset history and location context.
- Technicians work in the field while coordinators need live control of due dates and job states.
- Final documentation depends on service activities and measurement data.
- Commercialization required turning the implementation into a repeatable SaaS product.
Before state
Before the workflow was centralized, asset data, due dates and documentation could live across spreadsheets, paper forms, individual PDF files and team communication. This made it difficult to maintain one asset history and increased the number of manual steps after field work.
- Fragmented customer, site and asset registry.
- Inspection due dates controlled outside the main workflow.
- Paper or manually re-entered protocols.
- Measurements disconnected from the history of a specific asset.
- No single timeline connecting job, activities, measurement and document.
- Limited ability to productize the workflow for additional service companies.
Goals, success criteria and constraints
Discovery focused on mapping the real service workflow: customer and site hierarchy, asset types, inspection cycles, technician activities, measurements, completeness rules and data required for documentation. A separate concern was separating domain logic from the way a measurement is delivered — manually or by a device.
Product goals
- Create one source of truth for sites, assets and service history.
- Connect job scheduling with field execution.
- Unify manual and electronic measurements in the same model.
- Generate documentation from data already captured in the workflow.
- Keep completeness checks before a job can be closed.
- Prepare the architecture for hardware integration and future commercialization.
- Evolve the solution into the repeatable TECHPRES.app SaaS product.
Success criteria
- An asset has a persistent record with activities, measurements and document history.
- A service order has a clear lifecycle and assigned technician.
- The protocol is generated from a specific inspection rather than a separate manual process.
- The system supports both manual and electronic measurements.
- Due dates and overdue work are visible in one operational panel.
- Measurement integration does not bypass validation or asset linkage.
- The product can be offered commercially as SaaS for teams of different sizes.
Process-sensitive domain
The system supports formal inspection documentation, so data, states and documents must remain linked to a specific asset and service order.
Field work
The technician needs a short, unambiguous workflow that can be completed away from the office.
Different asset types
Hydrants and extinguishers use different activities, parameters and documents while sharing one service model.
Hardware-originated data
Electronic measurements can arrive asynchronously, so the system must know which asset and inspection they belong to.
Derived documents
The PDF is not a separate source of truth; it should be derived from validated domain data.
Productization
The implementation needed to evolve into a model that could be sold as TECHPRES.app without duplicating business logic for every customer.
Analysis and product decisions
- Mapping customers, sites, sub-locations and assets.
- Separating hydrants, extinguishers and their service activities.
- Defining the service-order lifecycle.
- Identifying inputs required by PDF protocols.
- Designing one model for manual and electronic measurements.
- Defining quality gates before inspection completion.
- Separating an integration layer for FH-2 Connect and other devices.
- Preparing the model for commercial SaaS plans and multiple teams.
Solution architecture
TECHPRES.app uses one domain backend as the source of truth for the management panel, technician workflow, assets, service orders, measurements and documents. Hardware integrations are an input layer into the same model, while the protocol generator uses data already validated in the service workflow.
- 01Coordination
Management panel
Customers, sites, assets, jobs, due dates, alerts, technicians and documents in one operational surface.
Next.jsReactTypeScript - 02Field service
Technician workflow
Execution of activities, results and measurements with completeness checks during field work.
Responsive webMobile workflow - 03Domain
Service API
Service-order lifecycle, asset rules, activities, measurements, states and document relationships.
NestJSNode.jsREST API - 04Data
Registry and history
Persistent relationships across customers, locations, assets, inspections, measurements and documents.
PostgreSQLPrisma ORM - 05Documents
Protocol pipeline
Templates, inspection data, validation, PDF generation, archiving and history linkage.
PDF GeneratorS3 / Blob Storage - 06Hardware + cloud
Measurement integration
Optional ingestion of data from FH-2 Connect or other devices over network channels and linking it to the inspection.
GSM/LTEAPITCPWebSocket
Problems, decisions and implemented capabilities
Asset data is scattered across sites and documents.
Build a hierarchical customer → site → sub-location → asset registry.
One asset record connected with inspections, measurements and documents.
Service history remains tied to the correct asset and location.
Inspection due dates can be lost outside the daily workflow.
Connect scheduling with sites, assets and service orders.
Calendar, alerts, states and assigned technicians.
The coordinator can see overdue and active work in one place.
Manual and electronic measurements can create two different workflows.
Unify them in one measurement model.
Manual measurements and device data enter the same inspection record.
Documentation does not depend on how the measurement was delivered.
The protocol requires re-entering data after field work.
Generate the document from domain data captured during the inspection.
Template → data → validation → PDF → archive pipeline.
The same data set feeds both asset history and the customer document.
Measurement-device data can arrive late or without context.
Treat the integration as a controlled input into the inspection domain.
Inspection and asset identification, metadata capture and result validation.
The hardware layer does not bypass lifecycle and documentation rules.
A dedicated implementation does not scale commercially without a product model.
Separate the domain core from plan and integration configuration.
TECHPRES.app as a commercial SaaS with public plans and optional hardware.
The solution can be offered to additional service companies without rebuilding the workflow from scratch.
Technology decisions
| Technology | Role | Rationale | Trade-off |
|---|---|---|---|
| Next.js + React + TypeScript | Management and service interfaces | The component model supports dense operational screens, forms and multi-step workflows. | Complex views require clear state and component responsibility boundaries. |
| NestJS + Node.js | Domain backend and API | Modular architecture maps well to sites, assets, jobs, measurements and documents. | As asset types grow, domain module boundaries must be maintained carefully. |
| PostgreSQL + Prisma | Relational service-history model | Strong relationships are required across customer, location, asset, inspection and document. | Schema changes require controlled migrations and preservation of history. |
| PDF generator | Protocols and documentation | The document can be generated automatically from the same data that drives the workflow. | Templates and data must be versioned to keep documents consistent over time. |
| S3 / Blob Storage | Document and file archive | Files can be stored outside the relational database while keeping domain references. | Access and retention require separate rules from the database record itself. |
| API / TCP / WebSocket | Measurement-device integrations | Different devices and gateways may require different transmission models. | The integration must handle timeouts, duplicates, connection loss and source identification. |
| GSM/LTE + FH-2 Connect | Hardware + cloud layer | The device can transmit measurement data and metadata without manual re-entry. | Field connectivity is not guaranteed, so the system cannot assume immediate data delivery. |
Integrations and data flows
FH-2 Connect
field device → GSM/LTE → TECHPRESTransmit measurement data and metadata into the relevant inspection workflow.
The reading is linked to an asset and inspection and validated before it is used in documentation.
API / TCP / WebSocket
devices or gateways ↔ integration backendSupport different measurement-device communication patterns.
The integration layer must handle duplicates, timeouts and source identification.
File storage
TECHPRES ↔ S3 / Blob StorageArchive protocols and files linked to sites, jobs and assets.
The application stores the reference and controls access independently from the file itself.
TECHPRES.app
product core → commercial SaaS offerMake the solution available to additional fire-safety service companies under a subscription model.
The public product keeps the shared domain core while plan scope and add-ons are a commercial layer.
AI, security and reliability
Roles and access
Access to customer data, jobs and documents should match the user role and company scope.
Lifecycle consistency
A job should not move to completion when required data or measurements are missing.
Integration idempotency
A repeated device reading must not create an uncontrolled duplicate measurement.
Change history
Asset, inspection and documentation keep a connected operational trail so the work can be reconstructed.
Document archive
A generated document remains linked to the data version from which it was produced.
Field-connectivity resilience
The measurement workflow does not assume constant GSM/LTE connectivity and must account for delayed data delivery.
Implementation, testing and release
- 101 — Fire-safety domain discovery
Map the real service process and data required from site to final document.
- Domain and asset relationship map.
- Service-order and inspection lifecycle.
- Protocol data requirements.
Result: The team established a shared product and data-model vocabulary.
- 202 — Operational core
Build the site and asset registry, scheduling and service-order workflow.
- Customer and site hierarchy.
- Asset registry.
- Calendar and technician assignment.
Result: Work coordination and asset history moved into one system.
- 303 — Measurements and documentation
Connect service activities, measurements and protocol generation.
- Manual measurement model.
- Document templates.
- PDF generation and archive pipeline.
Result: The document stopped being a separate post-inspection process.
- 404 — Hardware integration
Ingest measurement-device data without losing inspection context.
- API/TCP/WebSocket integration layer.
- Asset and inspection identification.
- Validation and metadata capture.
Result: Electronic measurement became an alternative data source for the same workflow.
- 505 — TECHPRES.app productization
Turn the implementation into a repeatable SaaS product with a commercial offer.
- Public TECHPRES.app offer.
- Plans for different team sizes.
- FH-2 Connect as an optional hardware product.
Result: The system is now commercially offered as TECHPRES.app.
Service-order lifecycle tests
Check allowed transitions across scheduling, execution, completeness and completion.
Measurement validation
Test manual and electronic measurement data, asset linkage and edge cases.
PDF protocol tests
Check required fields, templates, versioning and document consistency with job data.
Device integration tests
Timeouts, duplicates, retries, connection loss and late measurement delivery.
Role and access tests
Verify data and action scope for coordinators, technicians and other operational roles.
Commercial workflow validation
Verify that the shared product core works independently from plan, module and optional hardware configuration.
What confirms the project description
The historical repository contained percentage-based claims about handling time, paperwork and errors, but did not include a complete baseline, sample definition or source export. P1-F does not publish them as verified KPIs. Verified facts are limited to capabilities supported by the repository and the commercial status of TECHPRES.app confirmed by the live public product.
| Scope | Basis | Reference | Confirmation | Interpretation boundary |
|---|---|---|---|---|
| The system provides one dashboard for jobs, assets, alerts and due dates. | Product screen | TP-01 · dashboard screen in the project repository | Confirmed | Numbers and names visible in the image are demonstrative and are not customer KPIs. |
| The data model represents customers, sites, sub-locations and fire-safety assets. | Product screen | TP-02 · site and asset hierarchy screen | Confirmed | The screen demonstrates the structure, not the scale of a specific deployment. |
| A technician completes an inspection in a structured workflow with activities and measurements. | Product screen | TP-03 · inspection execution screen | Confirmed | The screen confirms the capability but does not measure time savings. |
| The architecture separates user surfaces, domain backend, documents and measurement integrations. | Architecture diagram based on project repository | TP-04 · platform architecture diagram | Confirmed in the product | The diagram is a simplified logical model, not a topology of confidential infrastructure. |
| An inspection has a lifecycle from due date and job to protocol and asset history. | Process model | TP-05 · inspection lifecycle | Confirmed in the product | Individual asset types can add steps and rules. |
| The PDF protocol is generated from asset, activity and measurement data. | Document-pipeline model | TP-06 · protocol generation pipeline | Confirmed in the product | Document templates can vary by protocol type and product configuration. |
| FH-2 Connect is publicly offered as an optional device connecting field measurement with the TECHPRES cloud over GSM/LTE. | Public product offer + integration diagram | TP-07 · FH-2 Connect integration; also confirmed on techpres.app | Confirmed | Measurement values shown on the public TECHPRES site are marked as demo data and are not used in this case study. |
| The project was commercialized as the live TECHPRES.app SaaS product with public plans and modules. | Public commercial product | TP-08 · productization model; public TECHPRES.app offer | Confirmed | Pricing and plan details can change, so the case study describes the commercial model without freezing current price points. |
How to read this information
- Earlier percentage-based efficiency and scale claims are not published as hard outcomes without complete measurement evidence.
- Dashboard visuals contain demo data and are not used as customer-performance evidence.
- The public TECHPRES site explicitly labels example FH-2 Connect readings as demonstration data.
- Commercialization and plan availability are publicly verifiable, while pricing can change.
- Technical scope is described from the repository and live product, not from assumptions about private infrastructure.
Process change, decision consequences and lessons
| Area | Before | After | Business impact |
|---|---|---|---|
| Registry | Fragmented spreadsheets, documents and local asset lists. | Hierarchical customer, site, sub-location and asset registry. | Asset history has one reference point. |
| Scheduling | Due dates and work assignment controlled outside the main asset history. | Calendar, job, technician, status and alerts in the same system. | The coordinator sees active and overdue work together. |
| Field inspection | Activities and results recorded in forms disconnected from the system. | Structured activities and measurements in the service-order record. | Data is ready for downstream workflow without re-entry. |
| Measurements | Manual re-entry of readings from devices or paper. | One model for manual measurements and electronically delivered data. | The measurement source does not change documentation logic. |
| Protocols | Document prepared as a separate step after the visit. | PDF generated from inspection data and archived with the job. | Document and history use the same source data. |
| Product model | Dedicated implementation for a service workflow. | Commercial TECHPRES.app vertical SaaS with plans and optional FH-2 Connect. | The same core can support additional service companies. |
One model for different asset types
- Alternative
- Separate hydrant and extinguisher systems.
- Trade-off
- A shared core requires extensible activity and data types.
- Rationale
- The coordinator needs one customer, site and service-work history.
Measurements as domain data
- Alternative
- Treating the IoT device as an external report.
- Trade-off
- The integration becomes more demanding around identification and idempotency.
- Rationale
- Only then can the measurement safely feed history and the protocol.
PDF as pipeline output
- Alternative
- Manual document creation independent from the workflow.
- Trade-off
- Templates and data need a rigorous structure.
- Rationale
- It removes a second competing data source after the inspection.
TECHPRES.app productization
- Alternative
- Keep the solution as a dedicated implementation only.
- Trade-off
- The product requires configuration, plans and a more reusable permission model.
- Rationale
- A repeatable core makes vertical commercialization possible.
Optional hardware
- Alternative
- Require a measurement device in every deployment.
- Trade-off
- The system must support both manual and electronic modes as first-class paths.
- Rationale
- A company can start with software and add hardware integration when needed.
Key lessons learned
- Vertical SaaS is strongest when the data model comes from the real field workflow rather than a list of screens.
- Hardware measurements should enter the same lifecycle as manual data instead of creating a parallel system.
- Automated documents are trustworthy only when they are generated from controlled source data.
- Asset history becomes the key entity connecting due dates, activities, measurements and documents.
- Productization requires separating the domain core from plans, configuration and commercial add-ons.
- Public commercialization is stronger maturity evidence than an undocumented percentage efficiency claim.
Which organisations this model is relevant for
Fire-safety service companies
Teams servicing hydrants, extinguishers, inspections, protocols and recurring due dates across many sites.
Field service with formal documentation
Industries where field work must end with structured documentation and asset history.
Vertical SaaS with hardware integration
Products combining application, backend, measurement device and cloud.
Companies moving from spreadsheets to an operating system
Organizations that need to connect asset registry, scheduling, technician work and documentation.
Vertical-software productization
Companies with a dedicated implementation that want to turn it into a repeatable SaaS product.
Related expertise and services
Fire Safety & Inspection Software
Custom fire-safety and inspection platforms for assets, technician workflows, measurements, protocols and history.
Web app development
Architecture and development of SaaS operating systems.
Mobile app development
Field workflows and technician applications.
Node.js
Domain backend, API and device integrations.
Next.js
Operator panels and complex web applications.
Fire inspection software guide
Related article about asset registry, protocols and measurement integrations.
Rentya — self-storage vertical SaaS
Another example of a vertical product engineered as SaaS.
Gizo Rental — field operations and rental
Transactional operational workflow connecting mobile, logistics and backend.
TECHPRES.app — commercial product
Public commercial version of the system for fire-safety service companies.
Building a service platform that must connect technicians, assets and documentation?
We can design the domain model, operational panel, field workflow, automated documents and hardware integrations as one production system.
Key confirmed facts
The following statements summarise the confirmed product scope and contain no unapproved growth data.
- 1
Softech designed and developed the fire-safety service system that was later commercialized as TECHPRES.app.
- 2
TECHPRES.app is a production vertical SaaS product for companies servicing fire-safety equipment.
- 3
The system models the customer → site → sub-location → asset hierarchy.
- 4
TECHPRES.app supports hydrants and extinguishers within one operational model.
- 5
Service orders connect scheduling, technician assignment, activities, measurements and documentation.
- 6
Measurements can be entered manually or delivered electronically.
- 7
PDF protocols are generated from data captured during inspection execution.
- 8
Asset history connects inspections, measurements and documents.
- 9
The public TECHPRES.app product has subscription plans for fire-safety service companies.
- 10
FH-2 Connect is an optional measurement device offered with TECHPRES.app.
- 11
FH-2 Connect uses GSM/LTE connectivity to transmit measurement data into the system.
- 12
The public TECHPRES site labels its example measurement values as demonstration data.
- 13
This case study does not publish earlier percentage-based KPIs without complete measurement evidence.
Visual evidence
The diagrams present confirmed product scope and workflows described in this material. They are not mock-ups or claims of undocumented outcomes.
FAQ
Can the system handle both hydrants and extinguishers?
Yes. The system supports different device types, their inspection history, measurement data, and service documentation.
Can technicians work with the system in the field?
Yes. The platform was designed to support field execution of inspections and later expansion into mobile workflows.
Can measurement data be imported from devices?
Yes. The system is prepared for integrations with GSM / IoT measuring devices so that measurement results can be stored automatically.
The same problem in a specific business context
Explore Softech local paths that extend this topic with delivery scope, operating problems and relevant first-party case studies.
Custom business systems for Warsaw companies
Workflows, roles, integrations and one auditable operating model instead of disconnected tools.
Explore contextBusiness systems for Wrocław companies
Field operations, ERP/CRM, assets, documents and operational workflows in one system.
Explore contextProcess automation for Wrocław companies
Automation of the full process lifecycle rather than isolated manual steps and point integrations.
Explore context
