DEV Community: TAMSIV

I Rewrote 3 Detail Screens to Make Them Look Identical — Here's Why That 40-Commit Sprint Was Worth It

TAMSIV — Mon, 20 Apr 2026 15:18:51 +0000

40 commits in 3 days. Zero new features. Just three detail screens rewritten to look identical.

Yes, that sounds absurd when you're shipping solo and every hour matters. But after 6 months of building TAMSIV (a voice-powered task manager), I've learned that the work nobody notices is often the work that keeps an app installed.

Here's what I did, why I did it, and what changed in the codebase.

The problem

TAMSIV has three "detail" screens: Task, Memo, Event. They all show roughly the same things:

Title and status
Who has access (owner + shared groups)
Parent folder in the hierarchy
Tags
Main content
Reminders, attachments, activity log

Each one was built at a different point in the project. Each evolved its own layout, its own section order, its own variants for the same data. Opening a task felt fine. Opening a memo right after felt subtly off. Opening an event after that felt like a third app entirely.

Nobody complained explicitly. That was the clue. Users don't complain about inconsistency — they just get tired and close the app.

Step 1: extract the access tree

The hardest piece was rendering "who can see this". Before the refactor, each screen answered that question differently:

TaskDetail showed an assigned-folder card plus a small "assigned to X" badge
MemoDetail showed a flat list of group members
EventDetail had a detached "Participants" section

I extracted a new component TaskAccessTree with two branches:

<TaskAccessTree
  ownerId={item.owner_id}
  sharedGroups={sharedGroupsWithMembers}
/>
// → Branch 1: owner (avatar + name)
// → Branch 2: each shared group with stacked member avatars

Same component, three screens, zero ambiguity. Users can now tell at a glance who sees a piece of content without reading a line of text.

Step 2: hide empty breadcrumbs

The parent-folder breadcrumb (e.g. Family > Shopping > Supermarket) rendered even when the task was at the root. That left a ghost arrow hanging before the title.

// Before
<Breadcrumb parents={parents} />  // rendered "› › › Title" when parents = []

// After
{parents.length > 0 && <Breadcrumb parents={parents} />}

Two lines. One visual bug gone. An empty space transformed into breathing room.

Step 3: `#`-prefixed tags under a header

Tags used to render as a flat row of words, indistinguishable from body text:

urgent groceries weekend family meals

Now:

<Section title="Tags">
  {tags.map(t => <Chip key={t}># {t}</Chip>)}
</Section>

A clear header, a universal prefix convention. Users recognize tags instantly instead of scanning for them.

Step 4: same section order, everywhere

After refactoring the individual pieces, I enforced a single section order across all three screens:

Title and status (or date for events)
Access tree (TaskAccessTree)
Parent folder assigned
Tags
Main content (description / memo body / event details)
Reminders and recurrence
Attachments
Activity log

The benefit isn't just visual. It drastically reduces the cost of adding a new cross-cutting feature. When I eventually add, say, an "AI summary" or "auto-translated version" section, I code it once and drop it in position 5. All three screens inherit it.

Before, that same feature would have needed three implementations with three position negotiations.

Step 5: extract `GroupMembersSection`

When content is shared in a group, we need to show which members of that group can actually see it (there are fine-grained permissions). This rendering existed in three slightly different forms across the screens.

I collapsed them into a single component:

<GroupMembersSection
  groupId={group.id}
  visibleMembers={membersWithAccess}
  greyedMembers={membersWithoutAccess}
  tapToSelect={canEdit}
/>

Re-used in TaskDetail, MemoDetail, EventDetail, and also in the "Select users to share with" modal. Four callers, one component.

The real benefit: future features now cost 1/3

Here's what sold me on spending 3 days on this.

In the last 6 months, every new feature that touched multiple detail screens took 3x the dev time it should have, because I was reconciling 3 different layouts every time. Reminders, attachments, activity logs, comments, reactions — all of it cost me tax.

Now each new feature drops into one shared layout. I've already measured the effect on the next two features (an inline translation banner and a "recently viewed by" section) — they took a single afternoon each, down from an estimated day-and-a-half before.

Refactors don't just pay for themselves in user experience. They pay for themselves in velocity.

Bonus: 22 SEO redirects

In parallel, I fixed a 22-slug SEO mess on the marketing site. Early translation passes had left obsolete slugs in DE/ES/IT/PT that returned 404s on Google. Each old slug now redirects (301) to its current version, and x-default hreflang is corrected so search engines know the canonical version.

22 visitor paths recovered instead of lost. A good reminder that invisible work isn't only inside the app — it's everywhere your users don't see.

Takeaways

Consistency is invisible value. Nobody says "thanks for the matching section order", but everybody feels when it's there.
Component extraction follows usage, not anticipation. I waited until the same rendering lived in 3+ screens before extracting. Earlier would have been premature.
Refactors unlock velocity. The cost is now. The payoff is every feature after.

TAMSIV is live on the Play Store (Android, free, 6 languages). 780+ commits, still solo. Full write-up of this sprint is on the blog.

What's a refactor you shipped that users never noticed but that changed how you build?

How I Built a Full Transactional Email System in 10 Days (Resend + React Email + Anti-Impersonation)

TAMSIV — Fri, 17 Apr 2026 06:59:12 +0000

10 days. 30 commits. Zero new visible features.

While TAMSIV users were waiting for a new button, a new color or a new voice command, I spent every day rewriting something nobody will ever see: how the app talks to people through email. And I realized the invisible part might be 80% of what makes a product stay installed.

Why build a full emailing system when Supabase Auth already sends verification emails

It's a fair question. Supabase in its default config already sends a verification email on signup. Many products stop there and add nothing else. That's enough to validate an email, not to build a relationship with the user.

In production since April 4, I ended up with dozens of accounts created but not verified. No follow-up. No day-7 feedback to know if the app was useful. No clean way for someone to say "that email wasn't for me." And no admin-side visibility on what was being sent, delivered, bounced or marked as spam.

A homegrown transactional emailing system is exactly what separates a "technically functional" product from one that actually feels serious. Big apps hide it behind polish. Small apps neglect it and lose users without understanding why.

The daily cron that sends one reminder, and only one

The first brick is a daily cron running at a fixed time on Vercel. It queries the database, selects accounts created exactly 3 days ago and still unverified, and triggers a single reminder per user.

The "one reminder only" rule is intentional. I've received more aggressive follow-up emails than I can count. Three in 48h, five in a week, ten over a month. That's the best way to get people to unsubscribe before they've even tried the product.

The cron writes to a dedicated table so it knows who received what and when. If a user was already reminded, they're skipped. If the Resend send fails, the error is logged but the cron doesn't auto-retry: I prefer visibility on failures to silent saturation.

The day-7 feedback loop: 4 buttons, 4 truths

Seven days after signup, each new user receives an email with 4 clickable buttons: love, hate, suggestion, bug. Each button points to a dedicated page that stores the response and offers a free-form comment area.

Why this exact format? Because a Google Play rating is filtered by whoever has the most energy to leave one. An email with 4 buttons captures the silent truth. The truth of people who will never go to the store to write a comment, but can say "I didn't like it" in one click.

Technically, each button carries a signed token scoped to the user and the feedback type. The GET route on the site validates the token, stores the answer with user_id and type, and renders the matching page with a free-form comment area. No extra auth to leave feedback: that's intentional. Friction kills responses.

The anti-impersonation flow: GDPR without drama

Concrete case: someone creates a TAMSIV account with email alice@example.com. But Alice never signed up. She receives a welcome email for an account she never created. What does she do?

Without this flow, she files the email under spam or reports the sender. Either way, it's a loss: loss for me on sending reputation, loss for her since she has no clean way to close the matter, loss for the person who typo'd and will never get communication on the right address again.

In the new version, every welcome email contains an "I didn't create this account" link. Click, dedicated page, confirmation. The signup is immediately deleted from the database, a log is stored for audit, and a closing message confirms to Alice that her address won't be used again. GDPR without drama. One action, three seconds, done.

The page is translated into all 6 languages of the app (French, English, German, Spanish, Italian, Portuguese). Accented characters were broken in some translations due to an encoding issue: fix in commit 12e61a7.

The Resend webhook: know before the user writes

All sends go through Resend, a developer-first transactional email provider. Resend exposes webhooks for every lifecycle event: email.sent, email.delivered, email.opened, email.clicked, email.bounced, email.complained, email.delivery_delayed.

All of them are listened to and stored in a dedicated table with the user reference, email type, timestamp and associated metadata. This lets me aggregate: how many emails arrived today, how many were opened, which ones generated a click, how many bounced.

The admin dashboard shows these stats in real time with badges that increment on every send. A bounce appears on a user? I see it immediately, I can check whether it's a temporary issue or a dead email, and adjust. A complaint (spam mark)? High priority, immediate investigation.

The per-user grouped send history, with resend and dedup

The admin sees all recent sends, but grouped by user. If Alice received her verification email then her day-3 reminder then her day-7 feedback, I see one "Alice" row with three sub-rows that expand. More readable than a raw chronological feed.

Each send has a "source" badge (auto / manual). Automatic sends (cron, triggers) are separated from manual ones (a "resend" button in the admin). A "resend" button exists on every row for the cases where an email landed in spam, or to force a retry on a different alias, or to test a template change.

A dedup system prevents re-spamming: if I sent a welcome email 2 hours ago and I want to do a bulk "all today's signups" send, Alice is excluded automatically because she already received one. An "eligible" badge shows on every user to indicate whether they can receive the ongoing send or not.

Two mobile hotfixes in parallel: v1.07 and v1.08

While the email backend was moving forward on Vercel, the mobile app needed air. Two releases went out on Play Store Alpha, then production.

v1.07 (7d65fd0): 8 targeted bug fixes, plus a new compact view inside folders. When you have 15 sub-folders in a project, you want to see the whole tree at a glance without scrolling. A toggle switches between detailed view (full cards with thumbnails and previews) and compact view (dense rows with just name and count). Zero new visible feature, but a shift in usage for heavy users.

v1.08 (a494e7e): full gesture-handler audit. TAMSIV uses react-native-gesture-handler everywhere, but several screens still had TouchableOpacity or FlatList imported directly from react-native. Result: intermittent taps that didn't register, impossible to reproduce, reported by users who eventually uninstalled without understanding why.

The audit touched 25+ files. Every TouchableOpacity, every FlatList, every ScrollView was switched to the gesture-handler import. The ghost tap bug is fixed. While we were at it, we redesigned the Feed UI and stabilized all modals: in the process, polish takes a clear jump.

What I take away after 10 days

What struck me is that every line of code written during these 10 days will stay invisible as long as it works. Nobody says "wow, your verification email arrived at the right time, once, in the right language." Nobody notices that a bounce was automatically detected and the admin saw the signal before the user even wrote.

The invisible only gets noticed when it breaks. And at that moment, the user doesn't understand what failed: they just feel the app "isn't working well." They uninstall. They don't write. They don't say why.

So the invisible might be 80% of what makes a product feel finished. Not the buttons you ship in feature releases, not the colors you repaint, not the animations. Just the fact that when something should reach the user, it reaches them. At the right time. Once. In the right language.

Not sexy to post on LinkedIn. But that's what keeps a product installed.

Want to see how it looks from the user side? TAMSIV is on Play Store and live at tamsiv.com. If you're building your own emailing stack, I'd love to hear how you handle the invisible part.

I Vibe-Coded a Voice AI Task Manager. Here's What AI Gets Right — and Where It Falls Short.

TAMSIV — Fri, 10 Apr 2026 09:09:41 +0000

Last October, I discovered Claude Code and thought: "I'll build a full mobile app solo in weeks." React Native, Supabase, WebSocket, voice pipeline. AI will handle everything.

The first hours were magic. Boilerplate that takes 2 days? Done in 20 minutes. A React Native component with error handling, TypeScript types, responsive styles. Almost perfect on the first try.

Then I started building for real.

The Frankenstein problem

AI generates 400 lines for a screen. It works. Next screen. Works too. You keep going. After 3 weeks: 50 generated files, 15 services, 8 React contexts.

And then you realize something.

Nobody thought about the architecture. Not the AI. Not you either, because you were moving too fast. You have a functional Frankenstein monster. Each piece works individually. Together, it's spaghetti.

I spent more time refactoring AI-generated code than I would have spent writing it myself. That's the sentence nobody says about vibe coding.

What AI actually does well

The repetitive, well-defined stuff. That's where it's a genuine 10x multiplier:

Boilerplate: component scaffolding, CRUD operations, API endpoints
SQL migrations: schema changes across 3 database schemas, 30+ tables
Translations: 1,993 keys across 6 languages (FR, EN, DE, ES, IT, PT)
Tests: unit tests, edge cases, mocking
Documentation: README updates, inline docs, API specs

No exaggeration on the 10x. These tasks went from hours to minutes.

What AI misses: decisions

The hard questions. The ones where "it depends" is the honest answer:

What database architecture keeps 30 Supabase tables maintainable in 6 months?
How do you structure a voice pipeline (STT, LLM, TTS) so it stays modular?
Where's the boundary between a WebSocket backend and a React Native frontend?

AI gives you an answer. Often plausible. Rarely the right one. And if you lack the experience to spot the difference, you find out 200 commits later when everything is coupled and nothing is testable.

The balance I found (900+ commits later)

Six months and 900+ commits into building TAMSIV (a voice-powered task manager for Android), here's my workflow:

Let AI generate the skeleton. First draft, boilerplate, repetitive patterns.
Review every structural decision myself. Architecture, data flow, service boundaries.
Refactor early, not late. The moment something feels wrong, fix it. Don't wait for 50 more files to depend on it.
Never confuse execution speed with thinking speed. Vibe coding accelerates the first. Not the second.

The real takeaway

AI didn't replace the developer. It replaced the parts of the job I didn't enjoy. The rest, the hard choices, the architecture trade-offs, the UX that makes someone come back tomorrow, that's still on you.

Vibe coding is a multiplier, not a replacement. And the multiplier only works if you know what you're multiplying.

TAMSIV is a voice-powered AI task manager for Android. Free on the Play Store. Built solo with React Native, Supabase, and a lot of refactoring.

I Removed Anonymous Sessions One Week After Launch — Here's Why

TAMSIV — Thu, 09 Apr 2026 16:04:50 +0000

TAMSIV launched on the Play Store on April 2nd. One week later, I ripped out one of the original features: anonymous sessions.

Here's the story, and what I learned.

The original idea

When I started building TAMSIV (a voice-powered task manager), I wanted zero friction. Open the app, talk, done. No signup wall. No email. Just start using it.

Supabase makes this easy with anonymous auth. A temporary user is created, they get a JWT, they can use the app. If they decide to stay, they convert to a real account later.

It sounded perfect on paper.

What actually happened

In production, anonymous sessions created more problems than they solved.

Data loss risk. Anonymous users who cleared their app data or switched phones lost everything. No email, no recovery path. Support nightmare waiting to happen.

Personalization was broken. The AI voice assistant uses a custom context per user (name, preferences, voice settings). Anonymous users had none of this. Their experience was generic, which is the opposite of what TAMSIV promises.

Analytics were useless. I couldn't tell real users from drive-by installs. My funnel metrics were polluted. How many people actually tried the voice feature? No idea, because half the "users" were anonymous ghosts.

Conversion tracking was impossible. RevenueCat needs a real user ID. Firebase events were tied to anonymous IDs that could never be linked to a paying customer.

The decision

One week after launch, with 750+ commits behind me, I made the call: remove anonymous sessions entirely. Require signup or login upfront.

The commit was 7a0101d: feat(auth): remove anonymous sessions, require signup/login upfront.

It felt scary. Every growth guide says "reduce friction, remove signup walls." But the data said otherwise. The friction of a broken experience was worse than the friction of a signup form.

What changed

The signup flow is simple: email + password, or magic link. Takes 15 seconds. And once you're in:

Your AI assistant knows your name from day one
Your data is tied to a real account, recoverable
Analytics actually mean something
RevenueCat tracks real humans

I also fixed a related bug in the same sprint: the terms & conditions modal was flashing briefly on every app launch (8979543). The fix was simple, wait for the fresh DB profile before deciding whether to show the modal. But it was the kind of thing that makes an app feel broken.

The lesson

"Zero friction onboarding" doesn't mean "no signup." It means "the signup should be worth it." If your anonymous experience is degraded compared to your authenticated one, you're not reducing friction. You're just delaying disappointment.

v1.04 (versionCode 39) shipped with these changes. The app feels more intentional now.

TAMSIV is a voice-powered task manager with AI, unlimited folder hierarchy, and real-time collaboration. Free on Google Play.

750+ commits, solo dev, 6 languages. If you're curious: tamsiv.com

From Idea to Production in 6 Months — A Solo Developer's Journey

TAMSIV — Sat, 04 Apr 2026 07:04:27 +0000

Six months ago, I had a sticky note problem.

My wife would add "kid's shoes" to the grocery list while I was driving. I couldn't write anything down without stopping, unlocking my phone, opening an app, typing... So I opened VS Code. And didn't close it for 6 months.

Today, TAMSIV is live on Google Play Store. In production. For everyone.

What is TAMSIV?

A voice-powered task and memo manager with conversational AI. Press the mic, speak naturally, and the AI creates tasks, memos, or calendar events — organized in the right folder, with the right priority, at the right time.

The stack

Frontend: React Native 0.81 (TypeScript, New Architecture / Fabric)
Backend: Node.js/Express + WebSocket, port 3001
Database: Supabase PostgreSQL — 3 schemas (privat, collaborative, gamification), 30+ tables, 40+ RLS policies
AI: OpenRouter (400+ models), native on-device STT, OpenAI TTS (6 voices)
Website: Next.js 16 + Tailwind CSS 4 on Vercel
Payments: RevenueCat (Free / Pro / Team)

750+ commits, 25 features shipped

Here's what made it to production:

🎙️ Conversational voice AI with 8 function tools
📋 Tasks and memos with photos, videos, PDFs
📅 Calendar with 5 views, recurrence, smart reminders
👥 Real-time collaboration (groups, assignments, checklists)
📁 Unlimited hierarchical folders
🏆 Gamification — 12 levels, 10 badges, streaks up to 365 days
🌍 6 languages (FR, EN, DE, ES, IT, PT)
🖥️ Full web companion app at tamsiv.com
🎨 AI-generated images (Runware HiDream)

The bugs that almost killed launch

6 hooks DDoSing my own database on startup. Six independent React hooks calling getGroups() concurrently. Six identical Supabase queries saturating the connection pool. Fix: one shared GroupsContext.

AI inventing impossible dates. February 29 on non-leap years, "Monday the 15th" that was actually a Wednesday. Fix: server-side validateAndFixDate() + pre-computed day tables in the prompt.

WebSocket callback conflicts. The AI setup screen and dictaphone fighting for the same channel. 3 hours to isolate.

i18n as an acquisition channel

Before launch, I translated everything into 6 languages. Result: 60% of website visitors don't speak French. Germany is the 3rd largest market — without a single German social post. Every language is a door.

What's next

TAMSIV is free — all core features work without paying. iOS is planned.

If you're a developer, the technical decisions are real, the bugs are real, and the code is production code.

If you need a voice-first task manager, give it a try and break things.

📱 Download on Google Play
🌐 Website
▶️ Demo video

Built solo. 750+ commits. October 2025 → April 2026.

38 Commits, Zero New Features — How I Made My Web App Production-Ready

TAMSIV — Wed, 01 Apr 2026 08:07:32 +0000

Sometimes the most important sprints are the ones where nothing new gets shipped.

38 commits in 10 days. Zero new features. But TAMSIV's web dashboard went from "it works" to "it's ready."

The Agenda Gets Real

The web agenda had one view — week. Functional, but limiting. Now it has four: day, week, month, year. Click any event, see its details. Click any task, same thing. Task and memo detail pages were completely redesigned to match the mobile app.

The goal: make the transition between phone and desktop invisible. You create a task by voice on your phone, you find it on your computer with the same layout.

Safety Nets: Crashlytics + Sentry

When your app is used by you and 12 testers, you can debug via Supabase logs and "works on my machine." When you're about to go public, that's not enough.

Two monitoring systems were added:

Firebase Crashlytics on the React Native frontend — catches crashes, ANRs, uncaught JS errors, with full stack traces
Sentry on the Node.js/Express backend — catches API errors, WebSocket timeouts, unhandled exceptions, with breadcrumbs and performance monitoring

When a bug happens in production, we know before the user complains.

The AI Learns Your Naming Habits

One commit. But the kind that changes daily experience.

The voice assistant now analyzes your existing folder names to detect naming patterns. If all your grocery folders start with the store name ("Groceries Carrefour", "Groceries Leclerc"), the AI picks it up and suggests the same pattern for new folders.

No user will ever ask for this. But everyone notices when it's there.

Performance & CRO

The landing page hero used a JavaScript Canvas for its animated glow effect. Beautiful, but heavy — especially on mobile. Replaced with pure CSS. Same visual, zero battery drain.

Other landing page fixes: hero subtitle rewritten for clarity, pricing layout improved, header scroll spy fixed.

Smarter Tracking

UTM parameters on every shared link — to know which post, channel, campaign drives traffic
Server-side IP capture — more reliable than client-side JavaScript
Admin dashboard — period selector (7d/30d/90d/all), config synced between mobile and web

versionCode 32

Build 32 on the Play Store. 740+ commits. Production review pending at Google. We polish, we wait, we polish again.

38 commits, zero features, and an app that went from "it works" to "it's ready."

📖 Full article on the blog: tamsiv.com/en/blog
📱 Try it: Play Store

I Translated My App Into 6 Languages Before Launch. Here's What the Data Says.

TAMSIV — Tue, 31 Mar 2026 08:58:54 +0000

Everyone told me I was crazy.

"You haven't even launched in France yet, and you're translating into German?"

I did it anyway. Here's what happened.

The Decision

TAMSIV is a voice-powered AI task manager I've been building solo for 6 months (730+ commits). When I hit the i18n milestone, I had a choice: launch in French first and "see how it goes," or go all-in on 6 languages from day one.

I chose the second option. I wrote an AI translation script that processes 1,993 keys across 5 target languages (English, German, Spanish, Italian, Portuguese) using OpenRouter. I localized the Play Store listing. The website. Even the voice assistant understands context in multiple languages.

Total investment: about 2 days of work.

The Data (41 days of tracking)

Here's what tamsiv.com analytics show after 41 days:

2,206 unique visitors total
1,142 unique visitors in the last 7 days alone

But the number that stopped me:

60% of visitors don't speak French.

Language breakdown (last 7 days)

Language	% of traffic	Unique visitors
🇫🇷 French	40%	440
🇬🇧 English	20%	226
🇩🇪 German	13%	150
🇪🇸 Spanish	10%	118
🇮🇹 Italian	9%	113
🇵🇹 Portuguese	8%	98

Germany is the third largest market. I never wrote a single German social media post. Zero German marketing. These visitors found TAMSIV through:

Localized Play Store listings — each language has its own title, description, and screenshots
Google searches in their language — the website auto-detects and serves the right locale
Automatic language routing — tamsiv.com detects browser language and redirects

The Technical Setup

Translation script

I use OpenRouter with a configurable model to translate JSON key files:

// Pseudo-code of the translation pipeline
for (const locale of ['en', 'de', 'es', 'it', 'pt']) {
  const translated = await openrouter.chat({
    model: process.env.OPENROUTER_MODEL,
    messages: [{
      role: 'system',
      content: `Translate to ${locale}. Keep placeholders like {name} intact. Adapt idioms naturally.`
    }, {
      role: 'user', 
      content: JSON.stringify(frenchKeys)
    }]
  });
  writeFile(`locales/${locale}.json`, translated);
}

Key decisions:

French as source language (not English) — my native language, so the source is always natural
AI translation with human review — I review German/Spanish/Italian with native speakers when possible
9 passes per language — the script runs multiple passes to catch context-dependent translations
Placeholder preservation — {taskCount} tâches must become {taskCount} tasks, not {taskCount} Aufgaben tasks

Play Store localization

The Play Store supports per-language metadata. I localized:

App title (30 chars)
Short description (80 chars)
Full description (4000 chars)
Release notes

This is probably the highest-ROI i18n work. People search the Play Store in their language. If your listing isn't localized, you're invisible.

Website (Next.js + next-intl)

/fr/  → French (default)
/en/  → English
/de/  → German
/es/  → Spanish
/it/  → Italian
/pt/  → Portuguese

Each locale has its own translated slugs, meta descriptions, and Open Graph tags. The x-default hreflang points to /fr/ (primary market).

The Surprising Insight

The most visited non-homepage pages are:

/fr/politique-de-confidentialite (165 visits)
/fr/suppression-compte (92 visits)

These are Play Store required pages (privacy policy, account deletion). Their high traffic confirms that people are finding TAMSIV through the Play Store, clicking these links, and landing on the website. The Play Store localization is driving real traffic.

Another Data Point

12 people clicked "Download for iOS." The app is Android-only.

12 strangers, somewhere in the world, want TAMSIV on iPhone. That's not a metric — that's a roadmap.

The Lesson

i18n is not polish you add after launch. It's an acquisition channel.

Every language is a door. I spent 2 days opening 5 extra doors, and 60% of my traffic walks through them.

If you're building a side project and thinking "I'll translate later" — consider translating now. The Play Store alone makes it worth it. And with AI translation tools, the cost is nearly zero.

What's Next

Production release is pending (waiting for Google Play review)
iOS version is now on the roadmap (thanks to those 12 clicks)
German-language content might be worth creating (13% is significant)

TAMSIV is a voice-powered AI task manager — speak your tasks, memos, and calendar events instead of typing them. Free on Android.

🌐 tamsiv.com
📱 Play Store

How I Added Voice-Based AI Personalization Two Days Before Launch

TAMSIV — Sun, 29 Mar 2026 08:47:35 +0000

Since October, TAMSIV's voice AI understood commands perfectly. "Create a task", "add a memo", "check my schedule" — all worked. But the AI didn't know the user.

Say "remind me about the thing for the kids" and it had no idea you had kids.

Two days before public launch, I shipped voice-based AI personalization.

Configure Your AI by Talking to It

A new screen: "Configure my AI". You tap, you talk:

"I'm a parent of 3, I manage a cleaning crew of 4, and I forget everything after 30 seconds."

The AI listens, summarizes your context, stores it. From that point on, every response is tailored. "The little one" means your son. "Tuesday's site" means your field intervention.

The implementation: the custom context is sent as part of the system prompt to OpenRouter. The LLM sees it on every conversation turn. Simple, but the UX around it — the onboarding flow, the voice recording, the save/edit/delete — that's where the 1,800 lines went.

6 TTS Voices with Live Preview

Voice is personal. The same robotic voice 50 times a day gets old.

I added a voice selector: 6 OpenAI TTS voices, each with a live preview button. Tap → hear "Hello, I'm your TAMSIV assistant" in that voice → choose. Saved to the user profile, used for all responses.

The tricky part: the preview uses the same WebSocket pipeline as the main dictaphone. Which led to...

The 3-Hour WebSocket Bug

The AI setup screen and the dictaphone share one WebSocket connection. When you preview a voice in setup, the dictaphone's callbacks also fired — processing audio meant for the setup screen.

Fix: an "active owner" pattern. When setup opens, it claims exclusive WebSocket ownership. The dictaphone's callbacks become no-ops until setup closes. Clean in theory, 3 hours of debugging because the conflict only appeared on specific Android models with aggressive garbage collection.

Personalization as a Feature Gate

AI personalization is now part of the Pro/Team plans in the pricing. Free users get basic context, paid users get full customization + voice selection. Added to the pricing page on the website too.

730+ Commits, Monday Is Launch Day

This was the last feature. The app now knows who it's talking to.

Monday, TAMSIV goes public on the Play Store. 6 months of solo development, and the AI finally has context.

TAMSIV is a voice-powered task and memo manager with AI. Try it on Android or visit tamsiv.com.

Vanishing Reminders and Missing Emails — The Never-Ending Quality Sprint

TAMSIV — Thu, 26 Mar 2026 09:16:49 +0000

When you're building an app solo, some weeks you ship shiny new features. Other weeks, you spend your evenings hunting bugs nobody reported — because you found them yourself while dogfooding your own app. This was the second kind of week on TAMSIV.

Here's a rundown of four fixes that look small on their own. But stacked together, they genuinely improve the daily experience.

Reminders That Vanished Into Thin Air

The scenario: you create a task with three reminders — one in 10 minutes, one tomorrow morning, one on Friday. But the first reminder is already in the past (you took too long to confirm). TAMSIV would display a warning: "This reminder is in the past." Fair enough.

The problem? Dismissing that warning wiped all reminders. The two perfectly valid future reminders were gone too. An overzealous cleanup in the validation logic.

The fix now clearly separates past reminders from future ones. The warning only targets what's actually expired, and upcoming reminders stay untouched.

Email Reminders That Never Arrived

TAMSIV supports two notification channels for reminders: push and email. In practice, when a user created a reminder, only the push channel was enabled by default. Email? Silently disabled.

Now both channels are enabled by default. You get a push and an email.

The Ghost Error on Cold Start

You open the app after a few hours of inactivity, and for a split second an "Invalid Refresh Token" error flashes on screen. Then everything works fine.

On cold start, Supabase tried to refresh the auth token. If it had expired, the SDK threw an error before the automatic reconnection mechanism had time to kick in. The error bubbled up to the UI when it had no business being there.

The fix intercepts this specific error at the right level and suppresses it from the display.

Badge Guide Translated Into 6 Languages

TAMSIV is available in French, English, German, Spanish, Italian, and Portuguese. But the badge explainer guide only existed in French and English. Fixed — all 10 badges are now translated into all 6 languages.

What's Next?

These four fixes represent roughly a day's work. None of them would make for an exciting changelog headline. But together, they eliminate real friction.

The quality sprint continues. 720+ commits and counting.

📖 Full article on the blog
📖 New: Productivity App Fatigue
📲 Try TAMSIV on Android

TAMSIV Has a Face — First Demo Video + Quality Sprint

TAMSIV — Wed, 25 Mar 2026 13:16:07 +0000

For 6 months, TAMSIV existed only as text and screenshots. Today, for the first time, the app has a face: a full demo video.

Why a video now?

A voice app needs to be seen. Reading "speak, AI understands and organizes" isn't enough — you need to see the mic activating, the real-time transcription, the task being created automatically in the right folder.

The video shows all of that in 2 minutes. It's now embedded directly in the website's hero section.

Quality sprint: 7 commits, 0 new features

Alongside the video, I spent a week on a 100% quality sprint. No new features — only polish, reliability, and silent fixes.

Dictaphone: 100% reliable stop button

The most frustrating bug: sometimes the "stop" button wouldn't respond. The mic kept recording, forcing users to kill the app.

The cause? A timing issue between native STT initialization and React state. The fix:

A "standby" mode for native STT — ready instantly without blocking the UI
Recording start 2x faster (no callback wait)
A stop button that works 100% of the time

Multi-day voice agenda queries

Previously, asking "what do I have this week?" only worked for a single day. Now the assistant understands ranges: "Monday to Friday", "the next 3 days", "this week".

AI images: switch to HiDream-I1-Fast

Folder cover images are AI-generated. SDXL 0.9 poorly understood complex prompts. HiDream-I1-Fast: better comprehension, more consistent results, ~$0.003 per image.

Folders: instant display

In collaborative groups, the folder tree waited for all content to load. Now it shows instantly — content loads in the background.

Security: data leakage fix

Critical bug: on shared devices, previous user's data could briefly appear when switching accounts. The singleton cache wasn't cleared on logout. Fixed with complete state cleanup.

What I take away

A quality sprint isn't glamorous. No new feature, no before/after screenshot. But it's what separates an app people try from an app people keep.

The video is the opposite: the moment the project becomes tangible for someone who's never touched it. Both complement each other — the storefront and the foundation.

📲 Try TAMSIV on Google Play
🌐 Website
📖 Full blog post

Why Productivity Apps Fail with ADHD — and the 3 Principles That Actually Work

TAMSIV — Mon, 23 Mar 2026 11:40:01 +0000

On Reddit, the same post shows up every week. Someone writes: "I downloaded a new productivity app. The first three days were amazing. Now it's collecting dust on my phone."

If you have ADHD, you know this cycle by heart. Download → get excited → forget → feel guilty → avoid → uninstall. And start over with the next "miracle" app.

The problem isn't you. It's that 95% of productivity apps are designed for neurotypical brains.

The real problem: friction

Open the app. Find the right list. Tap "+". Type the task. Pick a date. Select a category. Six steps. For an ADHD brain, that's five too many.

Each step is a chance to get distracted, lose your train of thought, or tell yourself "I'll do it later" — which means never.

Apps like Todoist, TickTick, or Notion are great for people who enjoy organizing. But with ADHD, the problem isn't organizing — it's capturing before the thought disappears.

Principle 1: Reduce friction to zero

Capturing should take less than 5 seconds. Period.

The fastest method: voice. You think something, you say it out loud, it's recorded. No screen to navigate, no text to type, no category to choose.

Apps like TAMSIV or even Google Tasks' voice input allow this. The goal isn't to find the perfect app — it's to find the one that puts the fewest barriers between your thought and its capture.

The test is simple: if you have to think about HOW to note something down, the app has already failed.

Principle 2: Make progress visible

The ADHD brain needs immediate feedback. A shrinking task list isn't enough — we need to SEE that we're making progress.

That's why gamification works surprisingly well:

Streaks: "Day 27 without breaking the chain" creates a loss aversion that's more motivating than any to-do list.
Levels: Going from "Beginner" to "Organizer" to "Expert" — the brain loves progression narratives.
Badges: Visual rewards for specific actions. It sounds childish, but it activates the reward circuit exactly the right way.

Habitica does this with an RPG angle. TAMSIV does it with levels and daily challenges. Even a simple counter of completed tasks on a sticky note can work. What matters is that progress is VISIBLE.

Principle 3: Flexibility without guilt

Apps that punish you for missing a day are toxic for ADHD. You miss Monday, feel guilty Tuesday, avoid the app Wednesday, and it's over.

The app that works for ADHD lets you pick up where you left off. No passive-aggressive "You missed 3 days!" message. No streak reset without a safety net.

Moving a task to tomorrow isn't failure — it's realistic planning.

Capture first, organize later

The classic trap: trying to organize AT THE MOMENT you capture. "Which folder does this task go in? What priority? What date?"

Stop. Capture first. Organize during a dedicated moment (5 minutes in the morning or evening). These are two different mental modes, and mixing them is exhausting for an ADHD brain.

With voice capture, it's natural: you speak, it's captured. You organize later, with a clear head.

What really matters

The perfect app doesn't exist. But apps that work with ADHD always have these three things: minimal friction, visible progress, flexibility without judgment.

If your current app makes you feel guilty when you open it, it's not the right one. Switch. Test. The right app is the one you still open 30 days from now.

How I Gave My Voice AI the Ability to Read Your Schedule (Not Just Write To It)

TAMSIV — Mon, 23 Mar 2026 08:26:38 +0000

For five months, my voice AI assistant could create tasks, memos, and calendar events. It could write. But it couldn't read.

If you asked "What do I have tomorrow?", it had no idea. It only knew write commands — create, update, delete. Your actual schedule? Completely opaque.

This week I changed that. Here's how.

The Problem

My app TAMSIV uses a voice pipeline: audio → Deepgram STT → OpenRouter LLM → function calling → OpenAI TTS. The LLM has 7 function tools: create_task, update_task, create_memo, update_memo, create_calendar_event, ask_clarification, end_conversation.

All write operations. The AI could create things in your schedule, but couldn't tell you what was already there.

The Solution: An 8th Tool

I added query_agenda(startDate, endDate) — a read tool.

When you ask "What's on my plate this week?", the LLM:

Parses your intent and calls query_agenda with the right date range
A Supabase RPC function queries three tables: privat.tasks, privat.calendar_events, and privat.memos
Returns structured data: tasks with due dates, events with times, memos with timestamps

But raw data isn't useful as a voice response. Nobody wants to hear "Task ID 47, title grocery shopping, due date 2026-03-24T10:00:00Z."

The 2nd LLM Call

This is where it gets interesting. The orchestrator makes a second LLM call — taking the raw agenda data and generating a natural vocal summary:

"Tomorrow you have three things. In the morning, grocery shopping. At 2pm, a dentist appointment. And you still have that memo about calling the insurance company."

Natural. Conversational. Adapted for voice.

The Architecture Change That Surprised Me

The FunctionExecutor — the component that runs tools — was synchronous and had no database access. It only returned instructions that the frontend would execute.

For query_agenda, the backend needed to query Supabase directly. So the FunctionExecutor became async, with access to the Supabase client and userId.

// Before: synchronous, no DB access
executeTool(name: string, args: object): ToolResult

// After: async with DB context
async executeTool(
  name: string, 
  args: object, 
  supabase: SupabaseClient, 
  userId: string
): Promise<ToolResult>

This opened the door for future read tools — the AI can now query anything server-side.

The RPC Function

The Supabase RPC crosses three tables in a single query:

CREATE OR REPLACE FUNCTION get_user_agenda(
  p_user_id UUID,
  p_start_date TIMESTAMPTZ,
  p_end_date TIMESTAMPTZ
) RETURNS JSON AS $$
  SELECT json_build_object(
    'tasks', (SELECT json_agg(...) FROM privat.tasks WHERE ...),
    'events', (SELECT json_agg(...) FROM privat.calendar_events WHERE ...),
    'memos', (SELECT json_agg(...) FROM privat.memos WHERE ...)
  );
$$ LANGUAGE sql SECURITY INVOKER;

Using SECURITY INVOKER means RLS policies are enforced — users only see their own data, even when the backend calls this function.

Frontend: No PendingCreation

Every other tool creates a PendingCreation — a preview the user validates before it's saved to the database. But query_agenda doesn't create anything. The frontend just needs to handle the agenda_queried action by... doing nothing. The voice response is the result.

The Bigger Picture

This changes the nature of the voice assistant fundamentally. Before, it was an input device — you talk, it writes. Now it's a conversational partner — you ask, it answers.

"What do I have this week?" → vocal summary
"Create a task: buy flowers for Friday" → creates task
"Actually, what else is on Friday?" → checks and responds
"Add a reminder for 5pm" → creates event

The conversation flows naturally because the AI can both read and write.

700+ commits. Solo dev. Production in 5 days.

If you're building voice AI features, the key insight is: read tools change everything. An AI that can only write feels like a command interface. An AI that can read and write feels like an assistant.