I built a minimal task manager with Next.js and Turso — here's what I learned

hcacode — Sun, 29 Mar 2026 17:47:42 +0000

The problem

I tried Todoist, Notion, TickTick — all great tools. But I kept spending more time tweaking my system than actually getting things done.

I wanted something dead simple: show me today's tasks, let me check them off, move on.

So I built Daybrick.

The concept

Daybrick is a daily task manager built around one idea: one day at a time.

Duties — areas of responsibility (Work, Health, Learning) that group your tasks
Tasks — scheduled for a specific day, so you only see what matters today
Habits — recurring tasks with streak tracking
Paths — multi-day goals with progress visualization

No kanban boards, no AI, no complexity. Just your day, broken into bricks.

The stack

Next.js 16 (App Router)
React 19
Turso (SQLite at the edge)
Drizzle ORM
Vercel for hosting and cron jobs
Resend for transactional emails
Web Push API for notifications
PostHog for privacy-friendly analytics

Some technical decisions worth sharing

Why Turso over Postgres?

SQLite is fast, simple, and Turso gives you edge replication for free. For a single-user-per-request app like a task manager, it's a perfect fit. Drizzle ORM makes the DX feel no different from Postgres.

PWA over native

I wanted Daybrick on both desktop and mobile without maintaining two codebases. A PWA with a service worker handles push notifications, offline capability, and "Add to Home Screen" — close enough to native for a productivity tool.

Push notifications that actually work

This was the trickiest part. A few gotchas I hit:

Chrome deduplicates notifications by tag — if you send the same tag twice, the second one silently replaces the first. I append Date.now() to make each tag unique.
event.data.json() can crash your service worker — a malformed payload kills the push handler for all future notifications. Always wrap it in try/catch.
Multi-device support — storing a single "notifications enabled" flag per user doesn't work. If you toggle off on your phone, your laptop stops getting notifications too. I store subscriptions per device and check active subscriptions directly.

Localization without URL params

Daybrick supports English and Turkish. Instead of /en/dashboard or /tr/dashboard, the locale is stored in a cookie and the user's DB profile. Cleaner URLs, simpler routing, same result.

Emails that match the user's language

All transactional emails (OTP, welcome, password reset, "we miss you") pull from a centralized i18n module, so a Turkish user gets Turkish emails automatically.

What I'd do differently

Start with semantic release from day one. I added it later and had to retrofit conventional commits. Setting it up early is 10 minutes of work that saves hours.
Don't trust toISOString() for dates. It converts to UTC, which shifts your dates. Use local date methods (getFullYear(), getMonth(), getDate()) when working with calendar dates.
Design your notification system for multiple devices from the start. Retrofitting multi-device support after building around a user-level flag was painful.

The result

I've been using Daybrick daily for my own work. It's minimal, it's fast, and it stays out of my way — which is exactly what I wanted.

If you want to try it: 👉 daybrick.io

It's free. I'd love feedback from the dev community — especially on the UX and mobile experience.

I Built 71+ Free Browser Tools Because Every "Free" Tool Site Is Terrible

hcacode — Tue, 24 Mar 2026 17:35:40 +0000

Every developer has this workflow:

Need to format some JSON
Google "json formatter online"
Land on a site with 47 ads, a cookie banner, and a newsletter popup
Paste your data into a text box that sends it to god knows where
Get your formatted JSON and close the tab in disgust

I got tired of this. So I built FastUtil — a collection of 71+ browser-based utility tools where everything runs client-side. No ads, no sign-ups, no data ever leaves your browser.

What's Inside

Image Tools

SVG to PNG converter
Image resizer & compressor
Favicon generator
QR code generator
Screenshot mockup creator

Developer Tools

JSON formatter & validator
Base64 encoder/decoder
Hash generator (MD5, SHA-1, SHA-256)
Regex tester with live highlighting
JWT decoder
CSS minifier/beautifier
URL encoder/decoder

Text Tools

Markdown editor with live preview
Word & character counter
Case converter
Lorem Ipsum generator
Text diff checker

Color Tools

Color picker & converter (HEX, RGB, HSL)
Palette generator
Contrast checker (WCAG compliance)

And about 40 more — check the full list at fastutil.app.

Why Client-Side Only?

This was rule #1 from day one. When you paste JSON with API keys, or convert an image with sensitive content, that data should never leave your machine. Every tool in FastUtil processes
everything in the browser using JavaScript. There is no backend. No API calls. No analytics tracking your input.

The Tech Stack

For those who care about what's under the hood:

Next.js 16 with App Router
Static generation — 400+ pages pre-rendered at build time
next-intl for i18n across 20 languages
shadcn/ui for the component library
Vitest with React Testing Library (253 tests)
Deployed on Vercel

The i18n Challenge

This was honestly the hardest part. Each tool has its own translation file with:

Tool name and descriptions
All UI strings (labels, placeholders, buttons, error messages)
FAQ content (3-5 Q&A pairs per tool)
Educational content (200+ words per tool)

Multiply that by 20 languages and 71 tools. That's thousands of translation keys. The file structure looks like this:

messages/
en/
common.json
tools/
json-formatter.json
svg-to-png.json
...
fr/
common.json
tools/
json-formatter.json
...
... (20 locales)

A merge script combines everything at load time into the single object that next-intl expects. Keeping all of this in sync is a challenge, but it means the site works properly in Arabic
(RTL), Japanese, Chinese, and 17 other languages.

Static Generation at Scale

Every tool page is generated for every locale at build time:

/tools/json-formatter (English, clean URL)
/fr/tools/json-formatter (French)
/ja/tools/json-formatter (Japanese)
/ar/tools/json-formatter (Arabic, RTL)

That's 71 tools × 20 locales = 1,420+ tool pages, plus home pages, category pages, and blog posts. The build outputs 400+ static HTML files. Everything is fast because there's nothing
to compute at request time.

SEO Architecture

Each tool page is server-rendered with:

Translated metadata (title, description, keywords, OpenGraph, Twitter cards)
JSON-LD structured data (WebApplication + BreadcrumbList + FAQPage)
Canonical URLs and hreflang alternates for all 20 locales
FAQ section rendered on the page (also feeds Google's "People Also Ask")
Educational content section (200+ words of crawlable text per tool)

I also generate llms.txt and llms-full.txt for AI discoverability.

What I Learned

1. i18n is a product, not a feature. Supporting 20 languages isn't just translating strings. It's RTL layouts, different text lengths breaking your UI, date/number formatting, and
cultural context in your content.

2. Static sites can be complex. "It's just a static site" doesn't mean it's simple. The build pipeline, routing, and content management for 400+ pages requires real architecture.

3. Privacy as a feature sells itself. Every time I mention "nothing leaves your browser," people pay attention. In 2026, privacy isn't a nice-to-have — it's a differentiator.

4. One tool leads to another. I started with 5 tools. Then someone asked for a Base64 decoder. Then a hash generator. Then a color picker. 71 tools later, I'm still getting
requests.

What's Next

I'm still adding tools based on what people ask for. Currently working on expanding the developer tools section and adding more converters.

If there's a tool you wish existed — or if you've tried it and have feedback — I'd love to hear it in the comments.

Try it: fastutil.app

No sign-up. No ads. No BS.

DEV Community: hcacode