0→1 SaaS product incubation in enterprise wind

Zeitview delivers drone-based inspection and analytics software to utility-scale wind operators and OEMs. I joined in a customer-success role embedded with enterprise clients, close enough to the product that I kept ending up in the same place: between what a customer had committed to, what was technically feasible, and what could actually be delivered on the timeline. That is where these three products came from.

The first was internal tower inspection. Nothing scalable existed for it in wind at the time; inspections meant a technician climbing the tower and capturing static photos, which left documentation inconsistent and put people in exposed positions. Enterprise customers wanted something safer and more standardized that could run across a fleet. I ran structured interviews with those customers to pin down the operational use cases, the deliverables they actually needed, the workflow and safety constraints, and what adoption would require. Those findings became documented requirements, and I drove the ideation across operations, engineering, internal subject-matter experts, and a new vendor partner. Because the offering needed a vendor relationship that did not yet exist, I also drafted the initial terms and conditions to formalize it. We scoped the MVP deliverables to balance feasibility against client value and built in feedback loops so the outputs could be refined against real use.

Internal nacelle inspection followed, and it moved faster because most of the hard parts were already settled: the same enterprise customer, the same site, the same caged-drone hardware, the vendor relationship and terms already in place, and a deliverable framework already validated on the tower work. Rather than rebuild any of that, I ran targeted follow-up discovery on the nacelle-specific use cases and constraints, then adapted the existing framework with engineering, operations, and subject-matter experts while holding the safety and feasibility line. Reusing the validated deliverable structures is what let the rollout happen quickly.

The third started as an emergency. A blade failed at a utility-scale site, and the client needed a fast, accurate estimate of the remaining blade stub length. No internal workflow existed to produce that at scale, and a delivery commitment had already gone out, so the pressure was immediate. I called and organized a cross-functional alignment meeting across operations, engineering, and product to clarify feasibility and settle ownership, then helped turn an ad hoc request into a defined, repeatable measurement capability: standardized outputs, a bias toward rapid assessment over feature breadth, and a first iteration scoped to the high-impact post-failure case. Zeitview produced the measurement and the damage characterization; what the client did with it, the claim, the logistics, and the timeline, stayed on the client's side.

Across all three I was working without formal product ownership or budget authority, which meant the job was mostly turning ambiguity into scope: clarifying requirements, getting the right people in the room, and keeping momentum when nobody had been formally assigned to the problem.

That same systems instinct now runs through internal AI tooling I build alongside the day job. An upload validator catches vendor dataset errors before they reach customer success or engineering, saving up to five hours of customer success time and up to five hours of engineering time per project, across two to four projects a week. A purchase order automation agent runs daily in production and reclaims more than 10 hours of my week from manual intake. The validator is in Recent Builds; the purchase order agent has its own write-up.