I took an AI-assisted control-design platform from concept to an MVP. It has completed two proof-of-concept cycles and passed the company’s internal product-readiness gate.

The product has not launched commercially. A formal B2B product-market-fit programme comes next, so this page makes no claims about paying customers, revenue or product-market fit. The company is an early-stage agentic-AI startup, and its name, customers and internal targets are confidential.

My role

Technical Product Manager (Mar 2026 to present). Before that, Robotics Software Engineer on the same product (Nov 2025 to Mar 2026).

Team

Seven engineers and three stakeholders across AI, control engineering, software, product design and QA

Stage

MVP, two POC cycles complete, readiness gate approved

Ways of working

Agile/Scrum with Jira, Mizito, Notion and Google Workspace

The problem

Designing a controller takes a chain of specialist steps. An engineer starts from a nonlinear model of the system, finds an operating point and linearizes it into a state-space model. Then they design and tune candidate controllers, run closed-loop simulations, and check stability and frequency response. Each step needs expertise and usually a different tool, and when a check fails, much of the chain has to be repeated.

The product’s bet is that AI agents can carry much of that chain, from a system description to a verified controller candidate.

My role

I joined the engineering team in November 2025 and was promoted to Technical Product Manager in March 2026.

As an engineer, I built parts of the automated pipeline. That included an agent workflow that generates operating points, state-space models, controller candidates and closed-loop simulations from nonlinear system descriptions. I also worked on model parsing, signal interconnection, Jacobian linearization, and the stability and frequency-domain checks.

As product manager, I own the product definition and its delivery. I wrote the market requirements document, business plan and business model canvas. I also run discovery, write requirements and acceptance criteria, manage the backlog, coordinate the team, validate releases, and wrote the go-to-market strategy and plan.

Having built the pipeline myself made it much easier to write requirements the engineers could act on, and to judge whether a result was correct.

Discovery

I ran market research, competitive analysis and more than 100 customer interviews. The interviews tested our assumptions about the problem and set our priorities. I turned the findings into product requirements and a prioritized roadmap.

Main product decisions

Scope the MVP around design, simulation and verification

The first release put the capabilities an engineer needs to trust a result first: automated design, closed-loop simulation and verification. Verification was in the core product from the start.

Use acceptance criteria as the shared definition of done

Every capability had user stories and acceptance criteria written in control-engineering terms. Completed features were checked against them before release, so engineering, design and QA all worked to the same definition of “done”.

Validate before selling

After the MVP, the product went through two proof-of-concept cycles and then an internal readiness gate. Go-to-market execution starts only after that gate.

Keep technical validation apart from market evidence

Test users can show that the product works. Only companies can show that they need it. The go-to-market plan I wrote defines the company-level evidence the next phase has to collect, so proof-of-concept usage is not counted as traction.

Delivery

I ran delivery in Agile/Scrum and kept the backlog prioritized in Jira, with Mizito, Notion and Google Workspace alongside it. I coordinated seven engineers and three stakeholders across AI, control engineering, software, product design and QA, and validated each completed feature against its acceptance criteria before release.

Evidence and results

In the first proof of concept, 38 academic test users created 198 projects on the platform. The second proof of concept is complete, and the product-readiness gate was approved internally, which clears the product for the next phase.

This is technical product validation with test users. It does not show paid usage, a company pilot or product-market fit.

What’s next

I wrote the go-to-market strategy and plan for the next phase. It covers target accounts, qualification, a launch sequence with gates, and the company-level evidence needed to judge product-market fit. The plan names me as the owner of PMF and go-to-market operations. The formal three-month B2B programme is the next step, and I will add its results here once there are results to report.

ViGenX turns a plain-language editing brief into a typed, validated workflow. A person can inspect and change that workflow, and nothing renders until they approve it.

It is my own open-source project. I built the initial MVP in 2025 and showed it at Diginext’s 10th Startup Camp. The current release is pre-1.0, suitable for development and testing, and has not yet been validated with external users.

My role

Independent product and technical lead

Stage

Pre-1.0, locally run, Apache-2.0

Built with

Python, Flask, React Flow, Whisper and FFmpeg, with optional Gemini, Groq or NVIDIA planning

Links

Repository · Landing page

The problem

Turning a long recording into short clips means repeating the same steps. You transcribe it, find the moments worth keeping, reframe for vertical video, add captions and music, and export. One-prompt generative tools promise to automate this, but they tend to return a finished render. You can’t see which decisions were made or change one step without starting again, and rerunning the same edit gives a different result.

That matters more when the footage carries obligations, such as licensed music, people’s faces or third-party clips, because an opaque result is hard to review. My working hypothesis was that creators would trust automation more if they could read and change the plan before it touched their footage.

My role

ViGenX is my own project. I defined the product vision, requirements, MVP scope and roadmap, and I led the technical build. Diginext hosted the startup camp where I showed the first MVP. It was not my employer and does not own the project.

What I know about users so far

There has been no structured external user research yet. The problem definition comes from my earlier work producing and editing video content, and from building the first MVP.

That MVP shipped three fixed pipelines: general, speaker and gaming. The current version replaces them with composable blocks that a planner assembles for each brief, so a new kind of edit needs a new block instead of a new pipeline. The fixed pipelines stay available until the graph version reaches parity.

Main product decisions

The model plans and a person approves

I considered letting a language model drive the edit end to end. That is the fastest route to a demo, but it is opaque and hard to repeat. Instead, the planner compiles a brief into a graph built only from registered blocks. It cannot invent block types, parameters, file paths, commands or upload targets, and it marks every workflow it generates as requiring approval. The cost is that the planner can only do what the block catalog supports, so new capabilities need engineering work.

Users edit the workflow directly

The graph is serializable JSON. It opens in a visual editor and can be saved and rerun, so users spend their time reviewing, adjusting and reusing an edit instead of regenerating it from another prompt.

Planning works without an API key

A deterministic local planner handles common requests such as clip count, duration, vertical format, captions, music and branding. Model-backed planning is optional. In Auto mode ViGenX falls back to the local planner when no key is set, and in AI mode it fails with an error if no provider is configured. The local planner understands a narrower range of briefs.

Every export carries rights information

Each export writes a rights manifest and metadata. Publishing adapters act only on approved jobs and default to private visibility where the platform supports it. The documentation says plainly that automation does not establish fair use or ownership.

What I left out

ViGenX is not a hosted service, has no multi-user authentication (it binds to localhost) and is not meant to edit autonomously. Leaving these out kept the scope achievable for one person and kept the trust boundary simple.

Delivery

I built the initial MVP in 2025 in five-week Agile sprints. It was a Python and Flask pipeline that turned long-form video into short clips, with transcription, key-moment scoring and face blurring using Whisper, MediaPipe, YOLOv8 and Gemini. It also had live job monitoring, a review queue, and metadata and rights files.

The open-source version, public since June 2026, adds a React Flow editor with generated inspector controls, templates and undo/redo. It has a block catalog for editing, audio, branding, AI analysis and export, per-node progress, batch sources, publisher adapters that wait for approval, and an entry point for third-party blocks.

Evidence and results

What exists today:

• a public, Apache-2.0 repository with continuous integration and unit, API, planner, concurrency and persistence tests;
• a working prompt-to-workflow path that runs without downloading models or setting an API key;
• the showing of the initial MVP at Diginext’s 10th Startup Camp.

There is no external usage data, structured user feedback or measured time saving yet. The test suite does not prove render quality on arbitrary footage, and the documentation says so. I am not claiming adoption or product-market fit.

What I learned, and what’s next

Separating planning from execution is what makes this AI feature reviewable. I apply the same pattern to AI in engineering software, where a wrong action is expensive and users need to check what the system intends to do before it acts.

Writing down the non-goals and the rights disclaimer early made later scope decisions faster.

The next validation step is to get the first external users to run ViGenX on footage they are allowed to edit and report exactly where it fails. On the engineering side, the open priorities are prompt-to-workflow evaluations with small licensed test videos, bounded render verification, node caching, and workflow diffs with dry-run cost estimates.

Artifacts

• Source code and documentation
• Landing page
• Contribution guide

A fuzzy “Strength Index” adapts knee-exoskeleton torque in real time while the user stands up from a chair. In a five-person engineering study it cut measured muscle effort by 30% at slow speed, with smaller gains at faster speeds.

This is a research prototype from FUM CARE. I am first author of a preprint on SSRN, which has not been peer-reviewed. The study was an engineering evaluation and was not clinical.

My role

Project manager and first author, in a university research team

Device

FUM-NEXA: passive hip and actuated knee joint per leg

Task

Standing up from a 46 cm chair

Runtime

Raspberry Pi 4B, ROS2 (Python/C++), CAN motor control

Evaluation

5 healthy subjects × 3 speeds × 3 device conditions

The problem

Fixed torque profiles are simple to deploy, but they can’t tell a user who is moving faster than the reference from one who needs substantial help. A rehabilitation device also has to avoid the opposite failure: giving so much torque that the user stops contributing.

The project had to meet several constraints at once:

• estimate how much help is needed from signals available on the robot, without continuous EMG control;
• adapt torque during the movement as well as between sessions;
• run on a Raspberry Pi-class computer with a small sensor and actuator set;
• start assisting at the right moment, close to lifting off the chair;
• show that the device reduces effort after accounting for its own weight and inertia.

The last constraint turned out to matter most. Wearing the exoskeleton with the motors off increased measured muscle effort by about 40%, so the controller had to more than offset the device’s own burden before it could help.

My role

I was project manager and first author. It was a team project at FUM CARE, and I was not the sole designer, fabricator or experimenter.

I developed the control concept, meaning the Strength Index, the fuzzy rule base and the torque-scaling policy. I connected the controller to ROS2, the CAN sensors and actuators, real-time filtering and logging. I coordinated the control, mechanical, experimental and writing work needed to get from concept to a working prototype, and helped structure the three device conditions and three speeds used for validation. I also wrote the manuscript and prepared its figures.

Main design decisions

The controller estimates how much help the user needs from hip and knee velocity errors and torque feedback, without EMG. That estimate of the user’s capability is indirect, but it needs no extra sensors on the body.

It scales a reference torque using the index: assistive torque = desired torque × (1 − Strength Index). The movement target stays the same while the amount of help changes.

We chose a small rule base. Nine fuzzy rules run comfortably on a Raspberry Pi and are easy to inspect and tune, which suited a small team and limited compute better than a learned model.

Assistance starts at chair lift-off. The right torque at the wrong phase of the movement is still a bad experience, so we treated the trigger point as a requirement.

The evaluation included a motors-off condition, which separated the device’s burden from the controller’s benefit.

The four sit-to-stand phases, with the trigger point near chair lift-off.

Results

Average change in muscle effort (EMG IRMS) across the five subjects, relative to standing up without the exoskeleton. Positive values mean less effort.

Assistance reduced measured effort at all three speeds. The benefit was largest at slow speed, where help matters most for users who struggle to follow the reference, and it shrank at fast speed, so the controller was not equally effective everywhere. The device’s own burden was large enough that the results could only be interpreted against the motors-off condition.

The adaptive torque keeps the shape of the reference profile at a lower magnitude across the three speeds.

What I took into product work

A feature can make things worse before it helps, so I now try to measure the cost of adopting a product separately from the value of using it.

Timing belongs in the requirements. Correct output delivered at the wrong moment still fails the user.

Limited compute and sensing pushed this design toward a small controller that is easy to explain, and that worked in its favour.

Technical detail

CAN sensor data
  → filter joint velocity and torque
  → compute motion and torque errors
  → fuzzy Strength Index → scale desired torque
  → motor-driver PID → CAN → knee BLDC actuators
  → log sensor, motor and controller data

Publication

S. M. Sarfarazi, S. Farhadi, H. Sabzali, M. H. Gheshlaghi, I. Kardan and A. Akbarzadeh, “A Fuzzy Strength Index for Adaptive Assist-as-Needed Control of a Knee Exoskeleton Robot to Enhance Sit-to-Stand Transition,” SSRN preprint, posted March 2026. doi:10.2139/ssrn.6335794. The preprint has not been peer-reviewed. Code and video are not public.

Separating where to go from how to walk let a simulated quadruped reach 94.2% navigation success, including 88.6% on map layouts it had never seen.

This is simulation research, presented as a conference paper at ICRoM 2025. A public proceedings record is not available yet. My M.Sc. thesis extends this work and is still in progress, and this page reports no hardware results.

Read the paper summary and original figures or download the complete conference manuscript (PDF).

The problem

A legged robot crossing cluttered, uneven ground has two jobs at once: choose a route around obstacles, and place its feet so it doesn’t fall. Training one “monolithic” policy to do both mixes very different objectives, and it tends to generalize poorly to new layouts.

The approach

A high-level navigation policy works on a 2D map and goal, and outputs a body-frame velocity command. That command is bounded, so the navigation policy can’t ask for motion the locomotion policy can’t deliver.

A low-level locomotion policy tracks the command in 3D. It uses 187 terrain height samples around the robot’s body and does no explicit footstep planning.

Both policies were trained and evaluated in GPU-parallel Isaac Gym simulation. In the reported setup, training took about five hours on a single GPU.

My role

I was second author on a three-person paper. I designed the hierarchical structure and implemented the reinforcement-learning path-planning component. In the lab, I also define requirements, evaluation criteria and success metrics for this line of experiments.

Results (simulation)

These numbers come from simulation under the paper’s evaluation protocol, and none of them were measured on a physical robot.

How this carries over to product work

Deciding what the upper layer may request, and what the lower layer guarantees, turned one hard problem into two testable ones, and each layer could be evaluated against its own success criteria. I use the same approach when I scope product features and split work between teams.

Thesis work, in progress

The thesis extends the architecture toward risk-aware navigation. It combines global graph search (Dijkstra) with sampling-based local planning (MPPI) and a distributional reinforcement-learning controller for locomotion. Results will be published once the thesis is complete.

Citation

Y. Ayoubi Rad, S. M. Sarfarazi and M. Shahbazi, “Hierarchical Deep Reinforcement Learning for Quadruped Navigation over Complex Terrains,” 13th RSI International Conference on Robotics and Mechatronics (ICRoM 2025), Tehran, December 2025. Author-hosted conference manuscript (PDF). A proceedings link will be added when the public record is available.

What I built

YOLO11n detects objects and ByteTrack keeps their identities across frames. The metric outdoor variant of Depth Anything V2 then turns each detection into a 3D position.

A recursive Kalman filter tracks motion with a six-value state (position and velocity in x, y, z). It uses wall-clock time between frames, so velocity stays consistent when the frame rate varies, and it keeps predicting through missed detections.

I calibrated the camera (a Samsung A34) with a checkerboard, and used a second phone’s IMU (a Samsung A54, via Phyphox) to sanity-check the estimated velocities.

How I chose the components

I benchmarked the detectors myself on the target laptop (RTX 3060, 6 GB):

I picked YOLO11n. It wasn’t the fastest, but it gave the best balance of detection quality, installation reliability and speed. The depth model was the real bottleneck at about 0.22 s per frame (≈ 4.5 FPS).

Results and limits

The Kalman filter typically converged within three to five frames of a new detection. I tested qualitatively on crowded pavements, street traffic and mixed traffic.

The report states the main limitation. Without LiDAR or stereo ground truth, I could not measure end-to-end depth error, and metric scale needed manual calibration. The depth model’s published benchmark (0.454 m MAE on its own validation sets) does not measure this system.

What it does

It takes an instruction in plain language and uses the Gemini API to turn it into a sequence of ROS2 actions, which then run on a simulated robotic arm in Gazebo.

Status and limits

This is an early-stage experiment. It has no formal evaluation yet, and the code is not public. I’ll update this page with a repository, the supported task set and results when there is something worth measuring.

The same question drives ViGenX: how to let a language model plan while keeping execution verifiable.

What I built

A Python (Kivy/Buildozer) Android app runs a TensorFlow Lite MobileNet v1 model on the phone to detect and select the person to follow, at roughly 60 frames per second.

The phone sends forward, backward, left, right and stop commands over USB serial to an Arduino Uno, which drives four DC motors through an L298N driver.

An HC-SR04 ultrasonic sensor overrides the vision system. It stops or redirects the robot whenever an obstacle is closer than 1.5 m.

Decisions worth noting

I compared a Raspberry Pi with a smartphone as the compute platform, and SAMURAI, YOLOv8 and MobileNet as detectors, choosing on inference efficiency. Running vision on the phone kept the robot’s electronics simple and cheap.

Limits

This was a course prototype. It was not evaluated with a formal protocol, and no code or video is public.