AI Customized Software

Custom AI built around your business problem

Fizon Tech builds custom AI software around a specific business problem, not off-the-shelf tools bent to fit. We design and ship workflow automation, computer vision, intelligent agents and predictive analytics that plug into the systems you already run. Because we also build the surrounding application and can source the hardware in-house, you end up with something in daily use rather than a model that never leaves the demo laptop.

We have been doing this since 2022 from Trichy in Tamil Nadu, with a second office in Dubai, across more than 150 projects in 12 countries. Our hardware team won the Smart India Hackathon 2022 Grand Finale in the hardware track, we have been supported through STPI Umagine Chennai, and we have received over 5 lakh in government grants. That mix matters more than it sounds, because a fair share of AI work turns out to depend on a camera mounted at the right angle or a device that survives a shop floor, not only on a better model.

Every engagement starts by defining the problem and the numbers that would prove it solved, then testing feasibility on your real data before full development. If what you need is specifically a language model, read our LLM training and fine-tuning service. If the AI is one part of a larger platform, our custom software engineering team builds the application around it, and our hardware sourcing and procurement team handles cameras, edge devices and sensors when the model has to run on site rather than in a data centre.

What each capability actually solves

Four capabilities cover most of what clients ask us for. Each has a different data requirement, a different integration path and a different failure mode, so it is worth being specific about all three before anyone signs anything.

Workflow automation

The usual problem is paperwork arriving in an inconvenient shape: supplier invoices as PDFs, delivery notes as phone photographs, claim forms as scans, purchase orders pasted into email. Somebody retypes them into the ERP, the queue builds up at month end, and typing errors surface weeks later during reconciliation.

To train an extraction model well we normally want 200 to 500 real examples per document layout, including the crumpled and badly lit ones, because a clean sample set produces a model that only works on clean documents. Integration is usually straightforward: we read from a mailbox, an SFTP drop or a shared folder, extract the fields, and write them back through a REST API or a controlled database insert. Anything the model scores below a confidence threshold goes to a human review screen instead of straight through.

The honest limit is that extraction accuracy never reaches 100 per cent, so plan for a review queue and someone who owns it. Printed text is reliable, stamped and handwritten fields are much harder, and a supplier who redesigns their invoice will need a short retraining cycle.

Computer vision

Vision earns its place where a person is currently watching something repetitive: counting output, checking that a component is present, spotting surface defects, confirming safety gear is worn, reading number plates at a gate, or auditing shelf stock. It is measurable work, which makes it easy to prove value.

For a detection or classification model we look for roughly 300 to 1,000 labelled images per class. The awkward case is always the defect you rarely see; if a fault happens twice a month, gathering enough examples takes longer than building the model, and we will say so early. Camera placement and lighting affect results more than the choice of architecture. Fixed mounting, consistent illumination and enough resolution on the region of interest are decided during discovery, not after.

Models run either in your cloud or on a device at the line. For on-site inference we typically use an NVIDIA Jetson Orin Nano or an industrial mini PC, with models exported to ONNX or TensorRT so they run fast on modest hardware. Results leave as MQTT or REST events into your MES or ERP, or as alerts to a supervisor. The limit worth knowing: a model trained on one line under one lighting setup will drift when moved to another, and it will need a fresh batch of images before it performs there.

Intelligent agents

Agents suit multi-step work that spans several systems and currently sits with a coordinator: triaging inbound enquiries, drafting quotations from a price list, reconciling two sets of records, or answering staff questions from internal policy documents. In most cases the right approach is retrieval over your own documents rather than fine-tuning a model, which keeps answers current when the documents change.

What we need from you is the source material in a usable state (documents, standard operating procedures, price lists) and scoped credentials for whatever tools the agent should call. Every action is logged, permissions are limited to what the task needs, and anything irreversible waits for a human approval.

The limit here is the most important one on this page. Agents are dependable at drafting, retrieving and preparing work for review. They are not dependable when left fully unsupervised on decisions with money, contracts or customer commitments attached. We design them with a person on the approval step, and we would rather lose that argument at proposal stage than after go-live.

Analytics and forecasting

This covers demand forecasting, churn scoring, predictive maintenance and anomaly detection in transactions. The data requirement is stricter than most people expect: normally 18 to 24 months of consistent history with reliable timestamps, and, critically, the outcome has to be recorded. You cannot predict machine failures if nobody has been logging failures, so occasionally the first project is fixing the record keeping.

Models read from your data warehouse or a read replica so nothing loads the production database, and results go back where the decision is made: into Power BI or Metabase for planning, or into the operational tool for day-to-day use. We use gradient boosting methods such as XGBoost far more often than deep learning here, because on tabular business data they are quicker to train, easier to explain and usually more accurate.

The limit is inherent to the method. A forecast learns from history, so it cannot anticipate an event with no precedent in the data. We always benchmark against the simple rule you use today, such as last month repeated or a three-month average. If the model does not beat that rule by a margin worth the maintenance, we will tell you rather than ship it.

How this connects to what you already run

Connecting to your existing systems

Almost nobody is starting from an empty desk. There is an ERP, an accounting package, a CRM, a shared drive and a WhatsApp group holding the process together. We integrate through whatever the system genuinely supports, in this order of preference: a documented REST or GraphQL API, then webhooks, then a scheduled export to a database or file drop, and only as a last resort screen automation, which breaks whenever a vendor changes a layout. Where a system has no API at all, we usually build a small service alongside it and keep the two in sync on a schedule you approve.

Where the model runs and who holds the data

Three options, chosen by your constraints rather than our preference. Cloud hosting is simplest and cheapest to start. On-premise hosting suits organisations whose policy keeps data inside their own network. Edge deployment suits vision work and any site with unreliable connectivity, since the device keeps working when the link drops. For clients in the UAE and India we can host in-region where your policy or your customers require it. You keep ownership of your data throughout, and we do not use it to train work for anyone else.

What a proof of concept looks like, and what it costs

A proof of concept exists to answer one question honestly: does this work well enough on your data to be worth building properly. It runs to a fixed scope and a fixed fee, and it ends with a recommendation that may well be to stop. Here is how an engagement runs, step by step.

1. Scoping call, about an hour. You describe the task, how often it happens and who does it now. We say whether it is a fit and which capability suits it. No charge.
2. Data sample, week one. You send a representative sample under an NDA. We check volume, labelling and quality, and confirm feasibility in writing before any fee is agreed.
3. Baseline agreed, week one. We write down what the current process achieves, such as minutes per document, defects that reach the customer, or forecast error last quarter. Without this number nothing later can be judged.
4. Model built and evaluated, weeks two to five. Data preparation, training, and evaluation on a held-out set your team has not seen, reported with precision, recall and a confusion matrix rather than a single accuracy figure.
5. Working demonstration, week five or six. A small interface running against your real records, so your team can try it rather than watch slides.
6. Written recommendation. Results against baseline, expected production accuracy, integration effort, running costs, and a clear go or no-go. If the answer is no, you have a documented reason and you have spent proof-of-concept money, not build money.
7. Production build, if you continue. Typically eight to sixteen weeks depending on integration depth, with fortnightly demonstrations and staged rollout alongside the existing process.

On cost, indicative ranges so you can plan a budget. A paid data audit, only where records are in poor shape, runs INR 40,000 to 75,000 (roughly AED 1,800 to 3,300). A proof of concept typically runs INR 2,50,000 to 6,00,000 (roughly AED 11,000 to 26,000) depending on capability, with vision and agent work at the upper end. Production builds usually start around INR 8,00,000 (roughly AED 35,000) and scale with integration count. Running costs are separate: cloud inference billed monthly, or a one-off edge device such as a Jetson Orin Nano developer kit, which lands in India at roughly INR 40,000 to 50,000 once duty and shipping are counted. These are ranges, not quotations. We confirm a fixed figure in writing after scoping.

How success is measured

Model metrics and business metrics

We report two sets of numbers and we do not let the first stand in for the second. Model metrics are precision, recall, the F1 score and a confusion matrix showing exactly where mistakes fall. Plain accuracy is misleading on imbalanced data: if two per cent of parts are defective, a model that passes everything is 98 per cent accurate and completely useless. Which of precision and recall matters more is a business decision. In quality inspection a missed defect usually costs more than a false alarm, so we tune for recall and accept the extra checks.

Business metrics are the ones your board will ask about: minutes to process a document, defects reaching the customer, forecast error against last quarter, hours returned to a team, or enquiries answered without escalation. Because we record the baseline before building anything, the comparison at go-live is a like-for-like measurement rather than an estimate. Where we cannot measure something reliably, we say so instead of publishing a number that flatters us.

What we watch after launch

Live systems degrade quietly. We monitor accuracy on a sample of production cases, the rate at which items land in the human review queue, response latency, and drift in the incoming data itself. A rising review-queue rate is usually the first sign that something upstream has changed, such as a new supplier layout or a repositioned camera. You get a monthly report in plain language, and a retraining schedule agreed in advance rather than negotiated in a crisis.

What to expect, and what not to

AI will not repair a process that is already broken. If approvals sit unread for four days, automating the data entry in front of them saves an hour and hides the real problem. We would rather point that out during discovery than build around it.

Accuracy plateaus, and the last few percentage points cost more than the first ninety. Moving a model from 90 to 95 per cent is often a longer project than reaching 90 in the first place. That trade is worth making for safety-critical inspection and rarely worth making for internal document sorting, where a review queue handles the remainder at far lower cost.

Adoption decides the outcome more often than the model does. Someone in your team has to own the review queue, act on the alerts and flag when the output looks wrong. Projects that stall are usually projects where that ownership was never assigned. And not every problem needs machine learning. Several times a year we recommend a rule, a validated form or a fixed report instead, because it is cheaper to run and easier to explain.

One more distinction worth making, since we get the question often. If you are a school or college looking at AI and robotics for students rather than for operations, our IoT, robotics and STEM programme for schools is the right place to start. It is a teaching programme with kits and trainers, not a build engagement, and the two are priced and run very differently.

Start with one task, not a strategy

The engagements that work best begin with a single, specific task rather than an AI roadmap. Send us a paragraph describing one job you would like handled: what it is, how often it happens, who does it today and how long it takes them. That is enough for us to say whether AI is a sensible answer, which capability fits, and roughly what it would cost.

Use the contact form on our home page to book a scoping call with the engineers who would do the work, or call the Trichy office directly. If it turns out you do not need a model, we will say that too.