HEPHEX›ABOUT

HEPHEX // ABOUT US

We did not start
in a meeting room.

Hephex was born inside a working metalworking shop, the one owned by the founder's family. Nobody started from a requirements list or a market study: the software grew up next to the machines, solving problems that were costing money that week.

Nothing gets built without a real problem to justify it.

That has been the rule since day one. It explains what Hephex does, and what it refuses to do.

THE ORIGIN

A real shop floor

Where the software came from

Quotes built in a spreadsheet and rebuilt from memory. Deadlines that only surfaced once the client rang up asking. Parts on the floor whose status depended on finding the right person to ask. Money leaking away in places nobody could point to.

That is not a scenario invented for a slide: it was daily life in our family's metalworking shop, and Hephex started being written to fix it. Every module that exists today began as a concrete friction, seen on that floor.

  • Built beside the people producing, not at a distance
  • Tested every day on a genuine operation
  • Every feature came from a problem with a cost attached
THE DOUBLE DEMAND

Serving one company and serving many

Why there is a core and there are modules

From the start the software carried two demands at once: it had to fix that shop today, with everything particular about it, and it had to serve other companies tomorrow without being rewritten from scratch.

That tension is where the core-and-modules architecture comes from. The core is what any production needs. The modules are what each company picks. And the customisation, which runs from business logic to the size of the buttons, is what lets the same software settle into operations that look nothing like one another.

  • One mandatory core, nine catalogued modules and whatever else you need
  • The adaptation happens in the process, not in a settings window
  • See what gets customised →
WHAT WE BELIEVE

Five convictions

What decides when the answer is not obvious

These are not values for a wall. They are the rules we use to decide what goes in and what stays out, and each one has already cost us at least one feature that looked like a good idea.

  • The simplest solution that fixes the problem wins. Ease of maintenance beats impressive technology
  • Nothing enters without a real flow to justify it. The why always precedes the how
  • Numbers are explicit and open to audit. The margins are yours and you can see all of them, with no black box setting prices
  • The data belongs to whoever produced it. It stays wherever the software runs, with native backups, and it leaves with you
  • Saying no is part of the job. Software that accepts everything ends up serving nothing well
THE BOUNDARIES

What Hephex does not do

And not for lack of thinking about it

This list is kept on purpose, and it gets said before the sale rather than after. A supplier who says they do everything is setting up a disappointment, and we would rather you knew where the limits sit now.

  • It does not issue certified invoices and does not do accounting. It records payment terms and real costs, and integrates with the invoicing software you already use
  • It does not quote automatically with artificial intelligence. The calculation is yours, with margins you apply and understand
  • It does not schedule production for you. It shows you real capacity and the delays coming; the person who runs the company decides
  • It is not a generic ERP. It is a production tool, and that is where it wants to be the best
HOW WE WORK

Proof before proposal

The process, in two sentences

The first step is always showing the real system working, with real processes and production data, and with no commitment. Only then come the conversations with management and with the people at the machines, the diagnosis and the plan.

No proposal is written before we understand how your production works. And the diagnosis also says, where it applies, where you need no software at all.

  • Seven steps, always in the same order, whatever the sector
  • Delivery means working software and people trained on it
  • See the process in depth →
FREQUENTLY ASKED

What people ask us before the first meeting

What is Hephex?

Hephex is production management and optimisation software built to the measure of each company. It has a mandatory core (dashboard, clients, projects, work items, transitions, process stages and member permissions) and grows with the modules it needs: nine are already in the catalogue, and whatever else is missing gets built to order.

It does not come off a shelf: every installation follows the client's own operation. See what gets customised.

Which sectors is Hephex for?

Any sector with production. Fitting practically any industry is not a vague promise: it follows from building each system to measure rather than limiting it to a single model.

It is in step 05 of the process, the build, that proven modules are shaped to each client's flows and terminology.

Where does the data live? Does it run in the cloud?

It runs wherever the company chooses: on a local server, for those who would rather keep everything in-house, or hosted online, for those who need integrations and connections to other software. The choice is yours and it can change later.

The data stays wherever the software runs, with native backups. It never passes through any cloud of ours, and if you ever move on, you take the database with you.

Does Hephex issue certified invoices?

No. Hephex does not issue certified invoices and does not do accounting.

The Invoicing module records payment terms and the real history of invoicing and costs, and can integrate with the invoicing software you already use, among other services.

What does the initial setup deliver?

The licence, the development and implementation of the software, on-site installation, the configuration of stages and permissions to the measure of the operation, every meeting in the process and training for your teams.

What does ongoing support include?

Software updates, tuning and debugging of what has already been delivered, support for questions, and improvement meetings.

The support time included tracks what there is to maintain: it grows with the number of active modules and with the number of users at the company.

Can I add modules later?

Yes, at any time. They join the same core and the same database, as if they had been there from the start, with no patch bolted onto the side of the system.

What are the Ember, Flame, Furnace and Fusion tiers?

They are the four complexity tiers that classify each module, named after the rising heat of a forge. The more a module touches the rest of the system, the higher the tier.

Ember only stores data and information. Flame already has rules and menus of its own, and runs simple calculations or raises alerts. Furnace cross-references several modules and influences production. Fusion connects to everything else, with fundamental calculations or deep functional logic.

How does the process start?

With a demonstration of the real system, using real processes and production data, and with no commitment. Only afterwards come the conversations with management and staff, the diagnosis and the plan.

No proposal is written before we understand how your production works. See the seven steps.

What if I need a feature that does not exist yet?

We build it. It comes in as a new module, placed in one of the four tiers according to how much it touches the rest of the system.

It is built on the same core and the same database, never as a patch bolted on beside the system. If it can be imagined, Hephex can build it.

Still unanswered?

Write to us and we will answer. If what you want is to see the system working, that is the shortest answer there is, and it is the first step of the process.

geral@hephex.pt
← Back