An MVP at the Edge of a Release Decision

MVP News is no longer a sketch or a prototype — it’s a working product.

From the beginning, the core idea was simply to generate news with AI and grade that content by difficulty level for language learners. Each article is currently graded across four bands, and the grading logic is built directly into the content pipeline.

The central mechanism does what it is meant to do.

Where things have become less clear is not the idea, but the release decision.

The MVP works, broadly as intended. But as I have started to use it more seriously — and to think about who it’s actually for — a set of questions emerged that I hadn’t considered at the outset. They aren’t about whether the product works, but about how far it should go before being released.

As I’ve spent more time using the app and thinking about who it’s really for, I’ve run into a decision I didn’t fully resolve at the beginning. The MVP feels ready — but the path forward isn’t obvious.

This post is about that moment: when something works, but you’re not yet sure how far to take it before pushing it out into the world.

What the MVP set out to prove

The goal of this MVP was deliberately narrow.

I wanted to see whether AI-generated news content could be simplified, graded by level, and delivered in a way that’s actually usable for language learners — not just technically possible, but readable and consistent.

That meant focusing on a few core things:

• generating short news-style articles
• grading them across four difficulty bands
• keeping the experience lightweight and fast

On that level, the MVP does what it’s supposed to do. Articles are generated, graded, and displayed reliably. The grading isn’t perfect, but it’s predictable, which matters more at this stage.

Crucially, this part of the system feels stable enough that I’m no longer questioning whether the idea works. The open question now is what to build on top of it — and what to leave out for now.

The consideration that changed the picture

One assumption I made early on was that this would be an English-first product.

That wasn’t a particularly deep decision. English is where most of the demand (and money) is. So I didn’t spend much time questioning it.

What changed that was using the app for myself.

I’m learning Japanese, and I wanted to see whether the MVP could handle a language I actually care about, not just one that made sense on paper. As soon as I did that, the idea of “the language” stopped being a background detail and became a real design choice.

If I’m building something for learners, should the language be fixed? Or should it be something the user can choose?

That single question opened up a much bigger one: am I releasing a tightly scoped product for one language, or am I building something that’s meant to support multiple languages from the start?

One language or many?

At this point, the decision is fairly clear, even if the answer isn’t.

One option is to pick a single language and release around that. Most likely, that would mean English. It keeps the scope tight, makes the positioning simple, and avoids a lot of early complexity.

But there’s a downside to that approach that’s harder to see on paper. As a solo developer, testing the product properly matters — and it’s much easier to assess whether something is working when I’m also the target user.

I’m learning Japanese, and to a lesser extent Chinese. Building and testing the product in those languages gives me much better feedback loops. I can judge whether the grading feels right, whether the content is readable, and whether small changes actually improve the experience. With English alone, that kind of assessment becomes more abstract.

The alternative, then, is to support multiple languages from the start, but in a controlled way. Not “any language,” but a small, intentional set — for example English, Japanese, and Chinese. That reflects how learners actually use language tools, while still keeping some sense of scope.

The trade-off remains the same. Each additional language adds complexity: not just in content generation, but in grading, UI, and how users move through the app. What looks like a small feature quickly becomes a structural choice.

So the question isn’t really “should I add a language selector?” It’s whether this MVP should be a focused, single-language release, or the first version of something more broadly applicable.

Why this isn’t just another feature

At first glance, adding language selection feels like a relatively small step. A dropdown, a parameter, a bit of conditional logic.

In practice, it reaches much deeper than that.

Language choice affects how content is generated, how difficulty is assessed, and how reliable the grading feels across levels. It shapes the UI, the defaults, and eventually the way users move through the product. Even decisions like what a “beginner” article looks like start to mean different things in different languages.

It also sets expectations for what comes next. Once users can choose a language, ideas like saved preferences, personalised views, or returning to “their” version of the site start to make sense. Those aren’t problems to solve immediately, but they’re consequences of the choice being made now.

So the hesitation here isn’t about adding one more control to the interface. It’s about deciding how much structure the MVP should carry into its first public release.

The user state question (acknowledged, not solved)

Once you introduce choices like language, level, or topic, it’s natural to start thinking about user state.

If someone can select a language, should the app remember it? If they come back tomorrow, should they see the same version they were using before? And if multiple users are using the site at the same time, how should that be handled?

Those questions quickly lead to familiar territory: accounts, persistence, and personal pages.

All of that may matter eventually, but none of it is required to answer the question in front of me now. At this stage, the issue isn’t how to store user preferences long-term — it’s whether the product should even expose those choices yet.

For the moment, it’s enough to recognise that today’s release decision influences tomorrow’s architecture, without letting future complexity dictate what gets built now.

How I’m thinking about the decision

To keep this from turning into a vague debate about scope, I’ve been trying to evaluate the decision using a few simple criteria.

First, what helps learning the most right now? Level-graded content was always central to the idea, and language choice clearly affects how usable that content is. If a feature meaningfully improves the learning experience, it deserves serious consideration — even in an MVP.

Second, what can I realistically test and assess on my own? As a solo developer, tight feedback loops matter. Being able to judge whether the output “feels right” in Japanese or Chinese is a practical advantage, not just a personal preference.

Third, what keeps the MVP honest? Every addition should support the original goal, not obscure it. If a change starts to pull the project toward long-term infrastructure or user management, that’s a signal to slow down.

Using this lens doesn’t magically produce an answer, but it does help separate decisions that clarify the product from ones that simply add weight.

What comes next

Right now, the MVP works. The question isn’t whether to keep building, but how deliberately to move forward.

Releasing with a single language keeps things simple. Supporting a small number of languages makes the product more flexible and more honest to how learners actually use it — but at a cost.

This post isn’t about locking in a final answer. It’s about recognising that release decisions shape products just as much as features do. Once something is public, it starts to define expectations, even at a small scale.

The next steps will be about making that decision explicit, and then following through — either by narrowing the scope and releasing sooner, or by adding just enough structure to support a wider set of learners without turning the MVP into something heavier than it needs to be.

Either way, the goal stays the same: keep learning, keep the product grounded, and resist the temptation to build ahead of what’s actually been proven.