03 · Case Study
Projipac
Enterprise heat-pump sizing platform that turns technical building inputs into calculation-driven product recommendations and PDF documentation
Heat-pump sizing workflow
Dynamic input forms
PDF documentation
- Role
- Senior Frontend Developer
- Focus
- Business workflows · Forms · Calculations · Architecture
- React
- TypeScript
- Redux Toolkit
- RTK Query
- React Hook Form
- Yup
Projipac is an enterprise heat-pump sizing platform used by installers and sales teams. Users capture technical building inputs, run calculation-driven selection (including deperditions and PAC recommendations), and produce client-ready PDF documentation. Products, parameters, and calculation inputs were maintained through admin tooling, so engineering workflows could evolve without restructuring the frontend.
Context
Installers and sales teams needed a reliable frontend to capture technical inputs, run calculation-driven selection, and produce client-ready documentation. The UI had to feel trustworthy for real project work, not just demo forms.
The engineering challenge
The hard part was modeling a business workflow where related inputs changed validation, available results, and document output. Forms, API state, and calculation results had to stay consistent as product rules evolved.
- Multi-step project flow from building inputs through deperditions, PAC selection, accessories, and synthesis
- Dynamic forms with conditional fields and business validation
- Calculation-driven results that depended on multiple related inputs
- PDF generation as part of the end-user workflow
Decision thinking
I standardized on Redux Toolkit + RTK Query for app/API state and React Hook Form + Yup for complex conditional forms, so new modules could follow shared conventions instead of reinventing fetching and validation per screen. I looked at React Query, but chose RTK Query because Projipac already needed Redux Toolkit for complex workflow state—step navigation, wizard progress, and unsaved changes. React Query would have been strong for server state alone, but keeping the API layer inside Redux Toolkit reduced architectural split across the app: one ecosystem for both server state and UI/workflow state.
- Server state and UI/workflow state needed clearer boundaries
- Forms were too complex for one-off page logic
- Consistency mattered more than short-term speed once modules started multiplying
Hard technical example
The hard part was not one form—it was making dynamic validation reusable across sizing steps. I treated it as a shared form pattern rather than page-local React Hook Form setup.
- useCustomForm wrapped React Hook Form so modules shared the same setup, error handling, and submit path
- Validation was composed with useTranslation and useSalesNetwork, so required fields, labels, and accepted ranges could change by locale and network config
- When calculation inputs or network settings changed mid-flow, the form re-resolved validation without remounting the step or losing user input
- That hook-based pattern kept page components thinner and let new steps reuse the same conditional-validation approach
What I built
I owned the frontend architecture and the core project workflow from technical input to product selection and synthesis.
- Step-based project workflow from technical input to product selection and synthesis
- Dynamic forms with conditional fields and business validation
- Clear separation between server state and workflow/UI state
- Shared form and API patterns reused across modules
- PDF generation as part of the end-user flow
Outcome
The frontend supported calculation-driven selection and document generation without collapsing into one-off screens. As the platform expanded, new modules could reuse the same state, form, and API patterns.
What I’d refine today
I would invest even earlier in shared contracts between backend payloads, Yup schemas, and frontend form models, and document decision rules more explicitly so architectural intent survives team growth.