Solutions
Web platforms for processes that outgrew the spreadsheet.
Design and development of portals, dashboards, workflows, user systems, and integrations with whatever already runs the business.
Symptoms
How you know it is time.
Almost nobody asks for "a platform." What gets noticed first is this:
- There is a spreadsheet nobody dares touch because "so-and-so handles it."
- The same information gets entered two or three times in different tools.
- Nobody can tell you the status of anything without asking a specific person.
- The process works, but only when that person is available.
- Decisions get made on numbers someone consolidated by hand last week.
- Growing means hiring someone else to do the same manual work.
What we build
Types of platform.
Client portals
Self-service, status lookup, documents, and communication, with per-profile access control.
Admin dashboards
Data, catalogs, users, and internal operations with differentiated roles.
B2B and B2C platforms
Catalogs, ordering, per-client pricing, and approval flows.
Quoting tools and configurators
Pricing and product rules turned into a flow the sales team can use without getting it wrong.
Records and documentation
Upload, review, versioning, and traceability of documents with states and owners.
Internal processes
Workflows, approvals, and operational reporting that currently live in email.
Architecture
Designed around capabilities, not a list of technologies.
Designed around capabilities, not a list of technologies.
The question is not "React or Vue?" It is what the system has to carry three years from now: how many users, which integrations, which data cannot be lost, and which parts will change often. The architecture follows from those answers, and it gets documented so the next person does not have to reverse-engineer it.
- React frontend with strict TypeScript and a component system of its own.
- APIs with authentication, role-based authorization, and server-side validation — not just browser-side.
- An explicit data model, with the business rules in one place.
- Integrations with clear boundaries: what the system owns and what it does not.
- Separate environments, reproducible deployments, and the ability to roll back.
- Enough observability to know something broke before a user reports it.
Integrations
Data, roles, and systems that already exist.
Almost no project starts on a blank page. The hard part is usually coexisting with what is already there.
- Integration with ERP, CRM, or internal systems via API or file exchange.
- Identity: local, corporate, or federated sign-in, depending on what the company already uses.
- Roles and permissions with real granularity, not two levels of administrator.
- Payments and invoicing when the flow requires them.
- Data import and export, because it is always needed eventually.
- Traceability: who did what, and when.
Modernization
When the system exists and has to be rescued.
A full rewrite is the most expensive decision available and the one that sinks the most projects. There is almost always a phased path: isolate what works, replace piece by piece, and keep the operation running throughout.
Audit
What exists, what is actually used, what depends on what, and where the risk sits.
Containment
Stop the bleeding: environments, backups, security, and whatever is on fire.
Piece-by-piece replacement
Modules get replaced one at a time, old and new running side by side.
Retirement
The old system is switched off once nothing depends on it anymore.
Process
From idea to operation.
Discovery
The real business rules, not the documented ones. They are usually different.
Prototype
A clickable flow the people who will use it can criticize before it gets built.
Architecture
Data model, integrations, roles, and system boundaries. Documented.
Increments
Reviewable releases. The first useful module ships before the whole system does.
QA
Testing, accessibility, performance, and a security review before every release.
Launch
Data migration, training, monitoring, and support through the first weeks.
How you hire
Three routes, depending on how defined the scope is.
If the scope is not clear, a fixed-price project is a risk for both sides. Start with consulting and close the scope afterward.
01
Managed project team
When to use it: The outcome is defined and the responsibility should be ours.
Commercial unit: Scope, schedule, and milestones
02
Dedicated cell
When to use it: You need sustained speed and continuity against an objective.
Commercial unit: Team per month
03
Embedded specialist
When to use it: A specific role is missing inside a team that already works.
Commercial unit: Role per period
Let's turn the process into a platform.
Tell us how it works today — spreadsheets included.