Custom AI Video Analytics: Builds from 2 to 128 Channels
The three standard packages cover most single-site deployments. They stop being the right answer at a predictable point: when you need more than six cameras on one appliance, when the algorithm you need is not in the library in the form you need it, or when the detection has to hand off to something else — a VMS, a barrier controller, a dispatch system, your own product.
This page sets out what a custom build actually involves, what drives the price, and how long it takes. It is written for people who already know they need one, or suspect they do.
When a standard package stops being enough
Standard packages are fixed configurations — 2, 4, or 6 channels, pre-built and tested, shipped as-is. They do not expand: a 2-channel unit cannot be upgraded to 4 later. Four situations take you past them.
| Situation | Why a package cannot absorb it | What a custom build does |
|---|---|---|
| More than six channels | A single appliance tops out at 6 on the standard configurations | Scales to 128 channels per system, with compute matched to the video load |
| A rule the library does not have | The 198+ algorithms cover common scenarios, not your specific one | Scoped and trained against your footage, then held as part of your configuration |
| Integration with another system | Packages ship with the standard alert outputs | API, SDK, or protocol work so events land where your team already works |
| Residency or network constraints | Fixed hardware spec, fixed deployment model | Hardware and topology specified around your network policy and data rules |
If none of those apply, buy a package. It is cheaper, ships faster, and you can always move to a custom build later — with a credit, which we cover below.
What a custom build includes
A custom build is not a different product. It is the same edge appliance and the same analytics engine, scoped and configured against your site instead of a fixed specification.
| Element | Standard package | Custom build |
|---|---|---|
| Channels | 2, 4, or 6 | 7 to 128 |
| Compute | 1 TOPS to a matched fixed load | Sized to your channels and algorithm count, 1–256 TOPS |
| Algorithms | Built-in set, or configured for your site | Scoped to the project, including rules not in the library |
| Camera support | ONVIF / RTSP, H.264 / H.265 | Same, plus mixed-resolution and legacy stream handling |
| Integration | Standard alert outputs | API / SDK / protocol work as scoped |
| Branding | Our product | White label available — see OEM & white label |
| Price | Fixed, published | Quoted per site |
Cameras stay optional in both cases. Most projects reuse what is already on the wall; where a view is missing, an ordinary IP camera is usually sufficient, and we will tell you which ones before you buy anything.
How the scope gets set
Scope is set in conversation, not by a configurator. The sequence below is what most projects follow, and it is the same sequence whether you are an end user, an integrator, or an OEM.
- You send the scenario. Camera count, layout, what you need detected, and what should happen when it fires. A rough site plan is enough to start.
- We tell you what fits. Which of the 198+ algorithms apply to your footage, what accuracy to expect given your camera angles and lighting, and where the honest limits are.
- Validate on your own video. A Starter Kit or a scoped pilot runs against your actual streams. This is the step that catches problems while they are still cheap.
- Confirm the build. Channel count, compute, algorithm set, integration work, and hardware are fixed in writing, with a delivery date.
- Deploy and tune. Thresholds are adjusted against real footage rather than a demo reel, because site conditions differ from anything we can simulate.
Step 3 matters more than it looks. Most disappointed deployments we are asked to rescue skipped it and went straight to a full rollout on a specification written from a datasheet.
What drives the price
A custom build is quoted per site, so there is no price list. Five variables move the number, and all five are things you can influence.
| Variable | Effect on price | What you control |
|---|---|---|
| Channel count | The largest single driver — compute scales with streams | Start with the cameras that cover the highest-risk view, expand later |
| Algorithm count | Each additional rule adds compute load | Run three rules well rather than thirty badly |
| Custom rule development | Scoped separately from the library algorithms | Check the algorithm library first — the rule you want may already exist |
| Integration work | Priced by interface complexity, not by line count | Confirm whether a webhook or an API call satisfies the requirement |
| Hardware and cameras | Reusing cameras removes the largest optional cost | Existing ONVIF / RTSP cameras usually stay in place |
For the arithmetic that sits around these variables — installation labour, phased rollouts, and what a multi-site deployment totals — the AI security system cost breakdown works through it line by line.
Credit for a package you already bought
If you have already bought any of the three standard packages — Standard 2, Standard 4, or Standard 6 — and later commission a custom build, the amount you paid for one of those packages is credited against the custom quote. If you have bought more than one, the credit still applies once, against one package only.
This exists because the sensible path for an uncertain project is to validate small, then scale — and that path should not cost you the price of the validation. Buy a package, prove the detection on your own cameras, and the money you spent is not wasted if you outgrow it.
Timeline
Two things decide the date: whether the build needs new algorithm development, and how much system design, integration, and commissioning work the site contains. We quote the date with the scope rather than naming a number before we have seen anything.
- First working demo — configuration only: about 7 days from receiving your camera layout and scenario. This is the case where the library already has the detection you need, and the work is project design, channel layout, rule configuration, and integration. You get a working configuration running your rules on your streams, not a slide deck.
- First working demo — new algorithm development: quoted with the scope. Training and validating a rule that does not exist yet takes as long as the data and the difficulty of the case require. The honest answer depends on what your footage looks like, so we will not name a date before we have seen it.
- Production delivery: quoted with the same scope document, because it depends on how much custom rule development and integration work the scope contains. Library-only configurations on standard hardware move fastest; new rule development is the long pole.
Both dates are estimates of work, not marketing. If your timeline is the binding constraint, say so at step 1 — it changes what we recommend, and it is better to know on day one than on day thirty.
Who this is for
| You are | What usually drives the custom build |
|---|---|
| A security integrator | Multi-site rollouts, channel counts past six, and your own service wrapper — for integrators |
| An OEM or software vendor | Embedding detection in your product under your brand — OEM & white label |
| An end user with a large site | Coverage across many cameras, or a rule specific to your operation |
| An end user with one or two cameras | Usually not a custom build — we will say so. A Starter Kit or a single smart camera at roughly USD 40 is the honest recommendation |
Custom builds use the same interfaces as the standard product: RTSP (RFC 2326) for camera stream access and ITU-T H.265 for video transport, so a bespoke model still lands on standard hardware.
Common questions
Can I start on a package and upgrade later? Packages do not expand in place — going from 2 to 4 channels means a different package. Moving to a custom build is a separate step, with the credit described above.
Do I have to replace my cameras? Almost never. The appliance ingests ONVIF or RTSP streams in H.264 or H.265, which covers most cameras installed in the last decade. Where a view is missing, one ordinary IP camera is typically all that is needed.
Does video leave my network? No. Processing runs on the appliance inside your network, so footage and alerts stay under your control. If residency is a formal requirement, the on-premise vs cloud comparison sets out what changes.
What if the detection does not work on my footage? That is what step 3 is for. If validation on your own streams does not reach a usable accuracy, you have spent the cost of a Starter Kit rather than a full deployment, and we will tell you what the limiting factor is.
What about returns? No refunds, on any tier — a box configured for one site is not something we can put back on the shelf. Standard packages carry a 30-day exchange window. Custom builds work differently: instead of an exchange window, the build is commissioned until it performs to the scope. That covers replacement parts where hardware is faulty, remote tuning and reconfiguration against your own footage, and on-site installation and commissioning as a paid service where the site needs hands on it.
The scope document is therefore the thing to read carefully. It is what “performing” is measured against — for both of us — and it is what we keep working against if the first pass falls short.
Start a conversation
Send the scenario, not a specification. Camera count, site layout, and the one thing you most need the system to catch — that is enough for us to tell you which algorithms fit, what accuracy to expect, and whether a package will do the job before you pay for a build.
Tell us your scenario for a scoped quote, or start with a Starter Kit and validate on your own cameras first. Package pricing is on the pricing page; hardware options are on the edge AI box page.