Most big data projects are tidying projects
The request almost always arrives called big data. Look closely and there is a modest amount of data spread across an ERP, a CRM, two databases and a lot of spreadsheets, none of which agree with each other. The honest answer is a warehouse and clean pipelines, not a platform.
What big data usually turns out to mean
Volume is rarely the problem. A two hundred person company produces data that fits comfortably in PostgreSQL or SQL Server with several years of history. What hurts is that the same idea exists in five shapes across five systems and nobody knows which one is authoritative.
So the useful work is choosing one place where data lands, writing the pipelines that bring it there every day without supervision, and settling once and for all what a customer, an order and a machine are. It does not sell well. It is what changes decisions.
A dashboard nobody opens is a failure
It is the most common deliverable in this field and the most useless. It looks good, it cost a lot, it was presented once, and three months later it is wrong because nobody looked at it often enough to notice.
So we start from the decision, not the screen. Which decision has to change, who makes it, how often, and which number is missing today. If no decision changes there is no project, and it is better to say that at the start than at the end.
If the sources disagree, no pipeline fixes that
When the ERP and the CRM report two different revenue figures, the question is not technical. Somebody has to rule on what counts as a sale, on what date, and what happens to credit notes and discounts. Until that ruling exists, a pipeline only copies the disagreement faster.
We document the gaps, size them and put them in front of you. The decision belongs to the business. Our work starts once it is made, and it consists of making sure it is applied the same way everywhere.
What we actually build
A warehouse on PostgreSQL or SQL Server, hosted on Azure, with the ingestion pipelines that feed it, written in .NET or Node. Deployment goes through Docker, Terraform and GitHub Actions like everything else we ship, so rebuilding the whole thing is a known operation rather than an adventure.
We have pushed machine data into Azure in industrial settings and integrated ERP and MES systems. That kind of flow is not glamorous: it falls over at night, it receives nonsense values, it receives the same message twice. A pipeline is judged on what it does in those cases, not on its architecture diagram.
For reporting we connect the tool you already have. Nobody needs another visualisation tool.
Where we are the wrong answer
If you already have a clean warehouse and the need is modelling or business analysis, hire an analyst or a BI firm. We build the plumbing. We are not your analytics team.
If the need is machine learning research, a model to design and train, that is not our ground. We can put an existing model into production and keep it running. We are not a lab.
And if your data fits in a spreadsheet that three people maintain properly, keep the spreadsheet. The moment to build arrives when the manual round trips between systems cost more each month than the plumbing that would remove them.
The pieces we deliver, almost always in this order and rarely all of them.
- Inventory and gapsBusiness workshops, SQLWhere the data lives, which system is authoritative, and a sized list of the contradictions.
- WarehousePostgreSQL, SQL Server, AzureOne place where data lands, with a model the business recognises.
- Ingestion pipelines.NET, Node, AzureDaily or continuous loads, safe to replay, with a log and an alert when they fail.
- Machine and industrial dataAzure, DockerEquipment data into Azure and MES integration, including outliers and duplicates.
- Running itTerraform, GitHub ActionsFull rebuild from the repository, monitoring and an agreed on-call arrangement.
Common questions
- Were we sold a data lake we do not need?
- Possibly. A lake earns its place when you store large raw volumes whose use is not yet decided. If your data comes from an ERP, a CRM and some files, a relational warehouse is simpler, cheaper and easier to query.
- Where do we start when everything is a mess?
- With one business question that is expensive today, and the two or three sources behind it. A narrow scope delivered in a few weeks teaches you more than a twelve month target architecture.
- Where will the data be hosted?
- On your infrastructure, or on an Azure subscription you control, in the region you choose. Morocco is not on the European Commission adequacy list, so our engineers work inside your environment rather than moving the data. Contracting is through JADEV GROUP SARL in Belgium.
- Are you ISO 27001 certified?
- Not today. Our practices follow ISO/IEC 27001 principles and are mapped against CyberFundamentals from the Belgian Centre for Cybersecurity, with the Stage 2 audit planned with a BELAC-accredited body in 2027. Encryption, enforced MFA, least privilege and access review at project close are in place now.
- Can you take over existing pipelines?
- Yes, and it is often cheaper than starting again. We run and watch them as they are first, long enough to learn what breaks and how often. A rewrite decided before that period is a rewrite decided blind.
- Do we need a particular BI tool?
- No. We deliver clean documented data that the tool you already use can query. If you have none, we will recommend one, but that is not the hard part.
Tell us which decision is missing its numbers
Describe the question your data cannot answer yet and the systems involved. The scoping assistant asks the questions an engineer would ask, then returns an estimate with a scope and a start date.
Scope a data engagement- Payment idempotency for iDEAL and BancontactOne replayed webhook is enough to charge the same traveler twice. We explain the idempotency key design that makes it impossible, drawn from booking platforms we run in production with iDEAL and Bancontact.
- Industrial IoT data ingestion on Azure: the patternThe pattern that makes machine data ingestion into Azure survive real plant conditions: a queue between the shop floor and the cloud, priced in engineering days on our public rates.
- ERP and MES integration cost, estimated in daysThe method we use to estimate MES and ERP integration in engineering days, with a complete worked example priced from our public rate grid.
- Zero downtime data migration: dual write to cutoverThe new system shadows the old one in silence, the copies are proven to match, and the rollback lever stays live until the end. The full playbook, priced, limits included.
- IT staff augmentationNamed engineers inside your existing team, on a European working day, contracted through Belgium.
- Nearshore vs offshoreA straight comparison for European teams who already offshore and are weighing a move closer.
- Nearshore development teamA dedicated group that owns delivery end to end, from architecture through production support.
- CTO as a servicePart-time senior technical leadership, to arbitrate without a full-time hire.
- Managed IT and cloudCloud, pipelines, domains, mail and access, held by the team that also knows the code.
- Cloud migrationInventory, batched cutovers and a tested rollback, so the move does not depend on luck.
- Infrastructure as codeEnvironments described in code, reviewed and rebuildable, instead of configured by hand once and never again.
- AI and chatbot engineeringModels integrated into software that has to run, with a straight answer on what will not work.
- Shopify developmentFor Shopify stores that have to talk to an ERP, a stock system or a payment flow.
