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

The topics I plan to write about include ROS2 software architecture, reinforcement learning for control, Isaac Gym and Gazebo simulation workflows, multimodal robot data pipelines, and the practical details of connecting LLMs and VLMs to robotic systems.

My goal is to keep the writing useful: implementation notes, design decisions, experiments, lessons from hardware integration, and research summaries that can help another engineer reproduce or improve the work.