Skip to content
MACT.ai

Solutions

BUILD INTELLIGENT PRODUCTS.

Seven areas where AI meets the physical world. Each one has a defined approach, proven scenarios, a technology set, and work behind it.

  • 01

    AI Products

    Products with intelligence in the architecture, not bolted on.

    Problem

    Most AI features are added late, so the model is constrained by decisions already made about compute, latency and data. The result feels like a demo attached to a product.

    Approach

    We design the product around the model from the first architecture review — what runs where, what it costs per interaction, how it fails, and what the user sees while it thinks.

    Proven scenarios

    • Conversational hardware

      A device whose primary interface is speech. Wake word and audio processing stay local; recognition and reasoning stream so playback starts on the first chunk. We hold first-audio latency as the product metric.

    • Assisted operation

      An operator-facing product where the model proposes and a human confirms. The interesting engineering is in the confidence display and the fallback path, not the model itself.

    • Autonomous decisioning

      Closed-loop products where the model acts without review. These need deterministic guardrails, bounded action space and a full audit trail before anything ships.

    Capabilities

    • AI product architecture
    • Model selection and evaluation
    • Latency and cost budgeting
    • Interaction design for probabilistic systems

    Technologies

    LLMVLMRAGFine-tuningAI AgentsEval
  • 02

    AIoT

    Connected devices that get smarter after they ship.

    Problem

    Connected hardware is often shipped and then frozen. Without safe updates and real telemetry, the product cannot improve and problems are invisible.

    Approach

    We build the device, the cloud and the update path as one system, so behaviour can be improved in the field with staged rollout and a way back.

    Proven scenarios

    • Distributed equipment monitoring

      Nodes across sites with unreliable uplinks. Control and safety logic run locally; the cloud sets intent and observes outcomes, so a lost connection degrades reporting rather than operation.

    • Consumer connected products

      Where onboarding decides retention. We design provisioning for a first-time user on a real home network, with a captive fallback when BLE pairing fails.

    • Mixed-generation fleets

      Hardware revisions accumulate. A versioned device protocol from the first release lets three generations share one fleet, one console and one OTA pipeline.

    Capabilities

    • Device and cloud architecture
    • Fleet management and provisioning
    • Staged OTA with rollback
    • Telemetry and observability

    Technologies

    MQTTWebSocketOTADevice CloudBLEWi-Fi
  • 03

    Edge AI

    Real models inside real power and memory budgets.

    Problem

    A model that works on a workstation rarely fits an embedded target. Quantization is attempted late, accuracy drops, and the schedule absorbs the surprise.

    Approach

    We benchmark candidate models on the actual silicon early, then quantize and optimize with accuracy tracked against a fixed evaluation set.

    Proven scenarios

    • Privacy-constrained inference

      Where data cannot leave the device at all. The full pipeline runs locally and only structured results are transmitted — which changes the silicon choice, not just the software.

    • Latency-critical control

      Inference inside a control loop, where a round trip to the cloud is not an option. We budget worst-case latency, not average, and verify it under sustained thermal load.

    • Cost-constrained volume products

      When the NPU budget is set by the retail price. We benchmark down to the cheapest silicon that meets the requirement rather than up from the most capable.

    Capabilities

    • On-target benchmarking
    • Quantization and pruning
    • NPU and DSP deployment
    • Runtime and operator optimization

    Technologies

    ONNXTFLiteTensorRTINT8NPURKNN
  • 04

    Computer Vision

    From sensor to decision, with the whole path engineered.

    Problem

    Vision accuracy is usually lost before the model runs — in optics, exposure, timing and the image pipeline rather than in the network weights.

    Approach

    We treat optics, sensor, ISP tuning and the model as one pipeline, and validate it against footage from the environment the product will actually live in.

    Proven scenarios

    • Fixed-installation monitoring

      Known scene, known mounting, uncontrolled lighting. Most of the accuracy comes from locking optics and exposure strategy against real footage before any model is chosen.

    • Motion and posture analysis

      Where the signal is temporal, not per-frame. Detection runs at reduced cadence with tracking holding identity between inferences, so modest silicon reaches a stable frame rate.

    • Inspection and measurement

      Vision as a measuring instrument. Calibration, repeatability and defined failure behaviour matter more than raw model accuracy.

    Capabilities

    • Optics and sensor selection
    • ISP tuning and exposure strategy
    • Detection, tracking and segmentation
    • Dataset and evaluation pipeline

    Technologies

    MIPI CSI-2ISPDetectionTrackingCalibration
  • 05

    Voice AI

    Conversation that feels immediate on modest hardware.

    Problem

    Voice products fail on latency and on noise. Both are decided by the audio front end and the streaming architecture, long before the language model is involved.

    Approach

    Wake word and audio processing stay on device; recognition, reasoning and synthesis stream so playback can begin on the first chunk instead of the last.

    Proven scenarios

    • Low-cost voice assistants

      Wake word inside an MCU memory budget, with recognition and reasoning streamed. The bill of materials is usually dominated by the audio chain, not the compute.

    • Hands-free industrial interfaces

      Noisy environments where a touchscreen is impractical. Beamforming and a constrained command grammar beat a general model on both accuracy and latency.

    • Multilingual devices

      One product, several markets. Language routing happens at the gateway, so adding a language does not require a firmware release.

    Capabilities

    • Microphone array and acoustic design
    • Wake word and VAD on device
    • Streaming ASR, LLM and TTS
    • Barge-in and turn handling

    Technologies

    ESP32Wake WordAECStreaming ASRTTSOpus
  • 06

    Robotics

    Physical AI — perception, planning and control in one system.

    Problem

    Robotics work often splits perception from control, and the integration cost of joining them arrives at the worst possible moment in the schedule.

    Approach

    We build the perception, planning and motion stack together, with deterministic real-time control separated from the higher-level intelligence by a defined contract.

    Proven scenarios

    • Fixed-cell manipulation

      Repeatable pick and place with vision-guided correction. Cycle time and repeatability are the specification; safety is enforced in hardware.

    • Mobile autonomy indoors

      Navigation in a space shared with people. Localisation, obstacle handling and a safety layer that can override the planner are the core of the work.

    • Instrument automation

      Precision motion in scientific and optical instruments, where sub-arcminute accuracy over long sessions matters more than speed.

    Capabilities

    • Motion control and kinematics
    • Perception and sensor fusion
    • Real-time architecture
    • Safety and failure behaviour

    Technologies

    ROS 2RTOSSLAMSensor FusionMotor Control
  • 07

    Smart Devices

    Consumer hardware that survives contact with manufacturing.

    Problem

    A working prototype is not a product. Cost, yield, certification and tooling reshape the design, usually after the schedule has been promised.

    Approach

    We design for the bill of materials, test and certification path from the beginning, and drive prototypes toward pilot production rather than toward a demo.

    Proven scenarios

    • Battery-first products

      Wearables and portables where average current sets every other constraint. A measured current budget in week one is what makes feature decisions possible.

    • Display and device UI products

      Where the on-device interface carries the brand. Compute is chosen against the UI and inference workload together, before schematic.

    • Ecosystem-integrated products

      Matter, HomeKit and Alexa integration shape the radio choice and the certification path, so the ecosystem decision belongs in architecture.

    Capabilities

    • Product and mechanical architecture
    • BOM and cost engineering
    • EMC and certification readiness
    • Pilot production and test fixtures

    Technologies

    PCBDFMEMCEnclosureTest Fixtures

HAVE AN IDEA?
LET'S BUILD IT.

mact.ai