Microsoft's new build tools repriced themselves, and the citizen developer is the line item

Three of Microsoft's newest build tools have quietly changed their commercial shape, and the change lands hardest on the exact population they were pitched at. In a dev.to post published under the handle wyattdave, a developer who had been planning around Code Apps, Cowork and the new Copilot Studio (also referred to as GitHub Copilot Harness) argues that pricing and packaging decisions, not capability, have reset the adoption curve for all three [s1c1].

The specifics, as the post describes them: Cowork moved to what the author calls an expensive pay-as-you-go model [s1c5]. The new Copilot Studio began charging for development time and removed free usage for Microsoft 365 Copilot licence holders [s1c6]. The author reports that the impact of that second change was large enough that the older Copilot Studio now looks set to stay rather than be replaced as planned [s1c7]. No dollar figures appear in the post, so "expensive" is the author's judgement rather than a published rate card [s1c20].

Meanwhile the front door for the third tool has not opened. Vibe.powerapp.com, described as the user-friendly version of Code Apps and the route by which citizen developers were expected to reach it, remains half finished and in preview [s1c2][s1c3]. The post gives 18 November 2025 as the launch date while also calling the preview almost a year old, so treat the elapsed time as approximate [s1c21]. The author's read on preview limbo is blunt and familiar to anyone who has bet a roadmap on a Microsoft preview: these things either get traction and reach general availability, or they die in preview without ever being formally deprecated [s1c4].

The consequence is a channel problem. If the friendly front end stays in preview, what is left is VS Code and adjacent developer surfaces, which the author argues most developers do not want to use [s1c9]. And metered development time changes the psychology of experimentation: the author's phrase for it is a "prove ROI before trying" philosophy, which he says kills innovation and citizen developers specifically [s1c10]. He is careful not to declare the tools dead, only that likely adoption has been massively changed [s1c8]. That distinction matters for planning. A tool that survives with a narrower, better-funded user base is a different procurement question from a tool that disappears.

The post traces the cause back to strategy rather than to any single pricing decision. Microsoft's bet was to attach Copilot to the interaction layer it already owned and let ubiquity at free or discounted prices do the work, on the Teams and Internet Explorer pattern, with monetisation to follow once value was established [s1c11]. The author's complaint is that the initial launch was fragmented and appeared to be built independently by each team, at a point when the models were not good enough and supporting technology such as MCP did not yet exist [s1c12]. Copilot in Office is offered as the illustration: Graph-grounded experiences, then an application-specific Agent Mode two years later, then a tool-and-context architecture around MCP and Work IQ six months after that [s1c13]. That is roughly thirty months and two architectural rewrites [s1c14]. The author's verdict is that the current experience is much improved and the initial one was not good [s1c15].

Worth noting what the post does not claim: that the free-everywhere approach failed on its own terms. It contrasts Microsoft with a vendor that gave up the interaction layer entirely to focus on a coding niche, leaving Cursor as arguably the main winner among developer front ends, and that could then charge considerably more than other providers [s1c16][s1c17].