Hconsul came out of a simple observation, formed over {{ANNEES_EXPERIENCE}} years on complex enterprise systems: most software projects do not fail for lack of technical skill. They fail because nobody took the time to understand the problem before proposing a solution.
We built this company to work differently.
The founder of Hconsul spent {{ANNEES_EXPERIENCE}} years designing and evolving enterprise systems — {{CONTEXTES_TECHNIQUES}}. Long enough to watch the same situations repeat, in organizations that had almost nothing else in common.
None of these came from incompetence. They came from distance: between the person selling and the person building, between the person deciding and the person who will live with the decision, between what a contract says and what actually happens in production.
Hconsul exists to remove those intermediaries. The engineer who analyzes your problem is the one who builds the solution. There is no salesperson who promises, then a project manager who translates, then a developer who discovers. There is one person accountable from start to finish — and therefore one person to hold to account.
That imposes a limit we accept: we cannot absorb any volume. We would rather turn down an engagement than hand it to someone who would not understand it.
We are not a large consulting firm and we are not trying to look like one. We have no client references to display, no activity figures, no logos on a home page. For some needs — a fifty-person programme, an international rollout — an established firm will serve you better, and we will say so.
What we bring is different: genuinely senior technical expertise, a decision settled in conversation rather than in three weeks, and written commitments that protect you better than a reputation does.
Technical skill can be verified in a few hours. How someone behaves when a project goes wrong takes months. We would rather write it into the contract on day one.
Three verbs, in that order, because each one determines the next.
The quality of a system is decided before the first line of code. Understanding the business, identifying the real constraints, choosing a structure matched to the actual complexity: it is the least visible work and it determines everything else.
A system that works in a demo and collapses in production has achieved nothing. We write code meant to be read, picked up and changed by others, tested where risk justifies it, and shipped in small increments so gaps show early.
Software is never finished. What separates a system you improve for ten years from one you throw away after three is not its technology: it is how easily you can change it without breaking it.
This is the only criterion that really counts. Not the elegance of the architecture, not how modern the stack is. The question is whether the system holds when load rises, whether the team dares change it on a Friday, and whether it will still be maintainable once we are gone.
We are not aiming for size. We are aiming for a precise position: the supplier you call again two years later for the next problem, because the last one went well and the system still holds.
Building our first references on projects where our standard makes a measurable difference, and documenting them honestly — including what did not work.
Assembling a small network of senior engineers who hold the same standard. We would rather decline an engagement than place someone who is not at that level. That constraint caps our growth; we accept it.
Contributing what our industry is short of: transmission. Publishing what we learn, sharing what we run into, including the technical decisions we regret. Software consulting has a candour problem; we would rather go the other way.
Every company advertises values. They only mean something if they forbid something. For each one, we state what it costs us.
What it means
Code written to be read by someone else. Tests where risk justifies them. Architecture decisions documented with their reasons, so they can still be understood in two years.
What it rules out
Shipping something that works but that we would not be willing to maintain ourselves. Accepting a deadline that only holds by sacrificing quality — we propose cutting scope instead, never rigor.
What it means
What is announced is delivered. When a difficulty appears, it is raised the day we find it, not at the end-of-month review.
What it rules out
Absorbing a problem quietly and hoping to catch up. Bad news raised early stays manageable; raised late, it becomes a crisis.
What it means
We test, we read, we get things wrong on our own projects rather than on yours. A technology only interests us once we understand which problem it solves and which one it creates.
What it rules out
Introducing a technology into your system because it interests us. Innovation paid for in maintenance debt is not innovation, it is a risk transfer to you.
What it means
A reasoned technical opinion, including when it contradicts the request. We will tell you if your project does not need the means you are considering, or if another supplier is better placed.
What it rules out
Selling work we doubt the usefulness of. Billing for complexity we introduced ourselves. Withholding anything that would make you reconsider our involvement.
What it means
We adopt your tools, your rituals and your standards where they work. The engagement model adapts to your organization.
What it rules out
Imposing our method on a team that has its own. When we suggest changing a practice, we explain why and you decide.
Six concrete differences, stated so you can check them.
Years of engineering on complex systems. You are not funding a learning curve on your project.
We choose the simplest solution that holds up over time. An oversized architecture costs twice: once to build, then again at every change.
No catalogue of offerings to move, no consultants to place. The engagement fits your need, including when that earns us less.
No layer between you and the engineer. What you ask in the morning does not need three relays to be understood.
A technical call is settled in conversation, not in committee. That is the structural advantage of a small organization, and it disappears with size: we are using it while it lasts.
Time-and-materials or fixed price, short engagement or long-term support, fifteen days’ notice. You are committed only for as long as the arrangement serves you.
Four principles that govern our technical decisions. They explain what you will get from working with us better than any statement of intent.
Given two options that answer the need, we take the simpler one — even when the other is more interesting to build. Complexity is a recurring cost: it is paid at every new feature, every new joiner, every production incident.
Performance assumptions are almost always wrong. Before touching a slow system, we instrument it. The real cause is rarely the one everyone suspects, and optimizing the wrong place adds complexity for nothing.
Some choices are hard to undo: a data model, a boundary between domains, a cloud provider. We identify those early and give them the time they need. The rest we decide quickly, ready to correct — deliberating at length over a reversible choice costs more than getting it wrong.
Every structural decision is recorded with its context, the options discarded and why. That document serves your team once we are gone — and it serves us six months later, when we have forgotten why we chose as we did.
Hconsul is a young company. What follows describes not an established culture but the working principles we apply from day one and build on.
Every engagement opens with workshops with your business and technical teams, reading the existing code and reviewing past incidents. We do not write a line before the problem has been restated in writing and you have agreed with that restatement.
Regular technical watch, experiments run on our own projects, past choices reopened. An engineer who stops learning loses their edge in three years.
Documentation, shared code reviews, skill development in your team. We aim for you to be able to do without us. That is commercially counter-intuitive — it is also why people call back.
We will make some. What matters is the delay between the mistake and telling you about it. We prefer a difficult conversation in week three to a crisis in week twelve.
A successful engagement is not a billed engagement. It is a system in production doing what it should, a team able to maintain it, and a client who calls back for the next problem.
Our path is not fast growth. A consulting firm that grows faster than its ability to hire at the right level mechanically degrades what it sells. We would rather turn work down.
Our first delivered work, with clients willing to work with a young firm in exchange for contractual commitments better than the market offers. Those terms will not last; they are how we make up for having no references.
A small network of experienced engineers who hold our standard. The selection criterion is not availability but level: we would rather decline than place.
A more honest practice of software consulting. Publishing what we learn, mistakes included. Saying no when it is warranted. Writing commitments we keep rather than promises nobody checks.
Our first clients will not be lines in a reference list. They are the ones who will make this company exist. We will keep that in mind at every decision.
You have a project to launch, an application blocking you, an architecture decision to settle or a team to reinforce. Describe your situation: we answer with an analysis, not a brochure. You leave with our written reading of your problem, whether or not you continue with us.
Hconsul · Île-de-France · RCS Nanterre 994 546 828 · {{EMAIL_CONTACT}}