Custom solutions

Some problems are not software problems.

Storage that outgrew its subscription. A gate with a queue at it. A factory floor with no way to see itself. These get solved with hardware, storage and platforms that already exist, assembled until they behave like one system — and we say when the honest answer is “you do not need this”.

In short

What non-software solutions does ZYNTEIRO provide?

ZYNTEIRO assembles systems out of parts that already exist, where writing an application would be the wrong answer: Nextcloud private cloud storage for firms whose data grows faster than their headcount; facial recognition, attendance and access-control hardware, specified, supplied and installed; telemetry walls and floor displays that give a plant a way to see itself; and integration between systems never designed to talk to each other, including into Odoo, which we operate as zynAIR.

Areas

Three of these, each written up properly.

Every one has a full guide or case study behind it, including the section on when not to buy it.

How we decide

Three questions we ask before quoting anything here.

Most disappointing IT projects fail one of these and nobody asked it out loud.

01

Does the data already exist?

If it does, you are buying a screen or a pipe — weeks. If it does not, you are buying a data-collection programme first, and the visible part is the small part. Most disappointing IT projects are this question, unasked.

02

Who is accountable afterwards?

On-premise storage, a local AI server and a biometric terminal all work beautifully for eighteen months without an owner, then fail on the day it matters with nobody watching. If the answer is a shrug, buy the subscription instead.

03

What decision changes?

If nobody can name a decision that gets made differently, faster or earlier, it is decoration. Decoration is a legitimate purchase. It should be a knowing one.

Questions

Before you call.

Who writes the parts. On a software project we write the thing itself and you own the source from the first commit — that is software development. Here the parts already exist: a storage platform, a terminal, a controller, a display, an ERP that is already running. The work is choosing them, specifying them, installing them and wiring them together until they behave like one system, and the deliverable is that system rather than a repository. Many jobs contain both, and the quote separates them so you can see which half you are paying for.

Both, and you can buy either. We will specify to a written requirement and let you purchase it yourself, or supply and install it ourselves — and we will tell you plainly what our margin structure is on request. What we will not do is lead with a product, because the product is rarely the deliverable. The record it produces, and what that record is wired into, is.

Usually, and it is a large part of what this practice is. The realistic constraint is not our end, it is whether the system on the other side exposes anything to talk to — a documented interface, a database we are allowed to read, an export on a schedule. Where it does, integration is ordinary engineering. Where it genuinely does not, the honest options are a scheduled file exchange, replacing that system, or living with the manual step, and we will say which rather than promising a bridge that does not exist. Where the system in question is Odoo, it is one we operate as zynAIR and the answer is almost always yes.

Then that is the answer and we will put it in writing. The three questions further up this page are the ones that decide it, and the most common outcome for a project that fails them is that a subscription, a process change or nothing at all beats the build. That conversation costs us nothing and saves you a purchase, which is a trade we will take every time.

Describe the problem, not the product.

Tell us what is going wrong and who it affects. If the answer is something we do not sell, we will say so — that conversation costs us nothing and saves you a purchase.