Pros
+ Genuinely interesting 3D rendering product + Modern TypeScript stack + Technically complex engineering problems worth solving + QA team is sharp and writes excellent bug documentation + Internal documentation is generally solid
Cons
Staffing instability. I joined in early 2024 as part of a larger hiring wave. Over the following year, headcount on the product side declined steadily. A Head of Product, a Chief Product Officer, and several developers departed through a mix of resignations and layoffs. By Q1 2026 I was included in a reduction that also took out two other developers, a Creative Director, and a UX designer. This happened during a period when company-wide meetings were showing positive revenue trends. Engineers considering this role should factor that pattern into their decision. High feature velocity with limited process support. Sprints run three weeks and typically include one to two net-new features, each requiring support across a wide matrix of client configurations. Developers are responsible for their own QA in addition to feature work. When a configuration edge case slips through, remediation tends to land in the following sprint, which creates compounding pressure on future deadlines. Configuration complexity is significant and often underestimated. The platform powers white-label products across multiple verticals, each with deep client-specific customization. Building something that behaves correctly across all configurations takes more time than typical estimates account for, and that gap tends to surface at the worst possible moment. Deadlines carry more weight than scope. When timelines slip, the default response is to push through rather than resize scope. The engineering management team does its best to buffer the team from this pressure, but the broader culture treats client commitments as fixed regardless of what changes downstream. Feature cards often arrive without documentation. Cards are frequently assigned with little to no written context. The expectation is that developers will gather requirements during sprint planning and follow up with managers or colleagues as needed. That research phase is real and is not typically reflected in story point estimates. Required sprint demos with no guidance. At the end of each sprint, every developer is required to record a video demo and produce an accompanying slide summarizing their work. The demos are well-regarded internally, but there is no documentation or established standard for how to create them. The time required to produce them is not accounted for in sprint planning, which means it quietly eats into development time at the end of every cycle. For employees on Pacific time, these demos are presented around 6:30am. The weekly report to the CEO has limited utility. All employees submit a five-item accomplishments and goals summary every Friday. Responses tended to be brief and the channel didn't appear to function as a two-way feedback loop. Substantive concerns raised through this channel did not appear to influence planning or priorities in any meaningful way. Pacific time employees start early. Company-wide kickoffs are held at 9am Eastern. For anyone on Pacific time, that is a 6am start every day.