Prasinus AI & software for manufacturers
Index
Contact

AI and custom software for manufacturers.

We find where AI gives a return in your factory, build the system, and put it into production. Your team keeps the source code.

Email us Run the deployment check

We reply within one business day

AI adoption

Quality inspection, predictive maintenance, production schedules, and document and quote work. The system runs where your IT group and your auditors agree.

App development

Internal tools, dashboards, and customer portals. We connect them to the ERP, MES and historian systems that you operate.

What we do.

Each factory is different, so this list is general. In the first call, we look at your process and find where the work has value. We tell you when a task is new to us.

  1. 01

    Quality inspection

    Automatic inspection on the line. Doubtful parts go to a person for review.

  2. 02

    Predictive maintenance

    The system reads the data that your equipment already produces, and reports a change before the failure.

  3. 03

    Production scheduling

    Schedules calculated from your routings and your constraints, fast enough to compare alternatives.

  4. 04

    Documents, knowledge & quoting

    Systems that read your SOPs, records and RFQs, and give each answer with its source.

  5. 05

    ERP & MES integration

    Connections between the systems that you already operate: ERP, MES, historian, or an old SQL server.

  6. 06

    On-prem & air-gapped AI

    AI on your hardware, with no connection out of the building, for the data that must stay on site.

App development.

We scope the work and document it, so that the next person can maintain it. We use AI where it makes us faster. One person reviews every line.

  1. 01

    Internal tools & dashboards

    The work that your team now does in a shared spreadsheet.

  2. 02

    Customer & supplier portals

    Order status, drawings, certificates and RFQ input, with an audit record that your quality system accepts.

  3. 03

    Legacy replacement

    The old database or the application that no person maintains. We replace it in stages, and the old system stays in operation until the new one is stable.

How we work.

We work in short phases. Each phase ends with a document that you keep, even if you stop after it.

  1. 01

    Assess

    We walk the floor and speak with the operators. Then we put the candidates in order, by return and by risk. This takes one to two weeks.

    You keepThe written, ranked opportunity list

  2. 02

    Pilot

    One problem with a defined scope, and one success measurement agreed in writing before we start. The pilot operates on real data. This takes four to eight weeks.

    You keepThe running pilot and the evaluation set

  3. 03

    Deploy

    We make the system ready for production. We connect it to the ERP, MES and historian. We add monitoring, we record the failure modes, and we train the operators on their shift.

    You keepRunbook, monitoring and the failure-mode list

  4. 04

    Hand off

    Your team operates the system. The source code, the documentation and the training are part of the price.

    You keepThe repository and the admin credentials

These durations are our estimates. If a phase needs more time, we tell you in that week’s note. Assess and pilot have a fixed price and a fixed scope. For deploy, you choose a fixed price or time and materials.

Read the full method Entry and exit criteria for the four phases, the documents in full, and the questions we ask in each. Published under CC BY 4.0.

Where it runs.

On your hardware, in your own cloud, or through a managed API. If the data cannot leave the site, the system runs on your hardware.

We work in all three modes and tell you which one your constraints permit. Sometimes the correct answer is the managed API.

Table 1 — Deployment modes compared
Property On-prem Self-hosted Managed API
NetworkNone. The line can be air-gapped.Your VPC, no public ingress.Egress to the vendor.
Process data leaves siteNo.To your own cloud account.To the supplier, under a data-handling agreement.
Model classOpen-weight.Open-weight.Frontier, plus open-weight.
HardwareYour GPUs, on your floor.Your cloud GPUs, reserved.None.
Cost shapeCapex, then flat.Opex per reserved hour.Opex per token.
Audit evidenceA network diagram with no arrow out of the building.VPC flow logs and IAM policy.The contract and the DPA.
First deployment6–10 weeks4–8 weeks2–4 weeks
Typical fitIP-sensitive processes, ITAR work, and lines that must operate when the WAN fails.Several sites, and a cloud account already in place.Documents: quotes, SOPs and work instructions. These already leave the building.
RiskNo person owns the hardware. When an accelerator fails, your team must repair it.No person owns the bill. A reserved instance continues to cost money after the pilot ends.The vendor changes the model. Without a written evaluation set, you cannot prove the change.

These durations are our estimates for one first use case. They assume hardware already on site or a reserved instance already approved, and one named process owner.

What “open-weight” means on this page

The licence permits three things. You can download the weights. You can operate them on your own hardware. You can continue to operate them if the supplier changes its plan.

What “pinned to a version hash” means

We record each model that we deploy by the checksum of its weight file, because names change.

Which one fits your factory?

This is the first ten minutes of a scope call. Answer for one process. “Not sure yet” is a valid answer. The page sends no data.

01 Can process data leave the site?
02 What is the network on that line?
03 Where would the GPUs come from?
04 Who has to sign off?

Readout — recommended deployment

On-prem

Data egress
None
Hardware
Yours, on your floor
Weights
Open, pinned to a version hash
Ruled out
Managed API and self-hosted

Recommended. Open-weight models on machines inside your firewall. The process data stays inside a boundary that an auditor can verify.

You do not know yet what the line can reach. On-prem works without that answer. Get the answer anyway, because it decides the other two modes.

The air gap decides this. Updates arrive on physical media, with a documented offline procedure.

A segmented VLAN could host this too, but each egress exception must be approved again at each audit. On-prem needs no exceptions.

The network would allow the other two modes. A different answer, about the data or the assessor, rules them out.

Nobody has priced the hardware yet, so the assess phase ends with a quote. One 48 GB accelerator for each line is the usual start.

You already own the accelerators. We size the model to that hardware.

Reserved cloud instances do not help here. The data must stay on site, so the compute must also stay on site.

No hardware and no data egress is the hardest combination. A small open-weight model on CPU is slow but possible. Start there, measure, then decide whether to buy hardware.

Full spec for on-prem ↑

Self-hosted

Data egress
Into an account you own
Hardware
Yours, or reserved by the hour
Weights
Open, pinned to a version hash
Ruled out
Managed API

Recommended. Open-weight models in a cloud account that you control, with your keys and your flow logs. Your answers permit process data to go only to infrastructure that you own.

You do not know yet what the line can reach. If the answer is air-gapped, this becomes on-prem. The rest of the plan stays the same.

Egress by exception fits this mode: one route, to one account, logged. The exception is written once.

An ordinary corporate network makes this quick to set up. The inference subnet gets its own security group before the pilot starts.

No person has priced the accelerators yet. Rent them by the hour until you know the workload. Reserve the instances when the workload is stable.

You already own accelerators, so a cost for each token is expensive. Keep an API contract only for work that needs a frontier model.

Reserve before you buy. You can return a reserved instance. A purchased machine depreciates for years.

You would rather not own accelerators. A reserved instance is rented by the hour, and you can return it.

Full spec for self-hosted ↑

Managed API

Data egress
To the supplier, under a data-handling agreement
Hardware
None
Weights
The supplier hosts them. The version can change.
Ruled out
Nothing yet

Recommended. Frontier models under a data-handling agreement, with an evaluation set, request logs that you can read, and a cost limit set before the first call. Nothing in your answers requires hardware.

Your answers do not rule this out, but nobody has checked the network. Ask before the pilot. An air-gapped line changes this answer to on-prem.

An ordinary corporate network needs one firewall rule and no purchase order. Nothing here is permanent, and that is the reason to start here.

Nobody has priced accelerators, and you do not need to yet. First find out whether the system has value. You can decide on hardware later, with a real token bill as data.

No accelerators and no operators is a correct answer. This is also the cheapest way to find out if the system helps you.

Full spec for managed API ↑

The check runs in CSS in your browser and sends no data.

Tell us about your factory.

Tell us about one process and the problem it causes. The first call is free and technical.

We reply within one business day