This is not a sales page. It is a straight answer.

Measured
Your site is not a custom application, and that is good news. It is five rented parts stacked on top of a site builder. Each one is a commodity with a replacement, and each one is doing a job for you right now.

One detail worth seeing, because it shows how the site really works: your pages are rendered by a serverless function at Webflow’s origin in the United States, then cached at Cloudflare’s edge for up to five days. One response we measured had been sitting in the cache for about 98,000 seconds. Your marketing pages are, in practice, files that were generated days ago. That is not a criticism — it is the clearest sign that the site is a set of files, and files can be built anywhere.

Everything in that table can be rebuilt. None of it is clever — Webflow renders pages, Outseta takes money, BookWidgets draws quizzes, BunnyCDN sends bytes. Any competent engineer could replace any of the five with something you control, and the whole thing would still be your site.

What cannot be rebuilt is this: 32 free stories across four levels. Two paid courses of 30 stories each. Your own voice, recorded, story by story. The vocabulary you chose to mark in the text. The order you put the stories in. The levels you invented to organise them.

That is the product. The rest is plumbing, and you are currently paying rent on it.

Judgement
There is a second half to this, and it matters as much as the first. Copyright protects your material legally, and it should. Nothing protects it technically today. Your story text is in the page HTML, and your audio and illustrations are served from URLs that require no key, no token and no expiry. We are not going to explain how to retrieve them, and we recommend you do not either. We are going to fix it, as part of this work, and then say it is fixed.

Your content, your app. We build the platform. You keep the material, the accounts and the decisions.

Here is the evidence, in the order that matters.

1. Your content model is small, and that is very good news.

A story on your site is seven fields: the level, the Spanish title, the English title, the body with your key vocabulary marked up inside it, an illustration, an audio file, and a set of practice exercises. Free story bodies run about 125 to 150 words. Course stories run 300 to 350.

Seven fields is small enough to rebuild cleanly. This is the fact that makes everything else on this page possible.

2. Your library is 32 free stories, and they are spread across four levels.

A1 has 10, A2 has 10, B1 has 8, B2 has 4. The story listing page shows 8 of them at once and offers a filter by level. The other two levels’ worth are reachable, but not from the listing page.

You have written fewer stories at the harder levels, which is normal and worth knowing: it tells us where the app’s review queue will run thin first.

3. The paid tier is more and longer stories: 30 stories per course, at $97.

The A1 course page shows $97 in six places in its own HTML, and one search result snippet shows the same price. The course stories are 300 to 350 words, arranged in sequence, with progress tracking, adjustable audio speed, and the full practice set — flashcards, comprehension, patterns, writing, listening and speaking challenges, plus culture sections.

So today, paying gets you more and longer stories. That is a content difference, not a product difference. Section 6 is about changing that.

4. Your exercises are rented. All of them.

Every quiz, flashcard deck and challenge is an iframe from a third-party widget service, and every one of them lives in a single shared teacher account. Free story pages embed two. The course page embeds five or more. The exercise titles we found in your markup cover comprehension quizzes, vocabulary flashcards, pattern drills, listening challenges, a short-story challenge and a mobile flashcard set.

The designs are yours. The runtime is not, and it never will be: an iframe in someone else’s account cannot work offline, cannot schedule reviews, cannot take voice input, and cannot hand progress back to your product.

5. Your audio and illustrations are served from URLs that anyone can request.

We tested one audio file. A request with no referring page attached returned the file, marked as audio, 908,012 bytes — about 0.9 MB — and the response explicitly allowed any website to use it. No key, no token, no expiry. Your audio paths are also completely predictable, organised by level and title.

Your FAQ already states that the content is copyrighted and must not be reproduced. That statement is correct and it is the right thing to publish. On its own, it is not a technical control. Today the protection on your recordings is legal, not technical, and the fix is a small piece of engineering: authenticated, short-lived links issued to people who have paid, an origin that only the delivery network can read, and an alert if the traffic suddenly looks like bulk retrieval. That is in the plan, in Phase 1.

6. There is no app, and there is no sign that there ever was one.

No service worker, no web app manifest, no native client. The only file that looks like a manifest is Webflow’s internal asset list, which is not an app manifest at all. The same file does publicly disclose your content structure — your story collection, your course pages, your dashboard, and a map of your short links.

No app means the app is open ground. Nothing has to be re-implemented, nothing has to be migrated, and nobody is ahead of you.

Two things in there are defects, and they are unrelated to whether you ever build an app.

The first: your public sitemap contains 294 member dashboard URLs. Those are member pages, and they are being handed to search engines for indexing. Out of 343 URLs in the sitemap, 294 are member pages. Estimate
That should not be public and it is a ten-minute fix.

The second: your media is unprotected, as described in point 5. That one is a slightly bigger fix, and it is Phase 1 work.

Neither of these is a reason to panic. Both are the kind of thing that is invisible until someone looks, and both are cheap to close.

Five replacements, one new thing, and one layer you keep. This is the summary — the full reasoning, the trade-offs and the effort estimates are in the technical proposal.

Edge · keep

Cloudflare

Edge, DNS, TLS and bot protection.

Public site

Static site

Plain files for your public pages and your reading experience.

Mobile app

The app

A separate client that reads the same content core.

Owned gate

Accounts and access

Accounts, entitlement and signed asset URLs, under your control.

Rented

Payment provider

Takes the money. Replaceable.

Yours

Content core

One set of stories, written once, used by both clients.

Protected

Media CDN

Audio and illustrations, served only through signed links.

Read that table once more, because there is one line in it that decides how expensive all of this is. “Your stories as structured files in a repository you own” is the line. Everything else is work; that line is the foundation. If the content model is right, the app is cheap to keep fed with new stories forever. If it is wrong, every story you write has to be entered twice, for the rest of the life of the business.

An app is not your website in a wrapper, and the difference is not cosmetic. A wrapper needs the network, cannot schedule anything, and gives you no reason to be opened on a Tuesday morning. Your site is where people find you and study when they have a laptop open. The app is the thing someone opens on the bus, at breakfast, and for the eleven minutes before sleep.

That is a different product, with a different job: bringing the learner back tomorrow. For a business like yours, that is the whole game.

What an app can do that your website cannot.

Judgement
These are engineering assessments of what an app can do.

Study with the network off. Stories, vocabulary and audio downloaded to the phone. A plane, a metro, a village with bad signal. There is no version of this on the web that is as reliable.

Put a short review queue in front of the learner every day. This is the one we would build first. You have already done the hard part: your stories mark their key vocabulary inside the text. Those marked words are a ready-made set of review items — for every free story and every course story you have written. An app can keep track of which words a learner has met, when each one is due again, and hand them twelve words a day that come from stories they actually read. Your website cannot do this, because the memory has to live with the learner and survive between visits and between devices.

Real audio controls. Speed that the learner sets, repeat a single sentence, keep playing with the screen off, controls on the lock screen. Your course already advertises adjustable audio speed. In an app that becomes a real player instead of a web control.

Speaking practice that is actually native. A microphone prompt, a recording, and a score against the text. We want to be straight with you about this one: a first version can honestly score whether the expected words were said, clearly enough, at a reasonable pace. A genuinely good pronunciation score is a research problem measured in months. Ship the honest rough version, then decide if it deserves more.

Progress that follows the learner, and a streak to keep. One account, one word list, one streak, on every device. Read three stories on the train, continue at home.

A library the learner manages. What is on the device, what is new, what can be deleted to free space. A real screen, not a browser cache.

And one more, which matters commercially: the app is the first thing here that cannot be copied by reading your page source. Your site’s HTML is public. A working app with its own review engine and its own data is not.

The data the app needs.

Plain version, no jargon: each story with its level, its two titles, its body with the marked words stored as data rather than only styling, its illustration, its audio, and its exercises. Each marked word as its own item: the word, its dictionary form, its English meaning, the story it came from, and its example sentence. Each exercise in a form a program can read. And on the learner’s side: their account and what they have paid for, an append-only record of what they have studied, the review schedule for each word, their streak, and enough bookkeeping to let two devices agree with each other without losing anything.

Two honest notes on that. Progress events are append-only, so they merge cleanly between devices — that part is easy. Review schedules are not append-only: if two devices disagree about when a word is due, a careless merge silently deletes a learner’s reviews. That is a design decision, made once, properly.

And the cost that grows: an app that lets learners download your whole library multiplies your bandwidth in a way the website never did. Model the worst case — every paying learner downloads everything — before launch, not after.

The decision that is not technical.

Today, paying gets you more and longer stories. The app lets you sell something the website cannot offer at any price: offline study, a daily review queue, speaking practice, streaks. That is a better reason to pay, and it does not require you to write a single new story.

Whether to make that the paid difference is your call, not ours. So is what the app does in its first five minutes, which platform goes first, and what number tells you it worked.

Three phases. Each ends with something you can use, and the third one starts before the second one finishes.

Phase 1 — Your content, in your hands, on your own site.

Estimate
Roughly weeks 0 to 6.

What you get at the end: your public site — the marketing pages and all 32 free stories, level by level, with the same reading experience — rebuilt on a platform you own, with your content stored as structured data instead of living inside a site builder. Your audio and illustrations are no longer retrievable by anyone who guesses a URL. Your 294 member pages are out of the public sitemap. No login, no billing, and nothing to pay a builder for.

Depends on: deciding who owns the content, in writing; deciding where it is hosted; and confirming your levels and reading order. Plus one session to hand us the material.

Phase 2 — Paid access that you control.

Estimate
Roughly weeks 6 to 14.

What you get at the end: a working paid product on your own platform. Real accounts, real checkout, your own access gate, and your courses delivered properly — 30 stories per course, in sequence, with progress and adjustable audio speed. Your exercises stop being third-party iframes and become components you own, and the practice people pay for is finally yours. The same service now answers “may this learner see this?” for the website, and it will answer the same question for the app.

Depends on: Phase 1’s content model. It also needs the exercise re-authoring done — which is evenings of work, not hours — and your decision about how you want to take money.

Phase 3 — The app.

Estimate
Roughly weeks 12 to 30, starting while Phase 2 is still running.

What you get at the end: the product your website cannot be. A learner downloads a story and its audio, studies with the network off, gets a short review queue every day built from the words in the stories they have read, hears the audio with real player controls, practices speaking, and keeps a streak. Their progress follows them between phone and laptop. And it is the first piece of your business that nobody can copy by reading your page source.

Depends on: Phase 2’s accounts and access service, the exercise data from Phase 2, and developer accounts in the app stores.

The estimates above are for one competent developer working full time, and they are estimates rather than measurements. The full breakdown, including the parts that always take longer than people expect, is in the technical proposal.

Below is a working sample of the reading experience we would build. It is small on purpose, and it is real: everything here runs in your browser, with no server behind it.

The text is not yours. It is a short piece of Spanish written for this page, and the audio is a synthetic voice generated on our own machine. Nothing from your stories, your recordings or your illustrations is used anywhere on this site. That is deliberate, and it is how we would expect anyone to treat your material.

What to try, in this order:

1. Tap a marked word in the text. Its English meaning appears, without leaving the page.
2. Press play and listen to the audio read the passage.
3. Flip a flashcard. The cards come from the words marked in the passage — which is exactly how your own stories already work.
4. Watch the progress bar move as you read, and check that it is still there when you reload the page.
5. Turn your network off — airplane mode, or “offline” in your browser’s developer tools — and reload. Everything above still works, including the audio.

That last one is the point of the whole demonstration. It is what your website cannot do, and it is what an app is for.

One more honest note while you are looking at it: the progress you make here is stored only in your browser on this device. It is not sent anywhere, there is no account and there is no tracking on this page.

Scope
This is a demonstration of the reading experience. It is not a preview of the app’s review engine.

Nothing below changes hands in any version of this plan.

Your content. Every story, free and paid. It moves into a form you control, on infrastructure you control, and you can leave with it whenever you want.

Your brand. Your name, your domain, your look, your voice, your level structure, your reading order. You do not become someone else’s brand on someone else’s marketplace.

Your recordings. Your own voice, kept as masters, delivered through a protected path. Nothing is re-recorded, and no synthetic voice ever replaces you.

Your exercise designs. The quizzes, decks and challenges you built are your teaching. They move into a format you own. They are not thrown away.

Your audience. Your learners keep their accounts and their access. Exporting your member list from your current provider is part of the move, and we would treat it as a condition of it.

Your prices. What you charge, whether there is a free tier, whether the app costs more, whether you add a yearly option. All yours. The $97 on your course page is a fact about what you charge today, not a constraint on tomorrow.

Your exit. Every layer in this plan can be left. Payment providers can be swapped, a delivery network is a commodity, and static files with a structured content library can be moved anywhere by anyone.

And one thing to check yourself, because it is the kind of detail that only surfaces years later: confirm you hold the rights to every illustration in your library. Our teardown measured how your images are delivered. It could not tell us who drew them.

This is the whole proposal in five words: your content, your app. We build the platform. You own the material. If this gets built, you should be able to walk away from us as easily as you can walk away from Webflow today.

These are the questions that decide the project. None of them is technical, all of them change the build, and we would rather ask them now than discover the answers in month four.

Who owns the content, in writing? Not “obviously me” — in writing, with the platform separate from the material. This one should be settled before a single file is migrated, including in whatever arrangement you make with us.

What happens if you stop paying each vendor today? Ask it provider by provider while it is a thought experiment rather than an incident. Which part of your business stops working in the first hour? Which parts of it can you take with you, and in what form? The answer to “what happens to my content if I stop paying” is the strongest argument for everything else on this page.

Do you want an app, or a much better website first? Both are defensible. A better website on your own platform fixes the structural problems and costs less. The app is where the growth is — and it needs the website work done first anyway. If you have to pick one to finish, finish the platform, then the app.

What are you actually selling? More and longer stories, as today, or a product the website cannot offer — offline study, a daily review queue, speaking practice. The second is stronger and needs no new writing from you.

What do you want to charge, and how? One-time courses, a subscription, or both. And who handles tax on it: a payment provider that acts as the seller of record, or you.

Who edits the content, and how? A text file per story in a repository is durable and cheap but not friendly. An editing interface is friendly but is another dependency. Do you want to be the editor, or hand this to someone?

Who answers support when something breaks? Access problems, broken streaks, refund questions. This becomes your job the day the gate becomes yours.

What number tells you it worked? Members, courses finished, learners who come back next week. Pick it before launch, or you will not be able to tell whether any of this was worth doing.

Method. Every fact on this page comes from read-only HTTP requests to publicly reachable pages of fluentwithstories.com. We sent ordinary browser user-agent headers and asked for pages and response headers. We did not authenticate anywhere: no login, no account, no password, no member area. We did not circumvent any rate limit or bot protection. We did not download your audio or your images — where we needed to know how media is delivered, we requested one file and discarded the response body, reading only its status and headers. We did not copy any story text, any illustration, any recording or any page copy, and none of it appears anywhere on this site.

What we looked at. HTTP response headers; the HTML of your homepage, a story page, your story listing page, your course page and a member dashboard page; your sitemap; and one file your site publishes that describes its own structure.

What we did not look at, and therefore cannot claim. Your server-side code, your databases, any internal interface between your tools, the detailed configuration of your membership provider, the settings inside your exercise account, your analytics beyond the presence of a tag manager, and any revenue or traffic figures. Nothing on this page is a guess about those. Where we could not measure something, we said so.

Where a number is a judgement rather than a measurement, it is labelled. The engineering estimates in weeks, the “ten-minute fix”, and the claims about what an app can do are assessments. Everything with a figure attached to your site — 32 stories, 10/10/8/4 across four levels, 30 stories per course, $97, 343 URLs in the sitemap, 294 member pages, 125 to 150 words and 300 to 350 words, 908,012 bytes, two widgets on a free story page and five or more on the course page — was measured on 1 November 2026 and can be re-verified by anyone who asks your site the same questions.

Nothing on this page is a suggestion that anyone may take your content. The unprotected state of your media is reported as a defect to fix. The fix is in Phase 1, and it is described as a goal rather than a technique.