Sus equipos trabajan en hojas de cálculo, en paralelo al software que compró.
No partimos de un producto estándar que usted tenga que esquivar después. Partimos de sus procesos, sus restricciones y sus objetivos, y construimos lo que realmente les corresponde.
- El código le pertenece
- Integrado con su sistema existente
- Creación o modernización
Three symptoms of software that does not fit
They rarely appear alone, and they cost far more than the licence.
Systematic workarounds
The tool was bought, deployed, trained on. Teams ended up opening a spreadsheet alongside it, because the real process does not fit. Double entry became the norm, and every duplicate is an error waiting to happen.
The field that does not exist
A piece of information essential to your business is missing, and the vendor will not add it to the product for one customer. It ends up in a “comments” field, from which no usable data will ever emerge.
The integration wall
The tools do not talk to each other. The same data is entered three times, in three systems, with three slightly different values. Nobody knows which one governs.
What we build
The common thread: the solution models your process instead of forcing you into a vendor's.
Management software
Activity tracking, steering, document management, project management, internal tools built for one specific trade.
Business CRM and ERP
Commercial and internal management shaped around your real cycle, not a generic one to be adapted.
Client portals
User spaces, case tracking, document upload, traced exchanges, with your access rules.
Web and mobile applications
Reachable from a browser or a phone, including in poor connectivity conditions.
Reporting and dashboards
Your business indicators, computed on your definitions, available without an export.
Modernising what exists
Interface redesign, architecture rework, new features, performance improvement, opening up APIs.
How a project runs
You see something real running long before the end. That is the only way to correct early.
Modelling the real process
We observe how the work actually gets done, workarounds and unofficial spreadsheets included — that is where the real process lives, rarely in the written procedure. This phase produces the model everything else refers to.
Architecture and scope
What the software covers, what it does not, what it takes over from the existing setup, how it wires into your systems. The first batch is deliberately narrow: shipping early beats shipping complete.
Development in batches
Each batch is delivered, tested by your users and corrected before the next one starts. You see your process running on real data within the first weeks, not at final acceptance.
Systems integration
Connection to the CRM, ERP, databases, APIs and existing services, to remove double entry. Where a third-party tool has no API, we build the connector.
Go-live and handover
Data migration, team training, launch support, technical and functional documentation. You own the code: you can take over in-house or change supplier.
Three projects, three starting points
Production tracking lives in four shared spreadsheets. The data is re-keyed into the ERP the next day, with discrepancies.
A production-tracking application modelled on the actual workstations, wired into the ERP by API, usable from shop-floor tablets.
Entry happens once, at source. The gap between tracking and the ERP disappears, and same-day steering becomes possible.
Engagement tracking, invoicing and client exchanges are split across three tools that do not talk to each other.
A single business platform with a client portal, engagement tracking, document space and invoicing generation.
One place governs. Clients follow their case without chasing, and invoicing stops being a month-end project.
An internal tool built for their own need is attracting interest from other companies in the sector.
Architecture rework towards a multi-organisation platform, role and permission management, API exposure and industrialisation.
The internal tool becomes a sellable product, with the governance needed to host several customers.
How we build
These are not aesthetic choices: each one has a direct consequence on what the software will cost you in three years.
- Code ownership
- You own the custom development code, with documentation and knowledge transfer.
- Mainstream technologies
- Nothing exotic: another supplier must be able to take the project over without a rewrite.
- API first
- Every function is exposed through an API, which makes integration and later AI additions possible without a rebuild.
- Native rights and permissions
- Roles, organisations and teams are designed in from the start, not added when a customer demands them.
- Delivery in batches
- Each batch is usable and tested in real conditions before the next.
- AI-ready
- The architecture allows agents and assistants to be added later, wired into the same rights and the same data.
What we commit to
These commitments are in the contract, not only on this page.
- of custom code transferred, with documentation and knowledge transfer
- 100 %
of custom code transferred, with documentation and knowledge transfer
- of scoping before any development: perimeter, architecture, firm budget
- 2-3 weeks
of scoping before any development: perimeter, architecture, firm budget
- forced dependency: you can take over in-house or change supplier
- 0
forced dependency: you can take over in-house or change supplier
Estos órdenes de magnitud proceden de lo que medimos en el piloto sobre alcances comparables. Sobre su corpus se miden antes de la industrialización, no se prometen antes.
Preguntas frecuentes
You do. Documentation and knowledge transfer are planned from the start, and you can take over in-house or change supplier without asking our permission.
Two to three weeks of scoping, then a usable first batch within the following weeks. You test your process on real data well before final acceptance.
Yes: interface modernisation, architecture rework, new features, performance improvement, API exposure. We start with an audit of the existing code and data.
The architecture plans for it. Every function is exposed through an API and rights are native, which lets agents and assistants be wired in without a rebuild — exactly where the two poles meet.
A range at the diagnostic, a firm budget at the end of scoping, then fixed price per batch or time and materials depending on scope. Later batches are only committed after the previous one is signed off.
Maintenance and evolutions under subscription, or handover to your teams if you prefer. Both are open, because the code is yours.
Lo que esta solución no hace
Custom is not always the right answer. When a market product covers ninety per cent of your need and the remaining ten per cent is not strategic, we say so and we do not take the project — buying a licence will cost you less than we would. Custom is justified when the process is your differentiation, or when no tool models it.
Which process do your teams work around today?
That is almost always where the project is. Thirty minutes is enough to tell whether it calls for custom software or an off-the-shelf product.