A Telegram Mini App in plain JavaScript — no build step, no dependencies, no guilt

gordey_pro — Thu, 08 Oct 2026 14:47:14 +0000

PULSAR is a Telegram Mini App for gentle self-tracking: mood, sleep, food, workouts,
tasks, finances, a diary, skills and breathing — and a statistics screen that ties it together. Two decisions shaped it
more than any framework would have.

Decision 1: no build step at all

PULSAR is vanilla JavaScript, HTML and CSS. No bundler, no npm dependencies, no transpiling. Cloudflare Pages deploys
the repository as static files on every push.

What that buys:

Deploys are just files. If something is wrong in production, the file in the repo is exactly what users run.
Nothing to rot. No dependency updates breaking the build a year later.
Fast inside Telegram. A Mini App opens inside a chat; every kilobyte and every request is felt.

What it costs: discipline. Cache-busting is manual — a release bumps every ?v= query in index.html and the version
constant in the app by the same number, or users get a mix of old CSS and new JS. And all storage goes through two
small helpers (one for localStorage, one for Telegram CloudStorage) so data stays isolated per account.

Decision 2: anti-shame as code

Most trackers motivate with guilt: red streaks, "you missed a day", leaderboards. PULSAR does the opposite, and it's
enforced in the code, not just in the copy:

No "you failed" language anywhere. No "you won't make it", no "missed".
Downward changes are muted, not highlighted in red.
Streaks forgive gaps — there's a grace period, so one bad day doesn't erase a month.
Basic tracking is never paywalled.
Statistics compare you only with yourself, and the correlations are deterministic — "based on your data", not a model's guess.

Where AI is allowed

AI is a side dish. A language model may suggest what to log, but it never writes data itself: suggestions appear in a
confirmation sheet, and only the user's tap saves anything.

Design in one theme

One dark "liquid glass" theme over a quiet starry sky, one cherry accent color, large bold type — and no theme picker.
Fewer options meant every screen could be polished instead of every combination being "okay".

Takeaways

For a small Mini App, "no build" is a feature, not a limitation — if you're strict about cache-busting.
If your product is about wellbeing, put the tone rules in code, where they can't drift.
Let AI propose; let the user decide.

I'm Gordey Fisun, I build websites, online stores, Telegram bots and Mini Apps for businesses —
gordey.pro.

Building a notes + whiteboard + graph app where losing data is not an option

gordey_pro — Thu, 08 Oct 2026 14:46:33 +0000

I built OMNI — one web app for documents, whiteboards, databases and a link graph. The editors
were the easy part: I used ready-made ones, BlockNote for documents and tldraw for boards. The hard part was a promise
I made to myself: a user must never lose a note. Not after a crash, not after two open tabs, not after a bad sync.

Here is what that promise turned into in code.

1. One door for every write

All user data lives in IndexedDB (via Dexie), and there is exactly one place that writes it: a VaultRepo module.
Features never touch the database directly. That sounds bureaucratic, but it means every guarantee below is
implemented once, not once per feature.

localStorage is used for one thing only — the UI theme.

2. Every save is atomic and versioned

Each write is a single transaction. Before an entity is overwritten, the previous version goes to its revision list —
up to 30 revisions per entity. Restoring is just another write through the same door.

3. Delete means "move to trash"

There is no hard delete in normal use. Deleted items go to a trash and can be restored; emptying the trash is a
separate, explicit action. Old work that's still useful goes to an archive instead — out of sight, still searchable.

4. Two tabs, no lost edits

Two open tabs editing the same note is the classic way to lose data in a local-first app. OMNI detects the conflict and
keeps both versions instead of letting the last writer win silently.

5. Backup is one JSON file

The whole vault exports to one JSON file and imports back. Boring, and exactly what you want on a bad day.

6. Schema changes only through migrations

The database schema changes only by a new Dexie version with a migration. No "just add a field" — that is how old
data quietly breaks.

7. Tests guard the promise

All of the above is covered by the test suite, and the rule is simple: if a change breaks a data-safety test, the
change is wrong.

Keeping it fast

Boards, documents and the graph are heavy, so each one is a lazy chunk: you only download tldraw when you open a board.
The core (src/core/) has no React and no editor code, and features don't import each other — which keeps the startup
bundle small and the architecture honest.

AI without giving it the keys

OMNI also exposes an MCP server, so an AI assistant can search the vault, read notes and propose changes. Changes the
owner didn't ask for come in as drafts that wait for approval, and every edit still goes through the same door — soft
delete and revision history included — so even an over-eager AI can't destroy anything for good.

Takeaways

Pick one write path and make it the only one.
Make deletion reversible by default.
Treat "two tabs" as a real user, not an edge case.
Use battle-tested editors; spend your effort on the data layer.

I'm Gordey Fisun, I build websites, online stores, Telegram bots and AI assistants for businesses —
gordey.pro.

DEV Community: gordey_pro

A Telegram Mini App in plain JavaScript — no build step, no dependencies, no guilt

Decision 1: no build step at all

Decision 2: anti-shame as code

Where AI is allowed

Design in one theme

Takeaways

Building a notes + whiteboard + graph app where losing data is not an option

1. One door for every write

2. Every save is atomic and versioned

3. Delete means "move to trash"

4. Two tabs, no lost edits

5. Backup is one JSON file

6. Schema changes only through migrations

7. Tests guard the promise

Keeping it fast

AI without giving it the keys

Takeaways