DEV Community: Fatih Kurt

[Boost]

Fatih Kurt — Tue, 26 May 2026 08:08:09 +0000

Fatih Kurt

May 21

I Built and Shipped TinyHab: an ADHD-Friendly Habit Tracker for iOS

#mobile #flutter #ios #productivity

Comments

4 min read

I Built and Shipped TinyHab: an ADHD-Friendly Habit Tracker for iOS

Fatih Kurt — Thu, 21 May 2026 19:13:43 +0000

I recently shipped TinyHab, an ADHD-friendly habit tracker for iPhone.

The idea was simple: most habit apps look clean on day one, but they become stressful the moment you miss a day. I wanted to build something calmer. Something focused on today, small wins, reminders that actually work, and a recovery path when routines fall apart.

So I built the full product myself: the iOS app, backend, landing page, admin panel, push notifications, subscriptions, App Store setup, and the release process.

App Store link: https://apps.apple.com/app/tinyhab-adhd-habit-tracker/id6770136917

The Stack

TinyHab is built with:

Flutter for the iOS app
Django for the backend API and admin panel
PostgreSQL for the database
Firebase Auth / Cloud Messaging for auth support and push notifications
Apple Sign In and Google Sign In
RevenueCat for App Store subscriptions
Dokploy + Docker for deployment
Django Admin for managing users, campaigns, tokens, and notification logs

I like this stack because it lets me move fast without giving up structure. Flutter gave me a clean app surface, Django gave me a reliable backend and admin panel, and Firebase/RevenueCat handled the parts that are painful to rebuild from scratch.

What I Wanted the App to Feel Like

TinyHab is not trying to be a loud productivity app.

I wanted the app to feel quiet and practical. The core flow is:

Open the app
See what matters today
Mark a habit done
Move on

No guilt-heavy streak system. No overwhelming dashboard. No complicated setup before the user gets value.

The app includes habit scheduling, daily progress, reminders, insights, profile settings, App Store subscriptions, home screen widgets, and a small admin system behind the scenes.

The Hardest Part Was Not the UI

The hardest parts were the production details.

Apple Sign In had to work from both login and registration. Push notification tokens had to be saved correctly after permission was granted. Firebase Cloud Messaging had to be connected to APNs correctly. App Store subscriptions had to sync with the backend. The backend needed enough logging so I could see what actually happened when something failed.

One example: push notifications were not just "install Firebase and done." I had to handle APNs token timing on iOS, register the FCM token with the backend, store device tokens per user, connect Firebase to the correct APNs key, and test direct backend sends from production.

When it finally worked, I could send a notification from the admin panel and see it arrive instantly on the device. That was a good moment.

App Store Review Was a Real Test

The first submission did not go through.

Apple rejected the app because the Continue with Apple button was unresponsive in one flow. The login screen was fine, but the registration screen had a button that looked ready and was not wired to the Apple auth flow yet.

That was a useful reminder: App Review will test the product like a real user, and any visible control needs to work.

I fixed the Apple Sign In flow, checked the release build again, fixed a few production issues around push token registration and profile plan display, rebuilt the IPA, uploaded a new build, and resubmitted.

The next review passed.

What the Backend Handles

The Django backend is not just a simple auth API.

It handles:

User accounts and auth sessions
Habit CRUD
Habit completions
Reminder settings
Device notification tokens
Push notification campaigns
Push notification logs
Daily summaries
Subscription state
Legal documents
Landing page content
Admin workflows

I also added admin tooling so I can inspect device tokens, see failed push messages, send campaigns, and debug real user issues without guessing.

That saved a lot of time during launch.

What I Learned

Shipping a real mobile app is mostly about the small details that do not show up in screenshots.

The UI matters, but production readiness matters more:

Does Apple Sign In work in every auth flow?
Does the app still work after a fresh install?
Are push tokens saved after permission changes?
Can the backend send to the latest device token?
Can I see why a push failed?
Does the App Store build match the version I think I uploaded?
Does the landing page point to the live App Store URL?

None of these are exciting individually, but together they decide whether the app feels real.

Why I Built TinyHab

I built TinyHab because I wanted a habit tracker that is easier to come back to after a bad day.

Most habit apps are optimized for perfect consistency. TinyHab is designed for imperfect consistency: missed days, low energy, friction, and restarting without shame.

That product direction shaped both the design and the engineering. The app needed to be simple on the surface, but reliable underneath.

Final Thoughts

This was a full-stack mobile build from zero to App Store approval.

I worked across Flutter, Django, Firebase, APNs, RevenueCat, Docker deployment, admin tooling, and App Store Connect. The result is now live on the App Store, and I am continuing to improve it based on real usage.

If you are building a mobile app, my biggest advice is simple: test the boring production flows early. Login, registration, push notifications, subscriptions, release builds, and admin visibility are where most launch problems hide.

TinyHab is live here:

https://apps.apple.com/app/tinyhab-adhd-habit-tracker/id6770136917

Most Framework Comparisons Ignore What Actually Matters in Production

Fatih Kurt — Wed, 20 May 2026 13:20:25 +0000

Every few weeks, developers compare frameworks again.

Which one is faster?
Which one has better syntax?
Which one has the cleanest developer experience?
Which one is more “modern”?

I used to care about these comparisons a lot. As a full stack developer, I tried Go, FastAPI, Next.js, NestJS, Fiber, Elysia and several other tools because I thought choosing the newest stack would make my projects better.

After building real projects, client work, internal tools, mobile backends and SaaS experiments, my opinion changed.

Most framework comparisons focus on the wrong layer.

They compare hello world performance, request throughput, routing syntax and startup time. Those things matter in some cases, but they are rarely the main reason a product succeeds or fails.

In production, the problems are usually different.

Can you deploy it safely?
Can you debug it quickly?
Can you onboard another developer?
Can you find stable packages?
Can you migrate the database without fear?
Can you monitor errors?
Can you maintain the project after six months?
Can the business rely on it?

That is where boring technology starts to win.

A simple API endpoint looks similar in almost every framework.

# FastAPI
from fastapi import FastAPI

app = FastAPI()

@app.get("/orders")
async def get_orders():
    return [
        {"id": 1, "status": "completed"},
        {"id": 2, "status": "pending"},
    ]

The same idea in Go Fiber is not fundamentally different.

// Go Fiber
app.Get("/orders", func(c *fiber.Ctx) error {
    return c.JSON([]fiber.Map{
        {"id": 1, "status": "completed"},
        {"id": 2, "status": "pending"},
    })
})

And in .NET, the shape is still the same.

// ASP.NET Core
[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
    [HttpGet]
    public IActionResult GetOrders()
    {
        return Ok(new[] {
            new { Id = 1, Status = "Completed" },
            new { Id = 2, Status = "Pending" }
        });
    }
}

The syntax changes, but the business problem does not.

Most of the time, the hard part is not writing the endpoint. The hard part is everything around it: authentication, permissions, database modeling, migrations, background jobs, caching, logging, file uploads, payments, admin workflows, SEO, analytics and deployment.

That is why I stopped treating framework choice as the most important technical decision.

For example, a boring Django model like this can create more business value than a week spent comparing backend frameworks.

# Django
from django.db import models

class Customer(models.Model):
    company_name = models.CharField(max_length=255)
    email = models.EmailField(unique=True)
    is_active = models.BooleanField(default=True)
    created_at = models.DateTimeField(auto_now_add=True)

There is nothing exciting here. But you immediately get a stable ORM, migrations, validation patterns, admin integration and a mature ecosystem around it.

That matters when you are building something that needs to survive beyond a weekend project.

The same thing applies to .NET.

A lot of people online treat enterprise stacks as boring, but boring is not always a weakness. In many projects, boring means predictable. It means other developers can understand the codebase. It means the deployment story is known. It means companies can maintain it for years.

This is especially important when the project is not just an experiment.

A client dashboard, a CMS, a restaurant ordering system, a SaaS backend, an internal CRM or a mobile app API does not need the most exciting stack. It needs a stack that can be maintained without constant drama.

Deployment is another place where boring tools usually win.

A simple Docker Compose setup like this is not impressive, but it is practical.

services:
  app:
    build: .
    restart: always
    depends_on:
      - postgres
      - redis

  postgres:
    image: postgres:16
    restart: always
    volumes:
      - postgres_data:/var/lib/postgresql/data

  redis:
    image: redis:7
    restart: always

volumes:
  postgres_data:

This kind of setup is boring, but it gives you repeatability. You can run it locally, move it to a server, add monitoring, add backups and understand what is happening when something breaks.

That is more valuable than people admit.

Modern tools often look better in demos because demos hide operational cost.

A new framework can feel amazing when you are building the first endpoint. The routing is clean, the syntax is elegant, the benchmarks are impressive and the documentation looks fresh.

But the real test comes later.

What happens when a dependency is abandoned?
What happens when the ORM has edge cases?
What happens when the package you need is half-maintained?
What happens when AI-generated tutorials teach bad practices?
What happens when you need to hire someone?
What happens when you need to debug a production issue at night?

This is where mature ecosystems have an advantage.

Not because they are perfect.

Because their problems are already known.

Known problems are easier to price, debug and plan around. Unknown problems are expensive because they appear when the project is already under pressure.

That is the part many developers ignore when comparing frameworks.

They compare speed, but not maintenance cost.

They compare syntax, but not ecosystem risk.

They compare benchmarks, but not hiring difficulty.

They compare developer experience, but not operational complexity.

For most business software, the bottleneck is usually not the framework. It is the database design, slow queries, bad caching, unclear requirements, weak deployment process, poor monitoring or missing product distribution.

A faster router will not fix those problems.

A newer runtime will not fix a bad data model.

A cleaner syntax will not make users care about your product.

That does not mean new technology is bad. I still like trying new tools, and sometimes a newer stack is the right choice. If it reduces complexity, improves performance where it actually matters or gives the product a real advantage, then it is worth considering.

But “new” by itself is not a strategy.

Before choosing a stack now, I ask more practical questions.

Can I ship faster with this?
Can I maintain it for three years?
Can I deploy it without special tricks?
Can I find help when something breaks?
Can I reuse patterns from previous projects?
Does it reduce complexity or just move it somewhere else?

That is why I still use Django, .NET, Next.js, PostgreSQL, Flutter and Docker in many projects.

They are not always the coolest choices.

But they are stable, documented, widely used and good enough for a lot of real-world software.

And “good enough” is underrated.

Good enough lets you ship.
Good enough lets you maintain.
Good enough lets you focus on the product.
Good enough lets you build systems instead of constantly rebuilding foundations.

After spending enough time chasing frameworks, I started caring less about what looks impressive in a benchmark and more about what still works when the project becomes boring.

Because that is usually when the real work begins.

Flutter vs React Native Is the Wrong Question for Solo Full-Stack Developers

Fatih Kurt — Mon, 18 May 2026 09:28:24 +0000

I see this debate everywhere:

“Flutter or React Native?”

But after building products as a full-stack developer, I think this is actually the wrong question.

The better question is:

“What helps a solo or small-team developer ship polished products faster with fewer long-term headaches?”

And for me, the answer became Flutter.

The Funny Part: I Already Use React

This is what makes my decision look strange at first.

Most of my stack is already JavaScript/TypeScript based:

Next.js
React
TypeScript
Node.js sometimes
Django / .NET on backend

So logically, React Native should have been the obvious choice.

Same ecosystem.
Same language.
Shared mental model.

But after trying both approaches seriously, I realized something important:

Mobile development is not just “React on a phone.”

It is an entirely different product experience.

And that changed how I evaluate frameworks.

Why Flutter Worked Better For Me

1. UI Consistency Matters More Than People Admit

One of the biggest things I noticed with React Native was this constant feeling of:

“Almost the same… but not exactly.”

Different behavior between iOS and Android.
Different rendering quirks.
Different native dependencies.
Random styling inconsistencies.

Sometimes small.
Sometimes painful.

Flutter felt different immediately.

The UI layer is fully controlled by Flutter itself, so things behave much more consistently across platforms.

As someone building products mostly alone, this matters a lot.

I do not want to spend energy debugging platform-specific UI weirdness.

I want predictable output.

2. Flutter Feels More Product-Oriented

This is hard to explain until you build real apps.

Flutter encourages polished interactions naturally:

smooth animations
better transitions
custom UI freedom
more “designed” feeling interfaces

React Native often feels like:

“web development adapted to mobile.”

Flutter feels like:

“actual mobile product development.”

That difference becomes very noticeable once you care about UX quality.

3. Separation Between Web and Mobile Is Actually Healthy

At first, I thought sharing React knowledge everywhere was automatically a good thing.

Now I think separating web and mobile stacks can actually improve architecture decisions.

For example:

Web

SEO
SSR
fast iteration
content-heavy systems

Perfect for:

Next.js
React

Mobile

animations
touch interactions
native feeling UX
smooth rendering

This is where Flutter shines.

Trying to force the exact same mindset onto both platforms sometimes creates worse products.

4. Developer Experience Was Surprisingly Calm

This was unexpected.

Flutter tooling felt extremely stable for me.

Especially:

hot reload
layout system
animation handling
component consistency

Everything felt centralized and opinionated in a good way.

With React Native, I often felt closer to the ecosystem chaos of JavaScript development.

And honestly:

As a solo builder, reducing chaos is underrated.

But React Native Still Makes Sense

I am not saying React Native is bad.

In fact, I think React Native is the correct choice in many situations:

large React teams
companies with existing JS infrastructure
shared business logic requirements
teams needing fast onboarding
web-heavy organizations

If I joined a big React-based startup tomorrow, I would probably use React Native too.

But for my own products?

Flutter gives me more confidence.

My Current View

I use:

Next.js for web
Flutter for mobile
Django / .NET for backend

And honestly, this combination feels extremely balanced.

Web and mobile stopped fighting each other technically.

Each platform now uses the tool that feels strongest for its own environment.

And that changed how I build products.

Maybe the real question is not:

“Which framework is better?”

Maybe it is:

“Which framework creates fewer long-term bottlenecks for the way YOU build products?”

Why I Built My Own Mobile SSH Client (And Why You Should Care About Your Keys)

Fatih Kurt — Mon, 09 Mar 2026 06:46:23 +0000

Let’s be real: managing a production VPS from a smartphone is usually a nightmare.

A few weeks ago, I had a runaway Docker container eat up all the RAM on a client’s server at 2 AM. By the time I got to my laptop, the damage was done. I tried using some of the "big" mobile SSH apps, but they all had the same problems:

They felt like they were designed in 2012.
They were bloated with features I didn't need.
The biggest red flag: They wanted to sync my private SSH keys and server IPs to their cloud.

As a developer, handing over my "keys to the kingdom" to a third-party cloud never sat right with me. So, I decided to build ServerGlance.

The "No-Cloud" Architecture

My first rule was simple: No credentials ever leave the device. Period.
I used flutter_secure_storage for local AES-256 encryption. When you connect to your server, the iPhone talks directly to the VPS via SSH. No middleman, no telemetry, no "syncing" to my servers.

Solving the Keyboard Agony

Using a terminal on a touchscreen is painful because standard keyboards lack Esc, Tab, Ctrl, and arrow keys. I built a custom keyboard accessory row and "Quick Actions" so I could run htop or df -h with a single tap.

Docker Visibility at a Glance

Instead of just being a terminal, I wanted to see my containers without needing a full SSH session. I implemented a view that surfaces your Docker containers directly on the dashboard. At a glance, I can see which containers are running, which have exited, and which image versions are live—all without typing a single command.

Who is this for?

If you manage a handful of VPS instances (Hetzner, DigitalOcean, AWS) and you actually care about where your private keys are stored, give it a look. It’s built by a developer who got paged one too many times.

I’m looking for feedback from fellow SysAdmins and DevOps engineers. What’s the one feature that would make you actually leave your laptop closed during a minor server crisis?

Links:

App Store: https://apps.apple.com/us/app/serverglance-ssh-monitor/id6758614736
Website: https://serverglance.fktyazilim.com/