Mulya: Making Cost a Design Variable You Can See

I spent about a decade moving between manufacturing, robotics, sourcing, and machine learning, including international PLM, ERP, and CRM integration work.

Across all of it, one pattern kept repeating.

Cost is a design variable. But it gets decided too late, and it gets explained too little.

By the time a number lands on a part, it usually arrives as a single figure from a quoting portal or a supplier email. No range. No reasoning. No way to ask why.

So you negotiate in the dark, or you accept the number and move on.

That always bothered me. Cost is not a verdict handed down at the end. It is a consequence of geometry, material, process, region, and quantity. Those are design choices. They should be visible while you are still making them.

That is the idea behind Mulya. Mulya is Sanskrit for value, or worth. It is live now: Try it → mulya.vayuai.ai

What it is

Mulya is a manufacturing cost-intelligence tool.

You describe a part: a material, a process route, a few dimensions, a quantity, a region. Mulya returns a should-cost range, low, base, and high, and it shows you the full breakdown behind that range.

No CAD upload. No supplier. No quote request. You do not need a drawing or a vendor to start thinking about cost.

That is the part I cared about most. The commercial should-cost tools are genuinely powerful, but they are expensive and gated. aPriori, Siemens, and FACTON live inside enterprise licenses. The instant-quote sites (Xometry, Protolabs, Fictiv) are excellent at what they do, but they hide their math, and they need CAD plus a supplier relationship before they will tell you anything.

I wanted something different. Neutral, public, and intent-first. A tool where you describe the intent of a part and immediately see what it should cost and why.

Cost as a design variable, not a black box.

It is a static React app: Vite, React, TypeScript, Tailwind, lucide icons. The whole thing runs in the browser, which means it is free to host and free to run. The deterministic cost engine is a pure function. The cost rules live as versioned, source-tagged data. That separation matters later, because it means a backend for accounts and calibration can be added without a rewrite.

Five jobs

Mulya does five things, and they map to how cost actually shows up in a project.

Estimate. Give it a part and a quantity and a route, and it returns a low, base, high should-cost range.

Explain. Every line item carries its own formula and inputs. Click any line and it expands into the trace: the numbers that went in, the math that was applied, where each input came from. Nothing is asserted without its reasoning attached.

Compare. Put scenarios side by side. Material versus material. Route versus route. Region versus region. Quantity versus quantity. The deltas are shown directly, so a sourcing decision becomes a visible trade instead of a guess.

Challenge. Paste a supplier quote and Mulya normalizes it into buckets, hands you a missing-assumptions checklist, and auto-generates the questions you should ask that supplier. This is the negotiation tool. It does not tell you the supplier is wrong. It tells you what they did not say.

Improve. A rules-based recommendation engine looks at the part and suggests changes. Each suggestion carries four things: an impact in dollars, a confidence, a trade-off, and a do-not-do guardrail. The guardrail is deliberate. A recommendation that only tells you what to do, and never what not to do, is not advice. It is a sales pitch.

How it actually works

The core is a deterministic engine. Given the same inputs, it returns the same numbers, every time. No randomness, no model in the hot path deciding what a part costs.

There are six route families, and each one is a real process model, not a curve fit.

CNC machining is driven by material removal rate. Harder, tougher materials cut slower, so they cost more time, so they cost more money. The machinability of the material feeds directly into the cycle.

Sheet metal is driven by cut speed. Mulya carries real fiber-laser cut-speed tables by thickness, and waterjet rates by thickness, with per-material multipliers. A 6 mm stainless plate and a 6 mm aluminum plate do not cut at the same speed, and the engine knows that the way a shop floor knows it.

Weldments are driven by weld deposition rate. Different welding processes lay down metal at different rates (a submerged-arc process deposits far more per hour than a TIG process), and filler cost varies by alloy. The engine prices the joint from deposition physics, not a flat per-weld guess.

Injection moulding is driven by cooling time, and cooling time scales with wall thickness squared. That single physical fact dominates moulding economics, and it is in the model explicitly, alongside machine cost per ton of clamp force and the tooling amortized across the run.

Additive is driven by build time, which comes from throughput in volume per hour for each process, plus powder or polymer cost and a waste fraction.

Simple assemblies include the parts that are cycle-time-bound for their own reasons. Rubber parts, for instance, are cure-bound: the cycle is set by how long the material has to stay in the mould to cure.

Every route produces a low, base, and high. And every line in every route exposes its formula. That is the whole point. You are not meant to trust the number. You are meant to be able to interrogate it.

The data layer is the honest part

A cost engine is only as credible as the numbers it stands on. So I made the numbers the most transparent thing in the app.

Under the engine sits a versioned, source-tagged seed library: around 25 metals, around 16 plastics and rubbers, 6 regions (each carrying a rate index, labor, electricity, freight, duty, and markups), finishes and heat treats, and intent-first archetypes so you can start from a kind of part rather than a blank form.

Every one of those numbers was seeded from free, public references. Wikipedia, MakeItFrom, SteelNumber, published machinability charts, CustomPartNet, Engineers Edge, DFMA guides, the Protolabs and Fictiv design guides, the Reshoring Institute, Eurostat, PlasticsNews, and government parametric handbooks.

No paid database. Not one.

And here is the rule I held to: every number is an editable default with a source tag. Mulya has a Data Sources page that shows what feeds each value and whether that value is sourced or estimated. If a number is a credible published figure, it says so. If a number is my own seed estimate, it says that too, plainly.

I want to be honest about what this is. The seed data is a credible starting point. It is not a calibrated database tuned against thousands of real quotes. The value is not that the numbers are perfect. The value is that every number is visible, sourced, and editable. You can see it, you can see where it came from, and you can change it to match your own reality.

The AI layer never owns the numbers

There is an optional AI feature, and its boundary is strict.

It is called AI Describe. You type a plain-English description of a part, and it turns that sentence into a structured estimate input: it fills the form. That is all it does.

It runs through a server-side, free-first LLM fallback chain: Cerebras, then Mistral, Groq, NVIDIA, Gemini, OpenRouter. The keys live server-side and never touch the browser. As soon as one provider returns usable output, the rest are skipped, so the whole thing runs on free tiers.

But the deterministic engine still owns every single number. The language model is a translator from English to a structured form. It does not estimate cost. It cannot. The moment a part description becomes a structured input, the AI is done, and the pure function takes over.

That separation is not an accident. An AI tool that quietly invents cost numbers is exactly the black box I was trying to get away from. The LLM is allowed to help you describe a part. It is not allowed to decide what that part costs.

Live data, when you want it

Material prices move. A should-cost number anchored to last year's copper price is wrong in a specific, knowable way.

So Mulya has an optional live commodity feed through FRED. Copper, aluminum, nickel, and zinc, in USD per kilogram, with 24 months of history. When it is on, each metal grade's cost is scaled by live-over-baseline: the engine takes today's price relative to the baseline it was seeded with and adjusts accordingly.

You turn it on by pasting a free FRED key into the Data Sources tab. With no key, Mulya shows clearly flagged baselines instead. It never pretends a baseline is a live price.

An honest note on limits

These are should-cost ranges. They are built for design decisions and supplier negotiation. They are not quotes.

A quote comes from a specific supplier, with their machines, their overhead, their schedule, and their margin. Mulya does not know those things. What Mulya gives you is a defensible, transparent estimate of what a part should cost, so that when a real quote arrives, you have something to measure it against.

The seed data, again, is a credible starting point, not a calibrated database. I would rather say that clearly than dress it up. The engineering credibility of a tool like this comes from knowing exactly where the boundary is.

What I will stand behind is the transparency. There is no hidden number in Mulya. Every value is on screen, tagged with its source, and editable to match what you actually know.

The workspace

The app is a three-pane workspace: inputs on one side, the cost model in the middle, the intelligence (compare, challenge, improve) on the other.

Scenarios can be saved, compared, and shared by URL, so a cost conversation can be sent to a colleague as a link rather than a screenshot. There is a print-to-PDF report for the cases that need to leave the browser and land in a meeting. And there is an in-app Architecture page, because a tool that asks you to trust its math should be willing to show you how it is built.

The whole thing wears the VayuAI house style: a warm-paper light theme, Fraunces and Inter for type. Calm, readable, not a dashboard screaming for attention.

Where it goes next

Mulya today is intent-first by design. You describe a part. The next layers make it geometry-aware and supply-chain-aware without losing that transparency.

The roadmap:

• CAD and STEP upload with feature recognition, so a model can seed the inputs instead of a form.
• PDF drawing ingestion, to pull intent straight from a drawing.
• Deeper live commodity feeds, beyond the current four metals.
• ASTM and ASME standards-grounded materials, with a mill-to-stock-form-to-operations flow that simulates the real supply chain: how a grade is specified, what form it is bought in, and how it is processed into a part.
• A Postgres and FastAPI backend for accounts, team workspaces, and calibration against logged quotes.

That last one is why the engine is a pure function and the rules are versioned data. Calibration is the thing that turns a credible seed estimate into a trustworthy one. When real quotes can be logged against real estimates, the seed numbers stop being seeds. The architecture is already shaped to allow that without a rewrite.

Why I built it

I have watched cost get decided too late and explained too little for my entire career in this field.

A requirement becomes a design. A design becomes a part. A part becomes a quote. And somewhere in that chain, cost stops being a thing you can reason about and becomes a thing that simply happens to you.

Mulya is my attempt to move that conversation earlier, and to make it legible. To let an engineer ask, while the design is still soft, what does this actually cost, and why, and what would change it.

Not a black box that hands down a verdict.

A glass box you can argue with.

The most useful number is not the one you are given. It is the one you can take apart.

Try Mulya live →