DEV Community: Azad Mohamed

I Got Tired of Losing to ATS Robots in the UAE Job Market, So I Built My Own Career Command Center

Azad Mohamed — Sun, 25 Oct 2026 15:07:14 +0000

"I don't always apply for jobs. But when I do, I apply to 47 of them before lunch and hear back from zero."

Let me be honest with you. Getting an interview in the UAE right now is hard. Not "a bit competitive" hard. "Your CV went into a black hole and the black hole didn't even send a rejection email" hard.

This post is about how that frustration turned into a side project, and how that side project turned into the tool I now use every single day of my job search.

😩 The problem: the job hunt is now a full-time job

If you're job hunting in the UAE (or honestly anywhere in 2026), you probably know this loop:

There are too many places to look. LinkedIn, Indeed, Bayt, GulfTalent, Naukrigulf, plus every company's own career page. Each one has its own login, its own form, its own "upload your CV and then type your CV again manually" experience.
Every JD wants a different CV. ATS systems scan for keywords. The same experience written slightly differently is the difference between "shortlisted" and "auto-rejected by a robot at 3 AM." So you end up with CV_final.pdf, CV_final_v2.pdf, CV_final_REAL_this_one.pdf...
You lose track. Which company did I apply to? Which CV did I send? Did that recruiter reply? Was the interview Tuesday or Thursday?

"My spreadsheet of job applications had more tabs than my browser. And that's saying something."

🤯 And then you finally get the interview...

Here's the part nobody talks about.

A lot of us build with AI now. Copilot, Claude, Cursor: they're part of how modern developers ship. That's fine. That's the job now.

But then you sit in a system design round and the interviewer asks:

"So, why did you choose a message queue here instead of a direct call?"

And your brain goes: "...because the AI suggested it and it worked?" 😅

Being able to explain architecture, trade-offs and decisions out loud is a separate skill. And you can't build it by reading random "Top 50 Interview Questions" blog posts. You build it by practicing on the questions you actually get asked, and fixing the gaps you actually have.

"Interviewer: Walk me through your architecture. Me: walks out of the room. Not what they meant, apparently."

🛠️ So I built Interview Command Center

I didn't set out to build a product. I built it for myself, because I needed one place to:

track every application and interview,
auto-apply to jobs that actually match me,
tailor my resume for each JD so it survives the ATS,
practice coding the way interviews are run now,
and prepare a crash course based on the exact job description and round.

It's open source, self-hosted, and it works with whatever AI you have (or none at all).

👉 GitHub: github.com/azadhmhd/interview-command-center

Here's everything it does.

✨ Features (all of them, because I'm proud of my child)

1. 📋 Application tracker

Table, Kanban and timeline views. Custom statuses, duplicate detection (no more applying to the same role twice, oops), contacts, documents, which CV version went to which application, follow-up reminders, and you can import a job post straight from its URL.

2. 🤖 Auto Apply

This is the one that saves me hours every week.

Finds jobs by your role and location through Google Jobs and Jooble, covering LinkedIn, Indeed, Bayt, GulfTalent, Naukrigulf and company pages. Searching "UAE" also covers every emirate: Dubai, Abu Dhabi, Sharjah, Ajman...
Watches company boards directly (Greenhouse, Lever, Ashby, SmartRecruiters, Workable), and you can even paste job alert emails.
Scores each job with reasons and hard blockers, so you know why it's a fit (or why it isn't).
Builds an apply kit from answers you've saved once.
Checks your CV's ATS keyword match before applying, and tailors a copy if the score is low.
Applies through your own browser (Claude in Chrome or a local runner). It works on forms that reject normal bots.
Guardrails built in: it stops on CAPTCHAs and logins, never guesses answers, never applies twice, and keeps proof of every submission.
A live Mission Control page shows the whole pipeline. Recruiter contacts get saved for later outreach.

"Auto Apply doesn't get tired, doesn't get sad, and doesn't refresh its inbox every 4 minutes. It's everything I aspire to be."

3. 📄 Resume builder with AI tailoring

Unlimited resumes and job-specific copies with the same design, a live A4 preview and PDF export. AI tailoring per job may only reword and reorder. It never invents facts. Your CV stays honest; it just speaks the JD's language.

4. 📓 Interview journal

Every company gets its own sequence of rounds. You record:

the exact questions you were asked,
your original answer (locked once saved, so no rewriting history 😄),
missed concepts, mistakes, code, follow-ups,
and then improved, approved answers.

Paste your messy post-interview notes and it splits them into questions automatically.

5. 🎓 Crash courses built from the JD

This is my answer to the "explain your architecture" problem. Give it the job description, round type, deadline, your CV and your recorded weak spots, and it builds:

prioritised topics (with the reason each one matters),
a time-boxed schedule,
lessons and model answers,
flashcards and mock interviews,
and readiness tracking so you know if you're actually ready.

"Crash course" because that's exactly what happens to my confidence 2 days before an interview. Now at least it's a planned crash.

6. 💻 Coding practice

Multi-stage problems in the style of modern AI-assisted coding interviews, plus pattern sections, in Python or JavaScript. Tests run in your browser, and an AI review scores you on correctness, approach, verification, code quality and communication. Yes, communication. Because "it works on my machine" is not an explanation.

7. 🧠 Personal knowledge base + spaced repetition

Full-text search across every interview you've ever done. If two companies ask the same question, it links to one entry. A spaced-repetition revision queue makes sure you don't forget what you learned the hard way.

8. 🎯 Practice & evaluation

Rubric scoring on correctness, completeness, depth and clarity. Model answers stay hidden until you try first (no cheating, I'm watching you). Retry and compare with your previous attempts.

9. ⏰ Automatic prep schedule

Milestones at 3, 2 and 1 day before the interview and on the day itself, with quiet hours, plus a prompt after the interview to capture what happened while it's still fresh.

10. 🔌 Bring your own AI

Use any OpenAI-compatible model (Ollama, LM Studio, vLLM, hosted providers), or your existing Claude Code / Cursor subscription. No new subscription needed.

11. 🏷️ Honest labels

Every question is marked as actually asked, public report, AI prediction or practice. Facts pulled from your CV stay "AI-inferred" until you confirm them. No hallucinated confidence.

12. 🔒 Private by default & works offline

Self-hosted, multi-user workspaces, per-record sharing, audit log, export and account deletion. And with no AI configured at all, tracking, journaling, search, revision and scheduling still work.

🧱 Tech stack (for my fellow nerds)

Frontend: Next.js 16
API: NestJS 11
Database: PostgreSQL 17 (the source of truth, so nothing is lost on restart)
Queue: Redis + BullMQ, with a separate worker for background tasks and scheduling
Storage: MinIO / S3 or local disk
One docker compose up and you're running.

git clone https://github.com/azadhmhd/interview-command-center.git
cd interview-command-center
cp .env.example .env   # set APP_ENCRYPTION_KEY
docker compose up -d --build

Open http://localhost:3000 and you're in.

🙏 I need your help (yes, you)

I built this for my own job search, but I know I'm not the only one stuck in this loop. So:

Use it. It's free and open source.
Break it. Then tell me how you broke it.
Give me feedback. What's missing? What's annoying? What would make your job search easier?
Contribute. PRs are very welcome.

It's still under construction. It's in the "we'll get back to you" stage of its own hiring process. 😄 But with your feedback we can make it much better, and help each other land bigger opportunities and build better futures.

"Rejection is just redirection. Usually towards another 'Apply Now' button."

⭐ If this sounds useful, star the repo, try it out and drop your thoughts in the comments or open an issue:
👉 github.com/azadhmhd/interview-command-center

Let's get hired. 💼

Are you job hunting in the UAE or the Gulf right now? What's the hardest part for you: getting the interview or surviving it? Tell me in the comments. 👇

Six tests that passed without testing what they claimed

Azad Mohamed — Sun, 18 Oct 2026 14:58:26 +0000

I recently built a multi-tenant booking API (FastAPI, SQLAlchemy, Postgres, Redis, and a background worker) with Claude Code, as the running example for a book. Writing good tests was an explicit goal from the first commit. The suite grew to 97 tests against real Postgres and Redis, with no mocked database.

Six of those tests passed without testing what their names claimed. None was careless. Each was plausible, read well, and went green. A green run can't tell a test that checks the behaviour from one that checks nothing, and that's as true when you write the test as when an agent does.

Here they are, in the order we found them.

1. "Expired tokens are rejected"

The test built a token with an exp in the past and asserted a 401. It passed.

It signed the token with a hard-coded secret, and the app used a different one from .env. The token was rejected for its signature, not its expiry. With expiry checking switched off, the test still passed.

The fix is a positive control. Next to the negative assertion, take the same token, change only the property under test, and assert it's accepted:

expired = jwt.encode(claims, settings.jwt_secret, algorithm="HS256")
assert post_with(expired).status_code == 401

still_valid = jwt.encode({**claims, "exp": now + timedelta(minutes=5)},
                         settings.jwt_secret, algorithm="HS256")
assert post_with(still_valid).status_code == 201  # same token, future exp: accepted

If the control fails, the negative test was never testing expiry.

2. "A 2,070-character webhook URL returns 422, not 500"

Contract fuzzing had found a real 500: URLs between 2,049 and 2,083 characters passed the URL validator and then overflowed a 2,048-character column. The regression test used a 2,560-character URL. It got a 422 because the URL validator's own length limit rejected it, so the database was never reached.

The fix: the test asserts its precondition (assert 2048 < len(url) < 2083), so it can't drift out of the window that matters.

3. "Login fails closed when Redis is down"

Login checks two rate limits: per IP and per email. Flipping the per-IP check to fail open left the test green, because the per-email check still failed closed.

The fix: one planted bug per guard, and a test path that exercises each guard alone. Registration only has the per-IP check, and it had no Redis-down test at all.

4. "Two owners removing each other can't leave zero owners"

Two threads, two requests, one assertion. It passed 10 out of 10 runs with the protective lock removed. The threads never actually interleaved.

The fix: force the interleaving. Open a second database connection, lock the rows the request needs, start the request, then commit:

with engine.connect() as other:
    other.execute(text("SELECT 1 FROM memberships WHERE org_id = :o "
                       "AND role = 'owner' FOR UPDATE"), {"o": org_id})
    other.execute(text("DELETE FROM memberships WHERE org_id = :o AND user_id = :u"),
                  {"o": org_id, "u": second_owner})
    pending = pool.submit(remove_first_owner)   # blocks on the lock
    time.sleep(0.5)
    other.commit()
assert pending.result() == 409

With the lock in place, it passes 3 out of 3. Without it, it fails 3 out of 3. That's a race test.

5. "A booking of exactly 12 hours is allowed"

A Hypothesis property test generated random durations between −24 and +24 hours and checked the rule 0 < duration <= 12h. Moving the boundary by one microsecond (<= to <) didn't fail it. Random durations practically never land on exactly 12:00:00.

The fix: pin the boundaries with @example(duration=MAX_BOOKING) and its neighbours. Property tests are great at the edges of the input space you give them, and blind to the edges inside it.

6. No test fetched a single booking

This one isn't a lying test but a missing one. While practising a refactor, we broke GET /bookings/{id}, and the whole suite stayed green. No test had ever fetched one booking successfully.

The one habit that found all six

Every one was found the same way: break the code on purpose and check that a test goes red.

We turned that into a script. It holds a list of realistic bugs (a missing tenant filter, expiry not enforced, the overlap constraint neutralized, a limiter that fails open, and so on). It applies each bug in turn, runs the tests expected to catch it, and fails if any bug survives. There are 22 now, and the script runs in CI. A pull request that deletes or weakens the test for a protection fails the build, even when every remaining test passes.

It isn't a general mutation-testing tool. It's a hand-picked list of the bugs this particular service must never ship. Because each bug runs only the test files expected to catch it, it's fast enough for every pull request: about a minute and a half for all 22 on a laptop.

What this means when an agent writes your tests

AI-written tests fail in exactly these ways, only faster and in greater volume. Three instructions change the outcome more than any amount of "be thorough":

"Write the test first and show me it failing, and why." The failure message should name the behaviour, not a setup error or a 404 for a route that doesn't exist yet.
"Every negative test needs a positive control."
"For each new protection, add a planted bug and show it's caught."

Then read which test went red. A planted bug caught by an unrelated test is a warning, not a success.

This is adapted from Chapter 9 of my book, Claude Code for Backend Developers. The book comes with the runnable service these tests are from: https://azadhmhd.gumroad.com/l/claude-code-backend

The 5 Queries I Run First When Postgres Is Slow

Azad Mohamed — Sun, 18 Oct 2026 08:08:41 +0000

When an API slows down and the database is the suspect, the hardest part isn't the fix. It's knowing where to look while everyone is watching. Here are five read-only queries that find the most common causes of "Postgres is slow" in production, in the order I run them. All of them are safe on a busy primary. Run them as a role with pg_monitor so you can see other sessions' queries.

Tip: start each session with SET statement_timeout = '5s'; SET lock_timeout = '1s'; so even a diagnostic query can't pile onto the problem.

1. Is anything blocked, and by whom?

One session holding a lock can stall hundreds of requests. Find every waiting query and the session it's waiting for:

SELECT w.pid AS waiting_pid,
       now() - w.query_start AS waiting_for,
       left(w.query, 80) AS waiting_query,
       b.pid AS blocker_pid,
       b.state AS blocker_state,
       now() - b.xact_start AS blocker_xact_age,
       left(b.query, 80) AS blocker_query
FROM pg_stat_activity w
CROSS JOIN LATERAL unnest(pg_blocking_pids(w.pid)) AS bp(pid)
JOIN pg_stat_activity b ON b.pid = bp.pid
WHERE w.wait_event_type = 'Lock';

Look at blocker_state. If it says idle in transaction, an application (or a forgotten psql session) opened a transaction and walked away while holding locks. A trap worth knowing: a migration waiting for an ACCESS EXCLUSIVE lock also blocks every later SELECT on that table, so a quick ALTER TABLE stuck behind one slow query can freeze a whole table.

2. Who is sitting in an open transaction?

SELECT pid, usename, application_name,
       now() - xact_start AS xact_age,
       now() - state_change AS idle_for,
       left(query, 80) AS last_query
FROM pg_stat_activity
WHERE state LIKE 'idle in transaction%'
  AND now() - state_change > interval '1 minute'
ORDER BY state_change;

These sessions hold locks and stop vacuum from cleaning up. The usual cause is application code that makes an HTTP call or does slow work inside a transaction. The guardrail is ALTER ROLE app SET idle_in_transaction_session_timeout = '60s';.

3. How close are we to max_connections?

SELECT count(*) AS used,
       current_setting('max_connections')::int AS max,
       count(*) FILTER (WHERE state = 'active') AS active,
       count(*) FILTER (WHERE state = 'idle') AS idle,
       count(*) FILTER (WHERE state LIKE 'idle in transaction%') AS idle_in_tx
FROM pg_stat_activity
WHERE backend_type = 'client backend';

Mostly idle means app pools are oversized (pool size × processes × instances). Mostly active means slow queries are holding connections. Raising max_connections is rarely the fix.

4. Which foreign keys have no index?

Deleting a parent row makes Postgres look up child rows by the FK columns. Without an index, that's a full scan of the child table, inside your transaction, holding locks.

SELECT c.conrelid::regclass AS table_name, c.conname,
       (SELECT string_agg(a.attname, ', ')
          FROM unnest(c.conkey) k(n)
          JOIN pg_attribute a ON a.attrelid = c.conrelid AND a.attnum = k.n) AS columns
FROM pg_constraint c
WHERE c.contype = 'f'
  AND NOT EXISTS (
    SELECT 1 FROM pg_index i
    WHERE i.indrelid = c.conrelid
      AND (string_to_array(i.indkey::text, ' ')::int2[])[1:array_length(c.conkey, 1)] @> c.conkey
      AND (string_to_array(i.indkey::text, ' ')::int2[])[1:array_length(c.conkey, 1)] <@ c.conkey);

Fix it with CREATE INDEX CONCURRENTLY, outside a transaction. In Django that's AddIndexConcurrently in a migration with atomic = False; in Rails, algorithm: :concurrently with disable_ddl_transaction!.

5. Is any ID about to run out?

Not a slowdown, but the outage nobody sees coming: an integer primary key stops at 2,147,483,647.

SELECT s.schemaname || '.' || s.sequencename AS seq, s.last_value,
       round(100.0 * s.last_value / 2147483647, 1) AS pct_of_int_max
FROM pg_sequences s
WHERE s.last_value > 0.5 * 2147483647
ORDER BY s.last_value DESC;

(This simple version assumes integer columns. The full check in the kit looks up each sequence's actual column type.)

What I don't run first

VACUUM FULL (an exclusive lock for the whole rewrite), restarting the server (it wipes the evidence and the cache), or raising settings at random. Diagnose first.

Turning this into a tool

I packaged these five checks as a free, MIT-licensed CLI that runs them read-only and writes a ranked report: github.com/azadhmhd/postgres-triage-kit. The full Postgres Triage Kit adds 15 more checks (top queries, vacuum lag, wraparound, unused and duplicate indexes, replication slots and more) and 9 incident runbooks: Postgres Triage Kit on Gumroad.

All queries tested on PostgreSQL 13–18. Originally published at azadhmhd.com.

How to Structure a NestJS Backend for AI-Assisted Development

Azad Mohamed — Sat, 17 Oct 2026 20:05:56 +0000

AI coding agents are good at writing NestJS code and bad at guessing your NestJS conventions. Left alone, they put queries in controllers, return entities straight from the database, add a fourth way of throwing errors, and cheerfully offer to run migration:run against whatever database your .env points at.

The fix is not a cleverer prompt. It's a repository that states its rules where agents read them, makes correct changes cheap to verify, and enforces the few rules that must never be broken. Here's the structure I use. None of it needs a particular agent.

1. One instruction file, and only one

Every major agent now reads a project instruction file. Codex, Cursor, GitHub Copilot and Gemini CLI (with one setting) read AGENTS.md. Claude Code reads CLAUDE.md, which can import another file. So:

<!-- CLAUDE.md -->
@AGENTS.md

## Claude Code specifics
(skills, subagents, permission rules: only what is genuinely Claude-specific)

// .gemini/settings.json
{ "context": { "fileName": ["AGENTS.md"] } }

Rules live in AGENTS.md only. The day you have the same rule in two files, they start to drift, and some tools (Copilot CLI, for one) merge every instruction file they find without a precedence order. Keep AGENTS.md short (a project map, commands, conventions, safety rules, report format) and link to docs/ for detail.

2. Write stop rules, not style advice

"Write clean code" changes nothing. What changes behaviour is a short list of things the agent must not do, written as rules with the exact words you want back:

## Stop rules

1. Do not generate, run or revert migrations until the user tells you to in this conversation.
   An entity change is not permission. Make the code change and report:
   "Schema change detected. Migration required. Not generated or run: no explicit approval."
2. Do not run or edit seeds until the user tells you to.
3. Do not format code. The pre-commit hook formats staged files; CI checks formatting.

Rule 3 is a cost rule: formatting runs burn agent time and produce noisy diffs, and Husky + lint-staged already do it on every commit.

3. Make the architecture boring and stated

Agents copy what they see. If the codebase has one pattern, they copy that one. Pick an explicit structure and write it down:

src/<feature>/
  controllers/   HTTP only: routing, guards, Swagger decorators
  services/      business rules; one class per responsibility
  dto/           request DTOs (class-validator, length limits) and response DTOs
  entities/      the data model; no queries, HTTP, email or JWT logic

Then the dependency rule in one line: Controller → Service → Repository<Entity>. Other modules inject the owning service, never another module's repository. And a few "never" rules that agents otherwise break constantly:

Responses map entities through ResponseDto.fromEntity(); never return an entity (that's how password hashes end up in JSON).
User-owned data is looked up by the authenticated ID from @CurrentUser(), never by an ID from the request alone.
Clients never set server-owned fields (status, verification state, roles).

A global ValidationPipe with whitelist: true, forbidNonWhitelisted: true backs the last rule up mechanically: a DTO that doesn't declare status can't receive it.

4. One error contract

Give the agent exactly one way to fail:

export abstract class AppException extends Error { /* status + stable code */ }
export class NotFoundError extends AppException {}
export class ConflictError extends AppException {}
// ...

throw new ConflictError('EMAIL_ALREADY_REGISTERED', 'Email is already registered');

A single global exception filter turns every error, including unexpected ones, into the same shape:

{ "statusCode": 409, "code": "EMAIL_ALREADY_REGISTERED", "message": "...",
  "path": "/api/v1/auth/register", "requestId": "6f1c...", "timestamp": "..." }

Stable UPPER_SNAKE codes give agents (and frontends) something to assert on, and the filter is the one place that guarantees no SQL, stack trace or SMTP detail leaks.

5. Make verification cheap, or it won't happen

An agent will run the checks you make easy. If tests need a database, Docker and seed data, the agent either skips them or starts containers you didn't ask for. So make the default suites infrastructure-free:

Unit tests construct services directly with a small in-memory repository that implements only the TypeORM methods your services use:

  /** Minimal in-memory stand-in for the TypeORM repository methods used by the services. */
  export class MockRepository<T extends { id: string }> {
    readonly items = new Map<string, T>();
    create(data: Partial<T> = {}): T { /* ... */ }
    async save(entity: Partial<T>): Promise<T> { /* ... */ }
    // findOne, findAndCount, update... only what's used
  }

E2E tests boot the real AppModule with the real pipes, guards, filters and throttler, and override only the repositories and the mail service. That tests authorization and validation where the bugs actually are, in about ten seconds, with no database.

Then tell the agent the exact commands, narrowest first (npx jest <path>), and that a red test is fixed for a real reason, never by weakening the assertion.

Be honest about the gap: in-memory repositories don't test SQL, constraints or cascades. Say so in docs/testing.md, and check migrations by hand (up, down, up) against a disposable PostgreSQL before a release.

6. Enforce the rules that matter; write down the rest

Written rules are followed most of the time. For the few operations that can destroy data, add enforcement your tool supports. In Claude Code, ask permission rules prompt before matching commands even in permissive modes:

{
  "permissions": {
    "ask": ["Bash(npm run migration:*)", "Bash(npm run seed *)", "Bash(psql *)",
            "Bash(docker compose down *)", "Bash(git push *)"],
    "deny": ["Read(**/.env)", "Read(**/.env.production)"]
  }
}

Know the limits: these rules match command text. A script that runs a migration indirectly isn't caught, and a deny on reading .env doesn't stop code that opens the file. For other agents, configure their command approval for the same commands.

7. Demand a fixed report

The most useful line in my AGENTS.md is the report format:

Implemented       what changed and why
Files changed     paths
Verification      commands actually run and their actual results
Not performed     e.g. migration generation, seed execution, Docker, deploy
Unverified        anything you could not check
Never claim a command passed if you did not run it.

It turns "Done! Everything works" into something you can check in thirty seconds, and the "Not performed" line is where the pending migration shows up instead of silently happening.

8. Turn recurring jobs into procedures

When you notice you're giving the same multi-step instruction for the third time, make it a file. In Claude Code these are skills (.claude/skills/<name>/SKILL.md), loaded on demand; for other agents the same Markdown works as "follow .claude/skills/debug/SKILL.md". Good candidates in a NestJS API:

generate: inspect an existing module first, reuse before creating, add tests, report.
database-change: check entity conventions, decide whether a migration is needed, review an existing migration's down(), and never generate one without a request.
debug: map symptoms to the right file (400 property X should not exist → the DTO is missing a field), reproduce with a database-free test, fix at the root.

Name them so they don't shadow built-in commands (review-change, not review).

The short version

One AGENTS.md; tool files import it.
Stop rules with exact words, not style advice.
One structure, one dependency direction, a few explicit "nevers".
One error class hierarchy and one filter.
Default test suites that need no infrastructure.
Tool-enforced prompts for destructive commands.
A fixed report that separates "verified" from "not performed".
Recurring tasks as procedure files.

I've packaged this structure, with a complete NestJS 11 + PostgreSQL implementation (auth, admin API, migration, 96 tests, Docker, and the agent files above), as a paid starter kit. If you'd rather start from it than build your own, it's here: NestJS Production Starter Kit for AI Coding Agents.

I Kept Forgetting to Drink Water While Coding, So I Built Kairo

Azad Mohamed — Wed, 26 Aug 2026 18:22:42 +0000

I spend a lot of time in front of a computer.

And like probably a lot of developers, when I'm deep into work, I completely forget about everything around me.

Drink water? Forgot.

Take a break? Forgot.

Look away from the screen? Forgot.

Move around for a few minutes? Maybe after another three hours. 😅

Living in the UAE makes this even easier. It's hot outside for a good part of the year, so it's very easy to stay indoors, sit in front of a screen, turn on the AC, and just keep working.

At some point I thought:

Why don't I just build something to remind me?

So I built Kairo.

What is Kairo?

Kairo is a small desktop companion designed to help build healthier computer habits.

The idea is simple:

💧 Remind me to drink water
👀 Remind me to rest my eyes
🚶 Remind me to take breaks
🧘 Encourage healthier working habits
📊 Keep track of what I've actually been doing

I wanted something that felt less like a notification from an operating system and more like a small companion sitting alongside me while I work.

That's where the animated character comes in.

I wanted it to be private

One thing I didn't want was another productivity application that required an account and sent all my activity to some server.

So I designed Kairo around an offline-first approach.

The core application works locally and stores its data on the machine.

AI is also completely optional.

If you want AI-powered coaching, Kairo can connect to providers such as Ollama or LM Studio, so you can run the AI locally instead of sending your data to a cloud service.

The application should still work perfectly fine without AI.

Why I built it

Honestly, this wasn't originally meant to become a big open-source project.

I built it because I needed it.

I kept noticing the same pattern in my own work:

Start coding → get focused → lose track of time → forget water → forget breaks → realize hours have passed.

If Kairo can interrupt that cycle even a little, then it has already done what I wanted.

A little bit about the engineering

Although the idea is simple, I wanted to use the project to experiment with building a proper desktop application.

Kairo is built with Flutter and is currently focused on macOS.

Some of the things I'm working with include:

Flutter desktop
SQLite for local persistence
Event-driven communication
Modular packages
Native desktop integration
Offline-first architecture
Optional AI providers
Local AI through OpenAI-compatible endpoints

One design decision I'm particularly happy with is keeping AI out of the critical reminder path.

The reminder system shouldn't stop working just because an AI provider is unavailable.

AI should enhance the experience, not become a dependency for the basic functionality.

It's still a work in progress

There are plenty of things I want to improve.

I'm still figuring out:

Better reminder behaviour
More useful habit insights
Better AI coaching
More customization
Improving the desktop experience
Supporting more platforms

And this is where I'd really like some feedback.

If you spend most of your day working at a computer:

What would actually help you build healthier working habits?

Not another productivity dashboard.

Not another app asking you to track 20 things.

Just something that quietly helps you remember the basic things we tend to forget when we're focused.

Try Kairo

The project is open source:

GitHub: https://github.com/azadhmhd/kairo

If you find it useful, give it a try.

And if you have ideas, suggestions, or even things you think I've approached badly, I'd love to hear them.

I built Kairo for myself, but maybe it can become something useful for other developers too.

Maybe we can build a healthier workspace together.