We did this deliberately. When we opened the beta to our early-access cohort, we sent the invite with almost no documentation. A short note explaining what the tool did in one paragraph, a link to log in, and a request to bring a project they were already working on rather than starting something new. We wanted to see what writers would do when left alone with it, not what they would do when following our prompts.
Over the first week, we were reading usage logs, booking short check-in calls, and taking notes. What three of those writers did with that week is worth writing about, both because it confirmed some things we expected and because it corrected some assumptions we had held too confidently.
Writer One: Testing the Limits on a Feature in Development
The first writer, working on a feature about a middle-class family navigating a divorce in a Tier 2 city, came into the beta with a completed treatment. She already had a strong sense of her characters and her structure. She was not coming to Mugafi to find her story; she was coming to stress-test it.
Her first week was almost entirely adversarial. She would submit a scene or a beat sequence, read the structural feedback the beat engine returned, and then argue with it in the notes field. Not dismiss it, argue with it. What she was doing, as she explained in our check-in call, was using the annotations as a sounding board for decisions she had already made but was not fully confident about. The tool flagged a midpoint transition as structurally underweight. She disagreed, but working through why she disagreed forced her to articulate the emotional logic of the scene in a way she had not done before.
By the end of the week she had not changed the scene. But she had written a detailed character note that clarified why the scene worked the way it did. She said it was the first time she felt she truly understood her protagonist's internal arc in that moment. The tool had not changed her script; it had changed how she understood the script she was already writing.
This was not the use case we had most explicitly designed for, but it made sense immediately. Good development feedback does not have to be accepted to be useful. It has to be legible and specific enough that the writer can engage with it. A vague note does nothing even when the writer agrees with it.
Writer Two: Breaking a Series Room Bottleneck
The second writer was working on a six-episode OTT series and had been in development for several months. His challenge was specific: he had strong individual episodes but was losing narrative momentum across episodes three and four. Every time he revised, either episode three improved and episode four sagged, or the reverse. He was chasing a moving problem.
He used the beta to run beat analysis on both episodes simultaneously, comparing the structural annotations side by side. What emerged was a pattern: the escalation pressure he was building in episode three was resolving slightly too early, which meant episode four had to restart its own pressure arc from a lower baseline. The cumulative effect across the pair was a loss of momentum that no single-episode revision could fully fix.
His next revision targeted the transition between the two episodes specifically, rather than fixing either episode in isolation. By day four of the beta week, he had a version of both episodes that held together better than any previous draft. He described the process as finally being able to see the problem rather than feel it.
This was exactly the use case we had been thinking about when we built the series analysis view. Episodic structure problems often live in the seams between episodes, not within individual episodes. A tool that only analyzes one episode at a time will miss the pattern.
Writer Three: Early-Stage, Rebuilding from Scratch
The third writer was the most junior of the three, working on her first feature, a coming-of-age drama set in a coastal Karnataka town. She had a premise, two or three compelling scenes she had already written, and a general sense of what she wanted the film to feel like. What she did not have was a coherent structural plan.
She used the first two days to upload everything she had, including the existing scenes and a rough paragraph describing where she thought the story was going. The beat engine returned a structural gap analysis that was, she later told us, more honest than she was prepared for. The feedback essentially identified that she had a strong premise and a strong emotional tone, but no Act 2. There was no mechanism for escalation. The story as she had mapped it would reach its emotional peak and then have nowhere to go.
Her response was not to revise. It was to sit with the analysis for a day, then write a character backstory document she had never written before, looking for where the dramatic pressure in the middle of her story was supposed to come from. By day five she had a beat breakdown for all three acts that her story editor described as the most structurally clear she had submitted in four months of development.
She was emphatic in her check-in call that the value was not the specific annotations, some of which she disagreed with. The value was that the tool gave her a framework for thinking about her structure that she did not have before. She was a writer who worked very intuitively, which meant her strengths were real but her blind spots were invisible to her. Making those blind spots visible without crushing the intuition that was driving her work was the balance she needed.
What This Week Taught Us
We are not drawing conclusions about all users from three writers. What we can say is that the patterns these three writers displayed are consistent with what we have seen more broadly across our early-access cohort.
Writers use Mugafi most effectively when they come with a real project, not a practice exercise. The structural feedback means more when the stakes are real. Writers who disagree with the annotations and can articulate why are often doing the most productive work. And the tool is most useful not at the very beginning of a project, when the intuitive, exploratory phase still needs room to breathe, but in the transition between early exploration and committed development, when structural clarity starts to matter for practical as well as creative reasons.
We are also honest about where the beta fell short. Navigation between the beat analysis and the document editor was friction that slowed all three writers down. The feedback on dialogue, which we have been working on, was not granular enough for the feature writer who needed to understand why certain exchanges were not landing. These are specific problems we are actively working through.
But the core thing we wanted to test, whether a structural analysis tool could be useful to working Indian screenwriters without dictating how they should write, held up. Three writers, three different stages of development, three different uses. None of them wanted a co-writer. All of them wanted a more rigorous mirror. That is what we are building.