FreeSpeech AAC turns a SvelteKit app into an offline-capable AAC board

What FreeSpeech AAC is and where it came from

FreeSpeech AAC is a free and open-source assistive communication app written in TypeScript, and the description in the repository is a free program designed to help the non-verbal. The topics confirm the shape of the thing: aac, communication, pwa, svelte and typescript.

The origin story in the README is the best single sentence about the project. The author created FreeSpeech initially for his sister who is nonverbal, and since then the project has been actively gaining users as the application also serves as a viable alternative to many other expensive pieces of AAC software. That framing explains the feature choices better than any feature list would, because every decision in the app is about a user who cannot type and may be somewhere without a signal.

The client is built on top of Svelte, described as a blazingly fast front-end UI framework, and the package manifest confirms the stack: SvelteKit 2, Svelte 4, Vite 5, TypeScript 5, Tailwind 3 and PostCSS, with the check script running svelte-kit sync followed by svelte-check, and lint running prettier and eslint together. Runtime dependencies include howler for audio, fuse.js for fuzzy search, jszip, image-resize, svelte-file-dropzone and the clsx and tailwind-merge class helpers.

The AI story is in the README too, and it is worth reading precisely. The project packages technologies sourced from AWS, Microsoft Cognitive Services and Google Cloud to give users AI generated voices, and it relies on the OpenAI GPT-3 model to handle complex textual analysis tasks along with phrase and word conjugation.

The primary language is Svelte, the last push was on 2026-10-20, and the release history is short, with 0.0.0.1 from 2021-12-24 and 0.0.0 described as a developer template, a blank home page, from 2021-07-03.

Offline mode, and the boundary the README draws around it

The offline story is the most concrete part of the README, and it is described as a two-part capability.

When a signed-in user opens a communication board, the web app automatically downloads the SvelteKit application shell, every page in that board, and its tile images. The board header reports when that device is ready for offline use. A downloaded board can cold-start from the installed Home Screen app, move between its pages, display cached tile images, and use an available browser or device speech-synthesis voice without a network connection.

The second part is the explicit scope of that mode. Offline mode is intentionally communication-only. Editing boards, opening the dashboard, online image search and cloud voice providers still require a connection, and FreeSpeech falls back to an available device voice if a cloud voice cannot be reached.

That is the correct design for the users the project exists for. A person who cannot speak and is waiting for a carer should not get an error because the wifi dropped, and a device voice is a worse voice but a usable one. What they should not get is a half-working board where the tiles load and the recording does not, and the split into communication-only and everything-else makes that boundary crisp.

The cost is that offline is a per-board, per-device feature rather than a general mode. The shell, the pages and the images are downloaded for the board that was opened, and the header tells the user when that device is ready. A user with many boards has to open each one to have it cached, which is a real piece of onboarding for a carer to handle.

The topics list includes pwa, and the README refers to the installed Home Screen app, so the offline path is a progressive web app install rather than a native application.

Running the project locally and the configuration it expects

The hosting section is short and has three steps: clone and enter into the project directory, install dependencies with yarn install, and run the dev command with yarn dev. The clone command is git clone https://github.com/merkie/freespeech freespeech && cd freespeech, and the README notes in the same list that there is a separate freespeech-api project referenced at the end of the file.

The configuration is a small .env file, and the example file shows the shape of it:

PUBLIC_R2_URL=https://media.freespeechaac.com
PUBLIC_API_URL=https://api.freespeechaac.com

The example also lists the alternatives, with the API URL pointed at https://api.freespeechaac.com for the production server and http://localhost:8172 for local development. The PUBLIC_ prefix on both variables is the convention that SvelteKit uses for values that end up in the client bundle, which is the right convention here because the media host and the API host are both public endpoints rather than secrets.

The scripts in the package manifest show the shape of the workflow. The dev and build and preview commands are the standard Vite ones, so dev is vite dev and build is vite build, and there is a separate check script that runs svelte-kit sync and then svelte-check against the tsconfig, plus a check:watch variant, a lint script combining prettier and eslint, and a format script. The repository also carries a deploy.sh and a .github directory, so there is a deployment path beyond the local one.

The repository top level is a SvelteKit project: src, static, svelte.config.js, vite.config.ts, tailwind.config.js, postcss.config.js, tsconfig.json, plus the package and lock files. It is a front end plus a configured API host, not a self-contained server, which is worth knowing before you try to run the whole thing locally.

Where the AI services actually sit in the design

It is worth being careful about what the README claims, because the phrase about AI generated voices covers two quite different things.

The voices come from third-party providers. The project packages technologies sourced from AWS, Microsoft Cognitive Services and Google Cloud, and the intent is to give users AI generated voices. Those are cloud speech services reached over the network, which is exactly why the offline path has to fall back to a device voice, and why the README's list of what still requires a connection includes cloud voice providers.

The language work is different, and the README attributes it to the OpenAI GPT-3 model for complex textual analysis tasks along with phrase and word conjugation. That is a text model doing conjugation and analysis, which is the part a user might interact with directly when composing a message, for example conjugating a verb to fit a grid or deciding on a phrase.

There is also a client-side element that matters. The runtime dependencies include fuse.js, which is a fuzzy search library, and the README mentions online image search as a feature that requires a connection. So the search inside a board is fuzzy and local, while finding new images to add to a board is remote.

The audio output itself goes through howler, the audio library in the dependency list, which handles the playback of the recorded tile. That separation is sensible: the tiles are cached locally, the images are cached locally, and the voice is the only part that may need the network.

What the README does not describe is the fallback order in detail beyond the device voice, so the quality difference between the cloud voices and the device voice for a particular language is something to check on the target device rather than assume.

Where FreeSpeech AAC is the wrong tool

Three limits, and they are the kind that come with the mission rather than with the code.

The first is that this is a communication aid, not a general AAC platform. A board is a grid of tiles, each one with an image and a spoken label, and the app's job is to let a user pick one and make a sound. If the requirement involves spelling, prediction, scanning with a switch device, or access to a user's own phrase bank, this is the wrong product, because the board model in the README assumes a pre-authored grid of tiles organised into pages.

The second is the dependency on hosted AI services, and this is the part that deserves the most scepticism. The voices come from AWS, Microsoft Cognitive Services and Google Cloud, and the text work comes from OpenAI GPT-3. A project whose stated goal is to be a free alternative to expensive AAC software, and whose offline mode is its most valuable feature, is still built on paid cloud services at the point where voice quality matters most. A family that loses connectivity gets the device voice, which is functional, and a family with connectivity is paying, in someone's cloud bill, for the better voice. The README does not discuss cost, which is exactly the question a family or a clinic would ask.

The third is the version history. The releases are 0.0.0 and 0.0.0.1, both from 2021, while the last push was on 2026-10-20, so the code is being worked on without the project publishing tagged releases to pin. The application version in the package manifest reads 0.0.1, and the project is marked private in the manifest, so it is not published to a registry either. For a piece of assistive technology that people may depend on daily, that is a supply chain question as much as a technical one, and it is worth asking who is running the instance your user depends on.

The alternative approach, for a clinic or a school, is to host the app and the API yourself. The configuration is two public URLs, so pointing PUBLIC_API_URL at your own backend is the whole of the deployment decision, and everything else, the board editor, the cached shell, the device voice fallback, works the same. That is the difference between a free tool and a free tool someone else pays for.

Editorial conclusion

Adopt FreeSpeech AAC if you are building or deploying an augmentative and alternative communication tool for a nonverbal user and you need something that keeps working when the network does not, since the app shell, the board pages and the tile images are cached and the device voice takes over when a cloud voice cannot be reached. Do not adopt it as a general speech synthesis platform or as a board editor, because offline mode is intentionally communication-only and editing, the dashboard, online image search and cloud voices all still require a connection. Verify first that the languages and voices your users need are covered by the providers the project packages, that the device has an available speech-synthesis voice for the fallback path, that your deployment serves the .env configuration correctly, since the media and API endpoints are configured through public variables, and that the licence position is settled, since the README states MIT while the repository carries a custom licence file that GitHub cannot classify.

Frequently asked questions

Official sources

1. Issues
2. Merkie/freespeech on GitHub
3. Project website
4. README
5. Releases