DEV Community: Omar Elhaitoum

Why Child Safety Tracking Should Never Be Paywalled

Omar Elhaitoum — Sun, 19 Jul 2026 23:00:00 +0000

Some features should never be locked.

Child safety is one of them.

That belief shaped WIN RAK from day one.

A Real Scenario

A father and son are visiting another country.

Crowded streets.

Busy markets.

Tourist rush.

For one moment:

they get separated.

The child panics.

The father is older.

Disoriented.

Doesn’t know the language.

Can’t explain where he is.

This can become dangerous fast.

With WIN RAK:

the child (or guardian) sends a location request.

The father accepts.

His live position appears immediately.

He is found.

Fast.

Simple.

Safe.

Why This Must Stay Accessible

Many apps put advanced safety features behind subscriptions.

I understand business.

Servers cost money.

Maps cost money.

Notifications cost money.

But safety is different.

That’s why WIN RAK keeps child-watch requests unlimited.

Always.

Even on free plans.

Emergency Access Should Not Depend on Money

Imagine needing your child’s location...

and seeing:

“Upgrade to Premium.”

That should never happen.

Ever.

Convenience can be monetized.

Safety should not.

This is one of WIN RAK’s strongest rules.

Building for Real Families

WIN RAK supports smartwatch pairing.

This allows:

guardian requests
child-side visibility
emergency coordination
family trust systems

And it will continue expanding.

Because family safety deserves dedicated architecture.

Not an afterthought.

The goal is simple:

technology should protect people.

Not exploit their fear.

That principle will stay.

Trust, Jealousy, and Boundaries: Why Location Apps Need Better Permission Models

Omar Elhaitoum — Sun, 12 Jul 2026 23:00:00 +0000

Location sharing is powerful.

But power without boundaries becomes dangerous.

Not always legally.

Emotionally.

Psychologically.

Relationally.

And modern apps often ignore that.

The “Where Are You?” Problem

Imagine this:

A husband is working.

Busy.

Meetings.

Driving.

Phone on silent.

He can’t answer.

His wife becomes anxious.

Or suspicious.

Or both.

With traditional apps:

she watches him all day.

That may seem helpful.

But it slowly normalizes surveillance.

That creates unhealthy patterns.

WIN RAK Changes That Dynamic

Instead:

she sends a request.

He sees it when available.

Approves.

A live session begins.

Now:

she knows where he is.

Without permanent tracking.

Without constant monitoring.

Without relationship erosion.

This is healthier.

Because trust remains active.

Not passive.

Permission Granularity Matters

WIN RAK allows:

Auto-Allow
Auto-Deny
On-Hold

This means each person gets different trust settings.

Your spouse may be Auto-Allow.

Your coworker may be On-Hold.

Your ex?

Probably Auto-Deny.

This matters.

Because trust is personal.

Not global.

Why Most Apps Oversimplify This

Most apps assume:

“sharing = always sharing”

That’s too crude.

Real human relationships are more nuanced.

WIN RAK tries to reflect that.

Technology should adapt to human boundaries.

Not flatten them.

Privacy and trust are not enemies.

They should reinforce each other.

That’s what I’m building.

Designing Consent-Based Location Sharing in Flutter

Omar Elhaitoum — Sun, 05 Jul 2026 23:00:00 +0000

Most location apps are built around persistence.

Always-on.

Always-visible.

Always-running.

When I started building WIN RAK, I wanted the opposite.

Not because continuous tracking is technically bad.

But because most real-world location needs are temporary.

Short.

Situational.

Human.

That changes the architecture completely.

The Traditional Model

Most apps work like this:

User A opens the app.
User B is visible.

Simple.

But under the hood:

background location stays active
battery drains continuously
privacy stays permanently exposed
backend receives constant updates

This creates a heavy system.

And often an unnecessary one.

WIN RAK Uses Request-Based Sessions

WIN RAK works differently.

Instead of constant presence:

it uses temporary live sessions.

Flow:

Request → Approval → Live Session → Session End

That means:

location only exists when needed.

This makes everything lighter.

Real-Life Example: “I’m Almost There”

Everyone knows this one.

Your friend says:

“I’m almost there.”

But he just woke up.

Still in bed.

Not moving.

With WIN RAK:

you send a location request.

He accepts.

You instantly know.

No guessing.

No fake ETA.

No argument.

Just reality.

Flutter Architecture Challenges

This model creates specific technical problems.

Unlike passive apps:

WIN RAK must be extremely fast.

That means:

fast notification delivery
fast approval path
fast GPS lock
fast map rendering

Everything must happen in seconds.

Not minutes.

Handling Contact Discovery Efficiently

One challenge was contact recognition.

WIN RAK scans contacts and detects which ones already use the app.

This improves onboarding dramatically.

Instead of manually adding everyone:

the app suggests them automatically.

That required:

normalization
local snapshots
delta sync
efficient server reconciliation

All while keeping memory low.

Battery Matters

A lot.

This is one of the biggest reasons I chose request-based architecture.

If no request exists:

WIN RAK does almost nothing.

That means:

less CPU
less network
less GPS
less wakeups

This is healthier for devices.

Especially older phones.

Why This Model Scales Better

Temporary sessions scale better socially.

Not just technically.

Because they respect relationships.

Your partner doesn’t need your location all day.

But maybe:

they worry when you’re late.

Or you’re working.

Or unreachable.

That’s where WIN RAK fits.

Not surveillance.

Coordination.

That distinction is the foundation of everything.

WIN RAK is still evolving.

But one thing is clear:

location sharing should be event-driven.

Not permanent.

Why I Built "WIN RAK": A Privacy-First Alternative to Passive Location Tracking

Omar Elhaitoum — Mon, 29 Jun 2026 23:15:24 +0000

Location sharing has become normal.

Most people use it for simple reasons:

checking if family arrived safely
coordinating with friends
helping elderly relatives
finding children
handling emergencies

But most existing apps solve this with the same model:

continuous passive tracking.

That model always bothered me.

Not because it doesn’t work.

But because it changes the relationship between trust and location.

The Problem with Passive Tracking

Most location-sharing apps work by keeping your position visible all the time.

24/7.

Even when nobody needs it.

Even when nothing urgent is happening.

That creates problems:

unnecessary battery drain
background resource consumption
privacy fatigue
permanent surveillance habits
blurred boundaries between care and control

The more I looked at it, the more I felt the model itself was flawed.

In most real-life situations, people do not need permanent tracking.

They need:

fast, intentional, temporary coordination.

That difference matters.

A lot.

The Idea Behind WIN RAK

I built WIN RAK around one simple principle:

Location should be shared when needed — not all the time.

WIN RAK is a privacy-first real-time geolocation platform designed for trusted contacts.

It works differently.

Instead of exposing location continuously:

A trusted contact sends a request.
The recipient approves it.
A live location session begins.
The session ends when it is no longer needed.

No permanent tracking.

No passive map watching.

No invisible background surveillance.

Only intentional sharing.

Why Consent-Based Sharing Matters

Consent changes everything.

WIN RAK is designed around explicit permission.

Every request follows a clear decision path:

approve
deny
auto-allow
auto-deny
on-hold

That means users stay in control.

Not just technically.

Psychologically too.

That’s important.

Because privacy is not only about encryption.

It’s about control.

Building for Family Safety Without Creating Surveillance

Family safety was one of the main reasons I started this.

Parents often need quick access to a child’s location.

Caregivers may need to locate vulnerable relatives.

Friends may need emergency assistance.

These are legitimate needs.

But they should not require permanent surveillance infrastructure.

WIN RAK tries to solve that balance.

Fast when needed.

Private when not.

Child Safety Should Never Be Locked Behind a Paywall

One decision I made early:

child safety features must remain accessible.

WIN RAK supports paired smartwatches for children.

Guardians can request a child’s location when necessary.

This access remains unlimited.

Because safety should not become a premium-only privilege.

That principle is non-negotiable.

Building It Efficiently

From a technical perspective, WIN RAK is designed to stay lightweight.

Current stack:

Flutter
Dart
Firebase Authentication
Firestore
Cloud Functions
Firebase Cloud Messaging
SQLite
SharedPreferences
Mapbox
Kotlin (Wear OS)

A lot of work went into:

efficient contact detection
reliable request delivery
low memory overhead
battery-aware lifecycle handling
notification durability
smartwatch integration

The goal was never visual complexity.

The goal was reliability.

What Makes WIN RAK Different

WIN RAK is not trying to be another passive tracking app.

It is built for:

trust
emergencies
caregiving
intentional family safety
temporary coordination

That makes it fundamentally different.

Its philosophy is:

Fast. Reliable. Lightweight. Affordable.

And most importantly:

built for trust, not surveillance.

What’s Next

WIN RAK is still in active development.

Current work includes:

stronger subscription systems
desktop integration
improved smartwatch workflows
advanced trusted-contact management
long-term fleet support

The core idea remains the same:

location sharing should respect people.

Technology should support trust.

Not replace it.

If you’re interested in privacy-first mobile systems, Flutter architecture, or consent-based location design, I’d love to discuss it.

Documentation:

https://omarelhaitoum.gitlab.io/win-rak-docs

AI ingestion layer:

https://omarelhaitoum.gitlab.io/win-rak-docs/llms.txt