Concepts
A Jump Start, Not A Finished Answer
An accelerator is a pre-built, configurable starting point that addresses the bulk of the common challenges companies in its domain typically face. It is not intended to solve every possible variation of every problem off the shelf — and understanding that distinction up front is what makes one succeed.
The definition
What An Accelerator Is, And What It Isn't
If your requirements fall outside what an accelerator describes, that is expected and normal for the model — not a shortcoming of that accelerator.
It is a functional solution
Production-ready and built to be used in live operations from the day it is installed. Not a demo, a proof of concept, or a sandbox exercise.
It is a starting point
A solid foundation most implementations can configure — and where needed extend with custom development — to reach their more unique requirements.
It is yours once installed
Installation forks the flows, models and screens into your environment as your own configurable copies. It is not a live link back to the published accelerator.
It is not off-the-shelf software
Off-the-shelf products are built to a fixed, average-case spec. Fast to stand up, but the business has to conform to the software — and when the business changes, the software does not move with it.
It is not complete for everyone
It addresses the bulk of common challenges, deliberately. No accelerator anticipates every process, product mix, compliance regime or scale.
It is not auto-updating
Once installed, later versions published against the accelerator do not propagate to you. Picking up a change means deliberately re-applying it against your branch.
The reasoning
Why An Accelerator Rather Than A Product
Because operational challenges are not static.
A company's processes, product mix, compliance requirements and scale all evolve — often within the first year of using a new system, and continuously after that. That is why off-the-shelf tools tend to function as a short-term fix for what is usually a longer-term operational challenge: they solve today's problem, then become the constraint on tomorrow's.
The accelerator model is built to avoid that trade-off on three counts:
- Immediate functional value. Like an off-the-shelf product, it delivers working capability from day one. It is not a starting-from-zero build.
- A configurable foundation, not a fixed one. Because it is delivered on the Fuuz® platform's low-code and no-code tools rather than as closed, packaged software, the capability that ships on day one can be adjusted — and extended — as requirements become clearer, without waiting on a vendor's product roadmap.
- Yours to evolve. You are not asking a vendor to update a shared product for your specific case. You are shaping your own instance as your operation actually changes.
In short: the fast start of an off-the-shelf solution, without inheriting its long-term rigidity — because a system that cannot change with the business tends to become the next problem rather than the solution to the current one.
Scope
Every Capability Sits In One Of Three Tiers
This is the vocabulary to use when deciding whether a requirement is covered, configurable, or a scoped piece of work.
| Tier | What it means |
|---|---|
| Standard | Delivered and working as-is. No configuration needed. |
| Configurable |
Delivered as a base capability you or your partner adapt with platform tools already included — screen builder, JSONata transforms, workflow rules, data flow parameters — without engaging professional services. |
| Custom development | Technically feasible on the platform but outside the accelerator's current scope. A scoped change through Fuuz or a certified partner. |
"Configurable" does not mean unlimited
It means the platform's existing no-code and low-code tools can achieve the change without a code-level extension. If a requirement cannot be met by adjusting parameters, filters, layout or workflow rules within the accelerator's existing objects, it is custom development — not configuration.
Anatomy
How An Accelerator Is Built
Every accelerator is the same kind of thing underneath: Fuuz platform components, packaged.
Data models
The records the application keeps — work orders, containers, inventory, quality specifications. The shape of the domain.
Data flows
The logic. Most are screen-bound: a request arrives from a button, queries fetch supporting records, rules branch, a mutation writes, a response returns.
Screens
What operators and administrators actually use — control panels, tables, forms, dialogs and management screens.
Document designs
Printable output: labels, manifests, reports. The paper the floor still runs on.
Modules
Components are grouped into modules by function — receiving, picking, quality, control panels. A module is the unit you reason about.
The package
All of it ships as one .fuuz archive. Some accelerators are also published
modular — the same package unpacked module by module, so it can be read
and diffed before anything is installed.
Lifecycle
How An Accelerator Is Used
- Evaluate before installing. Read the technical overview and the build reference. Where an accelerator is published modular, read the modules themselves.
- Scope honestly. Each accelerator's guide carries a discovery questionnaire. A "no" is not a defect — it marks where that accelerator's standard scope ends for your situation, and what to log for custom scoping.
- Install. The package is imported into a tenant, forking its flows, models and screens into your environment as your own copies.
- Configure. Most accelerators ship deliberately empty of status and reference data, because those values are specific to an operation. Site structure, product and process data, and access control come next.
- Verify end to end. Walk one real transaction through before going live.
- Extend where it matters. Anything in the custom tier is scoped work on top of a foundation that already runs.
Who publishes accelerators
Accelerators may be published by MFGx (the Fuuz platform team), certified partners, customers, or any party with access to a Fuuz environment. Support, warranty and maintenance terms differ by publisher — each accelerator's own guide states which apply.
Expectations
What This Model Asks Of You
The accelerator model works when both sides understand where the line falls. It fails when an accelerator is treated as finished software.
Expect to configure
An accelerator that shipped every status value, location and product pre-filled would be wrong for every operation that installed it.
Expect gaps, and name them early
Requirements outside the standard scope are normal. Surfacing them during scoping is far cheaper than discovering them during go-live.
Expect to own it
After installation the branch is yours, including the decision about whether and when to take a later version's changes.