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.