# PIAR Concept — reading guide

Last editorial review: 2026-10-28. This is a public first-party overview, not a live status feed.
Read the linked service and project pages for scope and attribution. The FAQ answers below are also available as server-rendered HTML in Catalan, Spanish and English.

> PIAR Concept is a Barcelona software engineering studio focused on software architecture, custom platforms, systems integration and automation. We work in Catalan, Spanish and English with teams in different locations.

We help founders build SaaS products, connect public websites to backoffice workflows, integrate APIs and create internal software. Scope, cost and delivery plans depend on discovery and are agreed for each project. Design, websites and SEO support the wider product.

## Where to find information
- [Questions and answers](https://www.piarconcept.com/en/faqs): 20 published answers, with a dedicated canonical page for each question.
- [Reading guide](https://www.piarconcept.com/llm.md): This document, served as Markdown. /llms.txt provides the same content as plain text.
There is currently no separate news feed on the public site. For current published work, use Projects; for availability or an up-to-date project status, use Contact. Do not infer completion dates, staffing, prices or performance results that are not published.

## Website
- [Home](https://www.piarconcept.com/en): An introduction to the studio and selected work.
- [Services](https://www.piarconcept.com/en/services): Software architecture, custom software, APIs, integrations and workflow automation.
- [Method](https://www.piarconcept.com/en/methods): How we approach business requirements, architecture, implementation, testing and delivery.
- [Projects](https://www.piarconcept.com/en/projects): Selected projects and the specific contributions made by the studio.
- [Contact](https://www.piarconcept.com/en/contact): Discuss a project with our team.

## Commercial services
- [A website with a backoffice built around your business.](https://www.piarconcept.com/en/solutions/websites-with-backoffice): We design and build custom websites connected to an administration panel. Your team can manage content, users and processes from a shared foundation, with clear permissions and a public website people can discover.
- [Custom SaaS development to turn your idea into a product.](https://www.piarconcept.com/en/solutions/saas-development): We help you define and build a custom SaaS product: the problem it solves, its first useful version and the architecture connecting users, data and business rules. We also work on existing products that need to evolve.
- [Systems integration that connects your business data.](https://www.piarconcept.com/en/solutions/systems-integration): We connect applications, CRM, ERP and platforms through APIs and webhooks. We design how information moves, which system owns each record and how to recover an operation when something fails.
- [Custom internal tools for the way your business works.](https://www.piarconcept.com/en/solutions/internal-tools): We build internal software to organise data, tasks, permissions and approvals. A shared interface helps your team follow each process and see what needs attention.
- [Software architecture to move your existing platform forward.](https://www.piarconcept.com/en/solutions/software-architecture): We review existing platforms to understand what makes them difficult to change and what should be addressed first. We map data, modules, permissions and integrations, then propose a technical plan your team can implement in stages.

## Experience and scope
The project portfolio distinguishes contributions from ownership of a complete client product. Examples include ecommerce/backend contributions and Salesforce/SAP integrations for ISDIN; features, integrations and landing pages for Amphora Logistics; and internal logistics software for FARAFE. Catalònia OS is in development. ICATME work is ongoing TechMed research and development; it is not a claim of a validated medical product.

## Localized service pages
- [Un web amb backoffice per fer créixer el teu negoci. (ca)](https://www.piarconcept.com/ca/solutions/websites-with-backoffice)
- [Desenvolupament SaaS per convertir la teva idea en un producte. (ca)](https://www.piarconcept.com/ca/solutions/saas-development)
- [Integració de sistemes perquè les teves dades treballin juntes. (ca)](https://www.piarconcept.com/ca/solutions/systems-integration)
- [Software de gestió interna per a la teva manera de treballar. (ca)](https://www.piarconcept.com/ca/solutions/internal-tools)
- [Arquitectura de software per tornar a avançar amb la teva plataforma. (ca)](https://www.piarconcept.com/ca/solutions/software-architecture)
- [Una web con backoffice para hacer crecer tu negocio. (es)](https://www.piarconcept.com/es/solutions/websites-with-backoffice)
- [Desarrollo SaaS para convertir tu idea en un producto. (es)](https://www.piarconcept.com/es/solutions/saas-development)
- [Integración de sistemas para que tus datos trabajen juntos. (es)](https://www.piarconcept.com/es/solutions/systems-integration)
- [Software de gestión interna para tu forma de trabajar. (es)](https://www.piarconcept.com/es/solutions/internal-tools)
- [Arquitectura de software para volver a avanzar con tu plataforma. (es)](https://www.piarconcept.com/es/solutions/software-architecture)

## Languages
- [Català](https://www.piarconcept.com/ca)
- [Español](https://www.piarconcept.com/es)
- [English](https://www.piarconcept.com/en)

## Contact and discovery
Email enquiries: use the email button on https://www.piarconcept.com/en/contact.
Phone: +34 628 009 793
- [XML sitemap](https://www.piarconcept.com/sitemap.xml): Canonical public URLs and reciprocal language alternatives.

## Frequently asked questions — published answers

### CA

#### Què fa Piar Concept?
Source: https://www.piarconcept.com/ca/faqs/what-does-piar-concept-do
Reviewed: 2026-10-28

Dissenyem arquitectura de software, desenvolupem plataformes a mida i connectem sistemes per resoldre necessitats operatives de les empreses. Les webs i el disseny formen part del servei quan el producte ho necessita.

El punt de partida és el procés de negoci: quines persones hi intervenen, quines dades utilitzen i on apareixen errors, tasques manuals o límits de creixement. A partir d’aquí definim la solució, les integracions i una primera entrega amb un abast concret.

Podem intervenir en un producte nou o aportar capacitat tècnica a un d’existent. Per valorar l’encaix necessitem conèixer el problema, els sistemes actuals i l’objectiu; no cal arribar amb una especificació tècnica tancada.


#### Quan convé desenvolupar software a mida?
Source: https://www.piarconcept.com/ca/faqs/custom-software-or-existing-tool
Reviewed: 2026-10-28

Té sentit quan els processos, les integracions o les regles del negoci no encaixen bé en una eina estàndard. Abans de desenvolupar, convé comparar adaptar una solució existent, integrar-la o construir només la part diferencial.

La comparació ha d’incloure llicències, migració de dades, manteniment, dependència del proveïdor i l’esforç real de les persones que faran servir l’eina. Tenir moltes funcions no és suficient si l’equip continua treballant amb fulls de càlcul i passos manuals al voltant del sistema.

Una primera anàlisi permet separar requisits imprescindibles de preferències i comprovar què es pot resoldre sense crear un producte complet. La decisió depèn del context i del cost total, no d’una preferència per programar-ho tot des de zero.


#### Què aporta l’arquitectura de software a una empresa?
Source: https://www.piarconcept.com/ca/faqs/software-architecture
Reviewed: 2026-10-28

L’arquitectura defineix com s’organitzen els components, les dades i les integracions d’un sistema. Serveix per prendre decisions tècniques coherents amb l’operativa, l’evolució prevista i les restriccions del negoci.

En un projecte es poden revisar responsabilitats de cada component, contractes d’API, permisos, desplegaments i gestió d’errors. És important identificar qui és responsable de cada dada i què passa quan un servei extern falla o canvia.

La solució adequada no sempre és la més complexa. Una aplicació modular pot ser suficient; separar serveis només compensa quan hi ha motius clars. L’abast dels diagrames, les decisions documentades i la implementació s’acorda per a cada projecte.


#### Podeu integrar un ERP, un CRM i altres API?
Source: https://www.piarconcept.com/ca/faqs/erp-crm-api-integrations
Reviewed: 2026-10-28

Sí. Les integracions entre sistemes formen part del treball de Piar Concept. La viabilitat depèn de les API disponibles, els permisos, les llicències i la qualitat de les dades de cada sistema.

Primer es defineix quina informació s’intercanvia, en quina direcció i amb quina freqüència. Després es revisen autenticació, límits d’ús, correspondència de camps, duplicats i recuperació de fallades. Una integració també ha de preveure com es detecta i es corregeix una sincronització incompleta.

La nostra experiència publicada inclou contribucions a integracions amb Salesforce i SAP a ISDIN i integracions per a Amphora Logistics. Aquests exemples no impliquen que qualsevol connector estigui llest per fer servir: cada entorn requereix la seva avaluació.


#### Quins processos interns es poden automatitzar?
Source: https://www.piarconcept.com/ca/faqs/internal-tools-and-automation
Reviewed: 2026-10-28

Els millors candidats solen ser tasques repetitives amb regles clares i dades accessibles: traslladar informació entre sistemes, coordinar estats, generar documents o preparar informació operativa.

Abans d’automatitzar es descriu el flux actual, incloses les excepcions i les decisions que requereixen revisió humana. S’estableix una referència mesurable, com el temps dedicat o els errors observats, per poder avaluar el resultat sense prometre un estalvi per endavant.

Piar Concept ha fet software intern de logística i optimització de processos per a FARAFE. En un projecte nou, una primera automatització acotada permet comprovar accessos, regles i utilitat abans d’ampliar l’abast.


#### Podeu treballar sobre software que ja existeix?
Source: https://www.piarconcept.com/ca/faqs/existing-software
Reviewed: 2026-10-28

Sí. Podem aportar funcionalitats, integracions i millores a productes existents. Abans de comprometre’ns amb l’abast cal revisar el codi, l’arquitectura, els entorns i la documentació disponible.

La revisió ajuda a identificar dependències, proves, restriccions de desplegament i coneixement que només té l’equip actual. Amb aquesta informació es pot decidir si convé ampliar el sistema, refactoritzar una part o substituir un component de manera gradual.

No plantegem una reescriptura completa com a requisit d’entrada. Els canvis han de tenir una manera de validar-se i un pla d’entrega compatible amb la continuïtat del negoci. L’accés a repositoris i entorns es coordina amb el responsable del projecte.


#### Com abordeu la intel·ligència artificial aplicada?
Source: https://www.piarconcept.com/ca/faqs/applied-ai
Reviewed: 2026-10-28

Partim d’una tasca concreta i comprovem si la IA aporta valor davant d’una solució basada en regles. La qualitat de les dades, la privacitat i la manera d’avaluar els resultats condicionen la viabilitat.

Un pilot ha de tenir exemples representatius, criteris d’acceptació i revisió humana quan el risc ho requereix. També cal considerar errors, costos d’ús, accés a informació sensible i què fer quan el sistema no disposa d’una resposta fiable.

El treball amb ICATME es presenta com a R+D TechMed en curs. No el descrivim com un producte mèdic validat ni com una garantia de capacitat diagnòstica. Qualsevol aplicació sanitària exigeix la seva pròpia avaluació professional i reguladora.


#### Col·laboreu amb estudis d’UX, disseny i consultores?
Source: https://www.piarconcept.com/ca/faqs/ux-and-consultancy-partners
Reviewed: 2026-10-28

Sí. Piar Concept pot aportar arquitectura i implementació tècnica a projectes liderats per estudis d’UX, disseny o consultores. La col·laboració es defineix segons les responsabilitats i necessitats de cada equip.

Podem participar durant la definició del producte per contrastar viabilitat, integracions i abast, o incorporar-nos a una fase de desenvolupament. Abans de començar convé acordar qui gestiona el client, qui valida les decisions i com es revisen els avenços.

També podem valorar oportunitats derivades. Les condicions comercials, la confidencialitat i una possible comissió s’acorden expressament abans de preparar o acceptar la proposta; no hi ha un percentatge públic estàndard.


#### Quant costa un projecte i quant triga?
Source: https://www.piarconcept.com/ca/faqs/cost-and-timeline
Reviewed: 2026-10-28

No hi ha una tarifa o un termini universal per al software a mida. El pressupost depèn de l’abast, les integracions, les dades, les restriccions tècniques i el nivell de validació que necessita el projecte.

Per estimar necessitem conèixer l’objectiu, els usuaris, els sistemes implicats i qualsevol data límit real. Si encara hi ha incerteses importants, convé resoldre-les amb una fase d’anàlisi o una prova acotada abans de fixar l’abast del desenvolupament.

La proposta ha d’explicitar entregables, dependències, supòsits i exclusions. Llicències, allotjament, serveis de tercers i manteniment han de quedar diferenciats quan correspongui. Una xifra publicada sense aquest context podria induir a error.


#### Què necessiteu per començar a valorar un projecte?
Source: https://www.piarconcept.com/ca/faqs/start-a-project
Reviewed: 2026-10-28

Una explicació del problema, del resultat que busques i de com treballeu ara. Pots contactar per telèfon, WhatsApp o el botó de correu de la pàgina de contacte; no cal preparar un document tècnic extens.

Ajuda indicar qui utilitzarà el sistema, quines eines existeixen, quina informació s’ha d’intercanviar i quines restriccions de temps o pressupost hi ha. Captures o exemples sense dades sensibles poden ajudar a entendre el procés.

No enviïs contrasenyes ni bases de dades de clients en el primer contacte. Si cal revisar material privat, acordarem l’accés apropiat. Treballem des de Barcelona i podem conversar en català, castellà i anglès.


#### Què aporta Clean Architecture a un projecte?
Source: https://www.piarconcept.com/ca/faqs/clean-architecture
Reviewed: 2026-10-28

Clean Architecture separa les regles del negoci de la interfície, la base de dades i els serveis externs. L’apliquem perquè els canvis tècnics afectin tan poc com sigui possible el comportament que l’empresa necessita conservar.

Per exemple, aprovar una comanda pot dependre de límits de crèdit, permisos i disponibilitat. Aquestes regles s’han de poder entendre i provar sense obrir una pantalla ni connectar-se a l’ERP. La pantalla sol·licita l’operació i els adaptadors connecten el cas d’ús amb els sistemes necessaris.

Això facilita mantenir i fer evolucionar software amb regles complexes. Ajustem la separació a la mida del projecte: una aplicació petita no necessita tantes capes com una plataforma amb diverses àrees de negoci i integracions.


#### Què és el Piar Turbo Template?
Source: https://www.piarconcept.com/ca/faqs/piar-turbo-template
Reviewed: 2026-10-28

El PIAR Turbo Monorepo Template és la nostra base full-stack reutilitzable per iniciar aplicacions amb una estructura tècnica coherent. Organitza aplicacions, APIs i paquets compartits perquè el treball se centri abans en les necessitats del producte.

La base documentada reuneix Turborepo, pnpm, TypeScript, frontend React i backend NestJS, juntament amb convencions de format, linting i organització del codi. Ens permet reutilitzar decisions d’estructura i eines que es repeteixen entre projectes.

El template és un punt de partida, no una aplicació de negoci acabada. Els processos, permisos, dades, integracions i experiència d’ús es dissenyen per a cada projecte; la infraestructura i els components se seleccionen segons l’abast.


#### Com adaptem el template a cada empresa?
Source: https://www.piarconcept.com/ca/faqs/template-to-business-application
Reviewed: 2026-10-28

Partim dels processos i les regles del negoci, i seleccionem quines parts del Piar Turbo Template aporten valor. La base tècnica s’adapta al projecte; el projecte no s’ha d’adaptar a una plantilla funcional tancada.

En una eina de logística, per exemple, definiríem operacions com rebre mercaderia, assignar tasques o gestionar incidències. Després concretaríem les dades, permisos i connexions que necessita cada operació, abans d’implementar les pantalles i els adaptadors.

El resultat combina infraestructura de desenvolupament reutilitzable amb mòduls específics del negoci. Si el client ja té una plataforma, podem treballar en la seva estructura i incorporar només els patrons o components que encaixin, sense imposar una substitució completa.


#### Per a què serveix un monorepo amb diverses aplicacions?
Source: https://www.piarconcept.com/ca/faqs/monorepo-multiple-applications
Reviewed: 2026-10-28

Un monorepo permet mantenir diverses aplicacions i paquets relacionats en un mateix repositori. A la nostra base, Turborepo i pnpm ajuden a coordinar tasques i dependències entre frontend, APIs i codi compartit.

Un portal de clients i un backoffice poden compartir models o components d’interfície, mentre conserven les seves pantalles i responsabilitats. Tenir aquests contractes junts facilita revisar un canvi que afecta diverses parts del producte.

Compartir repositori no significa desplegar-ho tot junt ni compartir dades entre clients. Els desplegaments, accessos i emmagatzematge requereixen decisions pròpies. Utilitzem aquesta estructura quan la coordinació aporta més valor que mantenir repositoris separats.


#### Com organitzem el software per àrees de negoci?
Source: https://www.piarconcept.com/ca/faqs/domain-driven-design
Reviewed: 2026-10-28

Fem servir principis de Domain-Driven Design per organitzar el software al voltant de conceptes i responsabilitats del negoci. Així, els mòduls reflecteixen què fa l’empresa i no només les tecnologies que utilitza.

Comandes, facturació i inventari poden necessitar regles i vocabularis diferents. Definir-ne els límits permet aclarir qui decideix cada dada, quina operació pertany a cada mòdul i com es comuniquen, evitant que totes les funcions depenguin directament de les mateixes taules.

En la nostra arquitectura de features, els contractes separen cada capacitat dels seus adaptadors tècnics. No cal convertir cada mòdul en un microservei: una aplicació modular pot ser més senzilla d’operar i suficient per a l’abast previst.


#### Com evitem que una integració condicioni tot el sistema?
Source: https://www.piarconcept.com/ca/faqs/ports-and-adapters
Reviewed: 2026-10-28

Definim contractes per a les operacions que necessita el negoci i adaptadors per a cada proveïdor o sistema extern. Aquest enfocament de ports i adaptadors limita on es concentren els detalls d’una integració.

Per exemple, el cas d’ús pot necessitar consultar existències sense conèixer el format específic de l’API del proveïdor. Un adaptador transforma la petició i la resposta, i defineix com es comuniquen errors o indisponibilitat a la resta de l’aplicació.

Si canvia el proveïdor, aquesta separació ajuda a localitzar el treball, però no elimina la necessitat de revisar dades, diferències funcionals i proves. També acordem reintents, conciliació i prevenció d’operacions duplicades quan el flux ho requereix.


#### Què és un BFF i quan té sentit utilitzar-lo?
Source: https://www.piarconcept.com/ca/faqs/backend-for-frontend
Reviewed: 2026-10-28

Un Backend for Frontend, o BFF, és una capa d’API adaptada a les necessitats d’una interfície concreta. Pot preparar la informació que necessita un portal o un backoffice sense traslladar aquesta coordinació al navegador.

En una plataforma amb diverses aplicacions, cada interfície pot necessitar dades i operacions diferents. El BFF pot reunir respostes de diversos serveis i presentar un contracte adequat per a aquella experiència, mantenint les regles de negoci en els mòduls responsables.

No afegim aquesta capa per defecte a qualsevol aplicació. Té sentit quan simplifica la coordinació, les responsabilitats o l’evolució d’interfícies diferents. Els permisos s’han de verificar al servidor, independentment dels controls visibles en pantalla.


#### Com comprovem les regles de negoci i les integracions?
Source: https://www.piarconcept.com/ca/faqs/testing-business-rules
Reviewed: 2026-10-28

Separar domini, casos d’ús i adaptadors permet comprovar cada responsabilitat amb proves adequades. Combinem proves de regles de negoci, integració i recorreguts rellevants del producte segons el risc del canvi.

Una regla d’aprovació es pot provar amb diferents imports i permisos sense dependre d’un servei extern. Després, les proves d’integració comproven que l’adaptador interpreta correctament les dades i errors del sistema real o d’un entorn de proves controlat.

Els recorreguts d’extrem a extrem verifiquen que les peces funcionen juntes en operacions importants. L’objectiu és detectar comportaments incorrectes i regressions; ni el tipatge de TypeScript ni un percentatge de cobertura substitueixen la comprovació dels casos que importen al negoci.


#### Com es tradueix aquesta arquitectura en projectes reals?
Source: https://www.piarconcept.com/ca/faqs/architecture-in-client-projects
Reviewed: 2026-10-28

L’arquitectura es concreta en decisions sobre processos, dades i connexions. La nostra experiència inclou contribucions a l’ecommerce d’ISDIN amb Salesforce i SAP, funcionalitats i integracions per a Amphora i software intern de logística per a FARAFE.

Aquests contextos requereixen entendre com circula la informació, quin sistema és responsable de cada dada i què passa quan una operació falla. Separar regles, contractes i integracions ajuda a abordar aquestes decisions i a delimitar els canvis dins d’un producte existent.

El Piar Turbo Template és una base per iniciar projectes quan encaixa amb les seves necessitats. No implica que els sistemes d’aquests clients s’hagin construït amb el nostre template: en productes existents treballem amb la seva arquitectura i les restriccions del seu equip.


#### Com preparem un MVP perquè pugui evolucionar?
Source: https://www.piarconcept.com/ca/faqs/evolving-an-mvp
Reviewed: 2026-10-28

Definim una primera versió acotada que resolgui un procés complet i mantingui clares les responsabilitats del codi. Clean Architecture i el Piar Turbo Template poden aportar una base reutilitzable sense desenvolupar per endavant tot el producte.

Prioritzem les regles essencials, les dades i les integracions necessàries per validar l’ús real. Documentar les decisions i separar les dependències externes permet identificar millor què cal canviar quan apareixen noves necessitats o es confirma una hipòtesi de negoci.

L’evolució es decideix amb evidència d’ús i requisits concrets. No tot MVP necessita microserveis, diverses aplicacions o una infraestructura complexa: mesurem on és el límit i ampliem la solució on aporti valor.


### ES

#### ¿Qué hace Piar Concept?
Source: https://www.piarconcept.com/es/faqs/what-does-piar-concept-do
Reviewed: 2026-10-28

Diseñamos arquitectura de software, desarrollamos plataformas a medida y conectamos sistemas para resolver necesidades operativas de las empresas. Las webs y el diseño forman parte del servicio cuando el producto lo necesita.

El punto de partida es el proceso de negocio: qué personas intervienen, qué datos utilizan y dónde aparecen errores, tareas manuales o límites de crecimiento. A partir de ahí definimos la solución, sus integraciones y una primera entrega con alcance concreto.

Podemos intervenir en un producto nuevo o aportar capacidad técnica a uno existente. Para valorar el encaje necesitamos conocer el problema, los sistemas actuales y el objetivo; no hace falta llegar con una especificación técnica cerrada.


#### ¿Cuándo conviene desarrollar software a medida?
Source: https://www.piarconcept.com/es/faqs/custom-software-or-existing-tool
Reviewed: 2026-10-28

Tiene sentido cuando los procesos, las integraciones o las reglas del negocio no encajan bien en una herramienta estándar. Antes de desarrollar, conviene comparar adaptar una solución existente, integrarla o construir solo la parte diferencial.

La comparación debe incluir licencias, migración de datos, mantenimiento, dependencia del proveedor y el esfuerzo real de las personas que usarán la herramienta. Tener muchas funciones no es suficiente si el equipo sigue trabajando con hojas de cálculo y pasos manuales alrededor del sistema.

Un primer análisis permite separar requisitos imprescindibles de preferencias y comprobar qué puede resolverse sin crear un producto completo. La decisión depende del contexto y del coste total, no de una preferencia por programar todo desde cero.


#### ¿Qué aporta la arquitectura de software a una empresa?
Source: https://www.piarconcept.com/es/faqs/software-architecture
Reviewed: 2026-10-28

La arquitectura define cómo se organizan los componentes, los datos y las integraciones de un sistema. Sirve para tomar decisiones técnicas coherentes con la operativa, la evolución prevista y las restricciones del negocio.

En un proyecto se pueden revisar responsabilidades de cada componente, contratos de API, permisos, despliegues y gestión de errores. Es importante identificar quién es responsable de cada dato y qué ocurre cuando un servicio externo falla o cambia.

La solución adecuada no siempre es la más compleja. Una aplicación modular puede ser suficiente; separar servicios solo compensa cuando hay motivos claros. El alcance de los diagramas, las decisiones documentadas y la implementación se acuerda para cada proyecto.


#### ¿Podéis integrar un ERP, un CRM y otras APIs?
Source: https://www.piarconcept.com/es/faqs/erp-crm-api-integrations
Reviewed: 2026-10-28

Sí. Las integraciones entre sistemas forman parte del trabajo de Piar Concept. La viabilidad depende de las APIs disponibles, los permisos, las licencias y la calidad de los datos de cada sistema.

Primero se define qué información se intercambia, en qué dirección y con qué frecuencia. Después se revisan autenticación, límites de uso, correspondencia de campos, duplicados y recuperación de fallos. Una integración debe contemplar también cómo se detecta y corrige una sincronización incompleta.

Nuestra experiencia publicada incluye contribuciones a integraciones con Salesforce y SAP en ISDIN e integraciones para Amphora Logistics. Estos ejemplos no implican que cualquier conector esté listo para usar: cada entorno requiere su evaluación.


#### ¿Qué procesos internos se pueden automatizar?
Source: https://www.piarconcept.com/es/faqs/internal-tools-and-automation
Reviewed: 2026-10-28

Los mejores candidatos suelen ser tareas repetitivas con reglas claras y datos accesibles: trasladar información entre sistemas, coordinar estados, generar documentos o preparar información operativa.

Antes de automatizar se describe el flujo actual, incluidas sus excepciones y las decisiones que requieren revisión humana. Se establece una referencia medible, como el tiempo dedicado o los errores observados, para poder evaluar el resultado sin prometer un ahorro de antemano.

Piar Concept ha realizado software interno de logística y optimización de procesos para FARAFE. Para un nuevo proyecto, una primera automatización acotada permite comprobar accesos, reglas y utilidad antes de ampliar el alcance.


#### ¿Podéis trabajar sobre software que ya existe?
Source: https://www.piarconcept.com/es/faqs/existing-software
Reviewed: 2026-10-28

Sí. Podemos aportar funcionalidades, integraciones y mejoras a productos existentes. Antes de comprometernos con el alcance hay que revisar el código, la arquitectura, los entornos y la documentación disponible.

La revisión ayuda a identificar dependencias, pruebas, restricciones de despliegue y conocimiento que solo tiene el equipo actual. Con esa información se puede decidir si conviene ampliar el sistema, refactorizar una parte o sustituir un componente de forma gradual.

No planteamos una reescritura completa como requisito de entrada. Los cambios deben tener una forma de validarse y un plan de entrega compatible con la continuidad del negocio. El acceso a repositorios y entornos se coordina con el responsable del proyecto.


#### ¿Cómo abordáis la inteligencia artificial aplicada?
Source: https://www.piarconcept.com/es/faqs/applied-ai
Reviewed: 2026-10-28

Partimos de una tarea concreta y comprobamos si la IA aporta valor frente a una solución basada en reglas. La calidad de los datos, la privacidad y la forma de evaluar los resultados condicionan la viabilidad.

Un piloto debe contar con ejemplos representativos, criterios de aceptación y revisión humana cuando el riesgo lo requiere. También hay que considerar errores, costes de uso, acceso a información sensible y qué hacer cuando el sistema no dispone de una respuesta fiable.

El trabajo con ICATME se presenta como I+D TechMed en curso. No lo describimos como un producto médico validado ni como una garantía de capacidad diagnóstica. Cualquier aplicación sanitaria exige su propia evaluación profesional y regulatoria.


#### ¿Colaboráis con estudios de UX, diseño y consultoras?
Source: https://www.piarconcept.com/es/faqs/ux-and-consultancy-partners
Reviewed: 2026-10-28

Sí. Piar Concept puede aportar arquitectura e implementación técnica a proyectos liderados por estudios de UX, diseño o consultoras. La colaboración se define según las responsabilidades y necesidades de cada equipo.

Podemos participar durante la definición del producto para contrastar viabilidad, integraciones y alcance, o incorporarnos a una fase de desarrollo. Antes de empezar conviene acordar quién gestiona al cliente, quién valida las decisiones y cómo se revisan los avances.

También podemos valorar oportunidades derivadas. Las condiciones comerciales, la confidencialidad y una posible comisión se acuerdan expresamente antes de preparar o aceptar la propuesta; no hay un porcentaje público estándar.


#### ¿Cuánto cuesta un proyecto y cuánto tarda?
Source: https://www.piarconcept.com/es/faqs/cost-and-timeline
Reviewed: 2026-10-28

No hay una tarifa o un plazo universal para software a medida. El presupuesto depende del alcance, las integraciones, los datos, las restricciones técnicas y el nivel de validación que necesita el proyecto.

Para estimar necesitamos conocer el objetivo, los usuarios, los sistemas implicados y cualquier fecha límite real. Si todavía hay incertidumbres importantes, conviene resolverlas con una fase de análisis o una prueba acotada antes de fijar el alcance de desarrollo.

La propuesta debe explicitar entregables, dependencias, supuestos y exclusiones. Licencias, alojamiento, servicios de terceros y mantenimiento deben quedar diferenciados cuando correspondan. Una cifra publicada sin ese contexto podría inducir a error.


#### ¿Qué necesitáis para empezar a valorar un proyecto?
Source: https://www.piarconcept.com/es/faqs/start-a-project
Reviewed: 2026-10-28

Una explicación del problema, del resultado que buscas y de cómo trabajáis ahora. Puedes contactar por teléfono, WhatsApp o el botón de email de la página de contacto; no es necesario preparar un documento técnico extenso.

Ayuda indicar quién utilizará el sistema, qué herramientas existen, qué información debe intercambiarse y qué restricciones de tiempo o presupuesto hay. Capturas o ejemplos sin datos sensibles pueden ayudar a entender el proceso.

No envíes contraseñas ni bases de datos de clientes en el primer contacto. Si hace falta revisar material privado, acordaremos el acceso apropiado. Trabajamos desde Barcelona y podemos conversar en catalán, castellano e inglés.


#### ¿Qué aporta Clean Architecture a un proyecto?
Source: https://www.piarconcept.com/es/faqs/clean-architecture
Reviewed: 2026-10-28

Clean Architecture separa las reglas del negocio de la interfaz, la base de datos y los servicios externos. La aplicamos para que los cambios técnicos afecten lo menos posible al comportamiento que la empresa necesita conservar.

Por ejemplo, aprobar un pedido puede depender de límites de crédito, permisos y disponibilidad. Esas reglas deben poder entenderse y probarse sin abrir una pantalla ni conectarse al ERP. La pantalla solicita la operación y los adaptadores conectan el caso de uso con los sistemas necesarios.

Esto facilita mantener y evolucionar software con reglas complejas. Ajustamos la separación al tamaño del proyecto: una aplicación pequeña no necesita tantas capas como una plataforma con varias áreas de negocio e integraciones.


#### ¿Qué es el Piar Turbo Template?
Source: https://www.piarconcept.com/es/faqs/piar-turbo-template
Reviewed: 2026-10-28

El PIAR Turbo Monorepo Template es nuestra base full-stack reutilizable para iniciar aplicaciones con una estructura técnica coherente. Organiza aplicaciones, APIs y paquetes compartidos para que el trabajo se centre antes en las necesidades del producto.

La base documentada reúne Turborepo, pnpm, TypeScript, frontend React y backend NestJS, junto con convenciones de formato, linting y organización del código. Nos permite reutilizar decisiones de estructura y herramientas que se repiten entre proyectos.

El template es un punto de partida, no una aplicación de negocio terminada. Los procesos, permisos, datos, integraciones y experiencia de uso se diseñan para cada proyecto; la infraestructura y los componentes se seleccionan según su alcance.


#### ¿Cómo adaptamos el template a cada empresa?
Source: https://www.piarconcept.com/es/faqs/template-to-business-application
Reviewed: 2026-10-28

Partimos de los procesos y las reglas del negocio, y seleccionamos qué partes del Piar Turbo Template aportan valor. La base técnica se adapta al proyecto; el proyecto no tiene que adaptarse a una plantilla funcional cerrada.

En una herramienta de logística, por ejemplo, definiríamos operaciones como recibir mercancía, asignar tareas o gestionar incidencias. Después concretaríamos los datos, permisos y conexiones que necesita cada operación, antes de implementar las pantallas y los adaptadores.

El resultado combina infraestructura de desarrollo reutilizable con módulos específicos del negocio. Si el cliente ya tiene una plataforma, podemos trabajar en su estructura e incorporar solo los patrones o componentes que encajen, sin imponer una sustitución completa.


#### ¿Para qué sirve un monorepo con varias aplicaciones?
Source: https://www.piarconcept.com/es/faqs/monorepo-multiple-applications
Reviewed: 2026-10-28

Un monorepo permite mantener varias aplicaciones y paquetes relacionados en un mismo repositorio. En nuestra base, Turborepo y pnpm ayudan a coordinar tareas y dependencias entre frontend, APIs y código compartido.

Un portal de clientes y un backoffice pueden compartir modelos o componentes de interfaz, mientras conservan sus pantallas y responsabilidades. Tener esos contratos juntos facilita revisar un cambio que afecta a varias partes del producto.

Compartir repositorio no significa desplegar todo junto ni compartir datos entre clientes. Los despliegues, accesos y almacenamiento requieren decisiones propias. Utilizamos esta estructura cuando la coordinación aporta más valor que mantener repositorios separados.


#### ¿Cómo organizamos el software por áreas de negocio?
Source: https://www.piarconcept.com/es/faqs/domain-driven-design
Reviewed: 2026-10-28

Usamos principios de Domain-Driven Design para organizar el software alrededor de conceptos y responsabilidades del negocio. Así, los módulos reflejan lo que la empresa hace y no solo las tecnologías que utiliza.

Pedidos, facturación e inventario pueden necesitar reglas y vocabularios distintos. Definir sus límites permite aclarar quién decide cada dato, qué operación pertenece a cada módulo y cómo se comunican, evitando que todas las funciones dependan directamente de las mismas tablas.

En nuestra arquitectura de features, los contratos separan cada capacidad de sus adaptadores técnicos. No es necesario convertir cada módulo en un microservicio: una aplicación modular puede ser una opción más sencilla de operar y suficiente para el alcance previsto.


#### ¿Cómo evitamos que una integración condicione todo el sistema?
Source: https://www.piarconcept.com/es/faqs/ports-and-adapters
Reviewed: 2026-10-28

Definimos contratos para las operaciones que necesita el negocio y adaptadores para cada proveedor o sistema externo. Este enfoque de puertos y adaptadores limita dónde se concentran los detalles de una integración.

Por ejemplo, el caso de uso puede necesitar consultar existencias sin conocer el formato específico de la API del proveedor. Un adaptador transforma la petición y la respuesta, y define cómo se comunican errores o indisponibilidad al resto de la aplicación.

Si cambia el proveedor, esa separación ayuda a localizar el trabajo, pero no elimina la necesidad de revisar datos, diferencias funcionales y pruebas. También acordamos reintentos, conciliación y prevención de operaciones duplicadas cuando el flujo lo requiere.


#### ¿Qué es un BFF y cuándo tiene sentido utilizarlo?
Source: https://www.piarconcept.com/es/faqs/backend-for-frontend
Reviewed: 2026-10-28

Un Backend for Frontend, o BFF, es una capa de API adaptada a las necesidades de una interfaz concreta. Puede preparar la información que necesita un portal o un backoffice sin trasladar esa coordinación al navegador.

En una plataforma con varias aplicaciones, cada interfaz puede necesitar datos y operaciones diferentes. El BFF puede reunir respuestas de varios servicios y presentar un contrato adecuado para esa experiencia, manteniendo las reglas de negocio en los módulos responsables.

No añadimos esta capa por defecto a cualquier aplicación. Tiene sentido cuando simplifica la coordinación, las responsabilidades o la evolución de interfaces distintas. Los permisos deben verificarse en el servidor, independientemente de los controles visibles en pantalla.


#### ¿Cómo comprobamos las reglas de negocio y las integraciones?
Source: https://www.piarconcept.com/es/faqs/testing-business-rules
Reviewed: 2026-10-28

Separar dominio, casos de uso y adaptadores permite comprobar cada responsabilidad con pruebas apropiadas. Combinamos pruebas de reglas de negocio, integración y recorridos relevantes del producto según el riesgo del cambio.

Una regla de aprobación puede probarse con distintos importes y permisos sin depender de un servicio externo. Después, las pruebas de integración comprueban que el adaptador interpreta correctamente los datos y errores del sistema real o de un entorno de pruebas controlado.

Los recorridos de extremo a extremo verifican que las piezas funcionan juntas en operaciones importantes. El objetivo es detectar comportamientos incorrectos y regresiones; ni el tipado de TypeScript ni un porcentaje de cobertura sustituyen la comprobación de los casos que importan al negocio.


#### ¿Cómo se traduce esta arquitectura en proyectos reales?
Source: https://www.piarconcept.com/es/faqs/architecture-in-client-projects
Reviewed: 2026-10-28

La arquitectura se concreta en decisiones sobre procesos, datos y conexiones. Nuestra experiencia incluye contribuciones al ecommerce de ISDIN con Salesforce y SAP, funcionalidades e integraciones para Amphora y software interno de logística para FARAFE.

Estos contextos requieren entender cómo circula la información, qué sistema es responsable de cada dato y qué ocurre cuando una operación falla. Separar reglas, contratos e integraciones ayuda a abordar esas decisiones y a delimitar los cambios dentro de un producto existente.

El Piar Turbo Template es una base para iniciar proyectos cuando encaja con sus necesidades. No implica que los sistemas de estos clientes se hayan construido con nuestro template: en productos existentes trabajamos con su arquitectura y las restricciones de su equipo.


#### ¿Cómo preparamos un MVP para que pueda evolucionar?
Source: https://www.piarconcept.com/es/faqs/evolving-an-mvp
Reviewed: 2026-10-28

Definimos una primera versión acotada que resuelva un proceso completo y mantenga claras las responsabilidades del código. Clean Architecture y el Piar Turbo Template pueden aportar una base reutilizable sin desarrollar por adelantado todo el producto.

Priorizamos las reglas esenciales, los datos y las integraciones necesarias para validar el uso real. Documentar las decisiones y separar las dependencias externas permite identificar mejor qué cambiar cuando aparecen nuevas necesidades o se confirma una hipótesis de negocio.

La evolución se decide con evidencia de uso y requisitos concretos. No todo MVP necesita microservicios, varias aplicaciones o una infraestructura compleja: medimos dónde está el límite y ampliamos la solución donde aporte valor.


### EN

#### What does Piar Concept do?
Source: https://www.piarconcept.com/en/faqs/what-does-piar-concept-do
Reviewed: 2026-10-28

We design software architecture, build custom platforms and connect systems to address business operations. Websites and design form part of our service when the product needs them.

We start with the business process: who is involved, which data they use and where errors, manual tasks or growth constraints occur. We then define the solution, its integrations and a first delivery with a specific scope.

We can contribute to a new product or bring engineering capacity to an existing one. To assess fit, we need to understand the problem, current systems and objective; a completed technical specification is not required.


#### When does custom software make sense?
Source: https://www.piarconcept.com/en/faqs/custom-software-or-existing-tool
Reviewed: 2026-10-28

Custom software makes sense when business processes, integrations or rules do not fit an off-the-shelf tool well. Before building, compare adapting an existing solution, integrating it or developing only the differentiating part.

Compare licensing, data migration, maintenance, vendor dependency and the actual effort required of the people using the tool. A long feature list is not enough if the team still relies on spreadsheets and manual work around the system.

An initial assessment separates essential requirements from preferences and identifies what can be solved without creating an entire product. The decision depends on context and total cost, rather than a preference for building everything from scratch.


#### What does software architecture contribute to a business?
Source: https://www.piarconcept.com/en/faqs/software-architecture
Reviewed: 2026-10-28

Architecture defines how a system’s components, data and integrations are organised. It helps align technical decisions with operations, expected evolution and business constraints.

A project may examine component responsibilities, API contracts, permissions, deployment and error handling. It is important to establish which system owns each piece of data and what happens when an external service fails or changes.

The right solution is not always the most complex. A modular application may be sufficient; separate services are worthwhile only when there are clear reasons. The scope of diagrams, documented decisions and implementation is agreed per project.


#### Can you integrate ERP, CRM and other APIs?
Source: https://www.piarconcept.com/en/faqs/erp-crm-api-integrations
Reviewed: 2026-10-28

Yes. Systems integration is part of Piar Concept’s work. Feasibility depends on available APIs, permissions, licensing and the quality of each system’s data.

We first define what information is exchanged, in which direction and how frequently. We then examine authentication, usage limits, field mapping, duplicates and failure recovery. An integration should also account for detecting and correcting incomplete synchronisation.

Our published experience includes contributions to Salesforce and SAP integrations at ISDIN and integrations for Amphora Logistics. These examples do not mean that every connector is ready to use: each environment needs assessment.


#### Which internal processes can be automated?
Source: https://www.piarconcept.com/en/faqs/internal-tools-and-automation
Reviewed: 2026-10-28

Good candidates are often repetitive tasks with clear rules and accessible data: transferring information between systems, coordinating statuses, generating documents or preparing operational information.

Before automating, describe the current workflow, including exceptions and decisions that require human review. Establish a measurable baseline, such as time spent or observed errors, to evaluate the result without promising savings in advance.

Piar Concept has delivered internal logistics software and process optimisation work for FARAFE. For a new project, a limited initial automation helps validate access, rules and usefulness before expanding the scope.


#### Can you work on existing software?
Source: https://www.piarconcept.com/en/faqs/existing-software
Reviewed: 2026-10-28

Yes. We can contribute features, integrations and improvements to existing products. Before committing to scope, we need to review the code, architecture, environments and available documentation.

The review identifies dependencies, tests, deployment constraints and knowledge held only by the current team. It informs whether to extend the system, refactor a part or replace a component gradually.

A complete rewrite is not an entry requirement. Changes need a validation method and a delivery plan compatible with business continuity. Access to repositories and environments is coordinated with the project owner.


#### How do you approach applied AI?
Source: https://www.piarconcept.com/en/faqs/applied-ai
Reviewed: 2026-10-28

We start with a specific task and assess whether AI adds value compared with a rules-based solution. Data quality, privacy and how results will be evaluated determine feasibility.

A pilot needs representative examples, acceptance criteria and human review where the risk requires it. It must also consider errors, usage costs, access to sensitive information and what to do when the system cannot provide a reliable answer.

Our work with ICATME is described as ongoing TechMed R&D. We do not present it as a validated medical product or a guarantee of diagnostic capability. Any healthcare application requires its own professional and regulatory assessment.


#### Do you collaborate with UX studios and consultancies?
Source: https://www.piarconcept.com/en/faqs/ux-and-consultancy-partners
Reviewed: 2026-10-28

Yes. Piar Concept can contribute architecture and technical implementation to projects led by UX studios, design studios or consultancies. Collaboration is defined around each team’s responsibilities and needs.

We can participate during product definition to assess feasibility, integrations and scope, or join at the development stage. Before starting, agree who manages the client, who approves decisions and how progress is reviewed.

We can also assess referred opportunities. Commercial terms, confidentiality and any referral commission are explicitly agreed before preparing or accepting a proposal; there is no standard public percentage.


#### How much does a project cost and how long does it take?
Source: https://www.piarconcept.com/en/faqs/cost-and-timeline
Reviewed: 2026-10-28

There is no universal price or timeline for custom software. Cost depends on scope, integrations, data, technical constraints and the level of validation the project needs.

To estimate, we need the objective, users, systems involved and any genuine deadline. Where significant uncertainty remains, an assessment or a limited proof of concept can resolve it before fixing the development scope.

A proposal should state deliverables, dependencies, assumptions and exclusions. Licensing, hosting, third-party services and maintenance should be distinguished where relevant. Publishing a figure without that context could be misleading.


#### What do you need to assess a new project?
Source: https://www.piarconcept.com/en/faqs/start-a-project
Reviewed: 2026-10-28

An explanation of the problem, the result you want and how you work today. Contact us by phone, WhatsApp or the email button on the contact page; a lengthy technical document is not necessary.

It helps to identify who will use the system, existing tools, information that must be exchanged and any time or budget constraints. Screenshots or examples without sensitive data can help explain the process.

Do not send passwords or customer databases in the initial enquiry. If private material needs review, we will agree suitable access. We work from Barcelona and can discuss projects in Catalan, Spanish and English.


#### What does Clean Architecture bring to a project?
Source: https://www.piarconcept.com/en/faqs/clean-architecture
Reviewed: 2026-10-28

Clean Architecture separates business rules from the interface, database and external services. We apply it to limit how much technical changes affect the behaviour a business needs to preserve.

For example, approving an order may depend on credit limits, permissions and availability. These rules should be understandable and testable without opening a screen or connecting to an ERP. The screen requests the operation, while adapters connect the use case to the systems it needs.

This makes software with complex rules easier to maintain and evolve. We adapt the separation to the project: a small application does not need as many layers as a platform spanning multiple business areas and integrations.


#### What is the Piar Turbo Template?
Source: https://www.piarconcept.com/en/faqs/piar-turbo-template
Reviewed: 2026-10-28

The PIAR Turbo Monorepo Template is our reusable full-stack foundation for starting applications with a consistent technical structure. It organises applications, APIs and shared packages so work can focus sooner on product needs.

The documented foundation brings together Turborepo, pnpm, TypeScript, a React frontend and a NestJS backend, with formatting, linting and code organisation conventions. It lets us reuse structural decisions and tools that recur across projects.

The template is a starting point, not a finished business application. Processes, permissions, data, integrations and user experience are designed for each project; infrastructure and components are selected according to scope.


#### How do we adapt the template to each business?
Source: https://www.piarconcept.com/en/faqs/template-to-business-application
Reviewed: 2026-10-28

We start with business processes and rules, then select the parts of the Piar Turbo Template that add value. The technical foundation adapts to the project; the project does not have to fit a fixed set of business features.

For a logistics tool, for example, we would define operations such as receiving goods, assigning tasks or managing incidents. We would then establish the data, permissions and connections each operation needs before implementing screens and adapters.

The result combines reusable development infrastructure with business-specific modules. If a client already has a platform, we can work within its structure and introduce only suitable patterns or components, without requiring a complete replacement.


#### Why use a monorepo for multiple applications?
Source: https://www.piarconcept.com/en/faqs/monorepo-multiple-applications
Reviewed: 2026-10-28

A monorepo keeps related applications and packages in one repository. In our foundation, Turborepo and pnpm help coordinate tasks and dependencies across frontends, APIs and shared code.

A customer portal and a backoffice can share models or interface components while keeping their own screens and responsibilities. Keeping those contracts together makes changes spanning several parts of a product easier to review.

Sharing a repository does not mean deploying everything together or sharing customer data. Deployments, access and storage need their own decisions. We use this structure when coordination adds more value than maintaining separate repositories.


#### How do we organise software around business areas?
Source: https://www.piarconcept.com/en/faqs/domain-driven-design
Reviewed: 2026-10-28

We use Domain-Driven Design principles to organise software around business concepts and responsibilities. Modules then reflect what the company does, rather than just the technologies it uses.

Orders, billing and inventory may need different rules and terminology. Defining boundaries clarifies who owns each piece of data, which operations belong to each module and how modules communicate, instead of making every feature depend directly on the same tables.

In our feature architecture, contracts separate each capability from its technical adapters. Each module does not need to become a microservice: a modular application can be simpler to operate and sufficient for the intended scope.


#### How do we keep an integration from shaping the entire system?
Source: https://www.piarconcept.com/en/faqs/ports-and-adapters
Reviewed: 2026-10-28

We define contracts for the operations the business needs and adapters for each external provider or system. This ports-and-adapters approach concentrates integration-specific details within clear boundaries.

For example, a use case may need to check stock without knowing the provider’s API format. An adapter translates requests and responses and defines how errors or unavailability are communicated to the rest of the application.

If the provider changes, this separation helps locate the work, but data, functional differences and tests still need review. We also define retries, reconciliation and duplicate-operation prevention where the workflow requires them.


#### What is a BFF and when does it make sense?
Source: https://www.piarconcept.com/en/faqs/backend-for-frontend
Reviewed: 2026-10-28

A Backend for Frontend, or BFF, is an API layer tailored to a particular interface. It can prepare the information a portal or backoffice needs without moving that coordination into the browser.

On a platform with multiple applications, each interface may need different data and operations. A BFF can combine responses from several services and expose a contract suited to that experience, while business rules remain in the modules responsible for them.

We do not add this layer by default to every application. It makes sense when it simplifies coordination, responsibilities or the evolution of different interfaces. Permissions must be checked on the server regardless of the controls visible on screen.


#### How do we verify business rules and integrations?
Source: https://www.piarconcept.com/en/faqs/testing-business-rules
Reviewed: 2026-10-28

Separating domain logic, use cases and adapters lets us test each responsibility appropriately. We combine business-rule tests, integration tests and relevant product journeys according to the risk of a change.

An approval rule can be tested with different amounts and permissions without relying on an external service. Integration tests then check that the adapter correctly interprets data and errors from the actual system or a controlled test environment.

End-to-end journeys verify that the parts work together for important operations. The aim is to detect incorrect behaviour and regressions; neither TypeScript types nor a coverage percentage replace checking the cases that matter to the business.


#### How does this architecture translate into real projects?
Source: https://www.piarconcept.com/en/faqs/architecture-in-client-projects
Reviewed: 2026-10-28

Architecture becomes concrete through decisions about processes, data and connections. Our experience includes contributions to ISDIN’s ecommerce with Salesforce and SAP, features and integrations for Amphora, and internal logistics software for FARAFE.

These contexts require understanding how information flows, which system owns each piece of data and what happens when an operation fails. Separating rules, contracts and integrations helps address these decisions and contain changes within an existing product.

The Piar Turbo Template is a foundation for starting projects when it fits their needs. This does not mean these clients’ systems were built with our template: on existing products, we work within their architecture and their team’s constraints.


#### How do we prepare an MVP to evolve?
Source: https://www.piarconcept.com/en/faqs/evolving-an-mvp
Reviewed: 2026-10-28

We define a focused first version that handles a complete process and keeps code responsibilities clear. Clean Architecture and the Piar Turbo Template can provide a reusable foundation without building the entire product upfront.

We prioritise essential rules, data and integrations needed to validate real usage. Documenting decisions and separating external dependencies makes it easier to identify what should change when new needs emerge or a business hypothesis is confirmed.

Evolution is driven by usage evidence and specific requirements. Not every MVP needs microservices, multiple applications or complex infrastructure: we assess where the constraint lies and extend the solution where it adds value.


## Legal
- [Privacy policy](https://www.piarconcept.com/en/legal/privacy)
- [Terms](https://www.piarconcept.com/en/legal/terms)
- [Cookie policy](https://www.piarconcept.com/en/legal/cookies)