DEV Community: Motion

We Thought React Native Was the Answer... Until Our App Hit 190% CPU 🔥📱

motion team — Wed, 09 Jul 2025 15:12:35 +0000

TL;DR: React Native seemed perfect for our productivity app until performance became unbearable. Here's why we switched to native and the dramatic results we achieved.

The Breaking Point 💔

Our React Native desktop app was consuming 190% CPU for a simple productivity tool. Users complained about:

Severe battery drain 🔋
Fan noise from overheating 🌡️
Sluggish system performance 🐌
App crashes under load 💥

What We Found 🔍

1. Bridge Tax
Every JS ↔ Native call adds overhead:

///Each call crosses the expensive bridge
const windows = await nativeModules.getWindows();
const activeApp = await nativeModules.getActiveApplication();

2. Re-rendering Hell
Components re-rendering 60+ times per second:

const TaskList = ({ tasks, filters, sortBy }) => {
  const filteredTasks = useMemo(() => {
    return tasks.filter(/* expensive filtering */)
  }, [tasks, filters, sortBy]); // Dependencies changing constantly
};

3. Memory Leaks in Native Modules
Poor resource cleanup in custom modules.

The Numbers Don't Lie 📊

React Native vs Native Performance:

CPU Usage: 190% → 15%
Memory: 400MB → 100MB
Cold Start: 3.2s → <1s
Battery Impact: High → Minimal

The Native Solution 🚀

We rebuilt using Swift/SwiftUI with performance-first design:

//Efficient window monitoring
class WindowMonitor: ObservableObject {
    private var eventTap: CFMachPort?

    func startMonitoring() {
        eventTap = CGEvent.tapCreate(
            tap: .cgSessionEventTap,
            place: .headInsertEventTap,
            options: .defaultTap,
            eventsOfInterest: CGEventMask(eventMask),
            callback: { /* efficient callback */ }
        )
    }
}

Results 🌟

CPU usage: 190% → 15% 📉
Memory: 75% reduction 🗜️
Launch time: 60% faster ⚡
Silent operation (no more fan noise!)

When to Choose What 💡

React Native is great for:

Content-heavy apps
Standard UI patterns
Rapid prototyping
React-heavy teams

Go native when you need:

Performance-critical apps
Heavy system integration
Resource efficiency
Background processing

The Bottom Line 🎯

React Native isn't bad—it's just not right for every use case. For Motion's requirements (system integration, background processing, resource efficiency), native was the clear winner.

The key is recognizing when to make the switch before performance problems become user complaints.

Read the full technical deep-dive: Motion Engineering Blog

Building high-performance productivity software at Motion. We're always looking for talented engineers who care about performance and user experience. Join our team!

We Replaced 5 Years of Infrastructure Debt with TypeScript. Here's How.

motion team — Mon, 07 Jul 2025 18:30:23 +0000

Five years of different people clicking buttons in dashboards. Zero documentation. Pure tribal knowledge that walked out the door when people left.
Every deployment felt like Russian roulette because our setup was essentially unreproducible.

The Question That Changed Everything 💡

Sebastian joined our team and asked one simple question:

"What happens if we need to rebuild this from scratch?"

The honest answer was terrifying. We couldn't. Nobody could.

The Infrastructure Horror Story We All Know Too Well

Our Reality Check:
- 5 years of "it works, don't touch it"
- 0 documentation
- 100% tribal knowledge
- Every deploy = prayer circle
- New engineers = 3 months to understand anything

Sound familiar? Yeah, we thought so.

One Engineer. One Mission. Zero Terraform Patches.

While most would try to document the mess or patch the existing Terraform, Sebastian made a bold call:

Rebuild everything using Pulumi + TypeScript.

Why?

Same language across our entire stack
Proper modular design
Type safety for infrastructure
Actual documentation that updates with code

The Transformation 🚀

// Before: Nobody knows what this does
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  # ... 500 more lines of mystery
}

// After: Self-documenting infrastructure
const webServer = new aws.ec2.Instance("web-server", {
  instanceType: aws.ec2.InstanceType.T3_Micro,
  ami: ubuntu20.then(ami => ami.id),
  userData: renderStartupScript(),
  tags: { 
    Purpose: "Handles API traffic",
    Owner: "platform-team" 
  }
});

The Results After One Year

From 3 months → 1 week for new engineers to understand our infra
From "prayer deploys" → 30-minute production deployments**
From 0 → 100% infrastructure reproducibility -** From tribal knowledge → living documentation**

Any developer on our team can now understand, modify, and deploy our infrastructure.

This Is How We Think at Motion

Sebastian didn't wait for permission. He didn't form a committee. He saw a critical problem and owned the solution completely.
This is the engineering culture we're building at Motion: identify what's broken, take ownership, and ship the fix.

The Full Infrastructure Rebuild Playbook 📖

We documented every step, every decision, and every lesson learned from this migration. No gatekeeping.
Get the complete guide here: How We Rebuilt Our Infrastructure From Scratch

We're hiring. If you're the type of engineer who sees "nobody understands this system" as a challenge rather than an excuse, let's talk: https://jobs.ashbyhq.com/motion/4f5f6a29-3af0-4d79-99a4-988ff7c5ba05

How One Engineer Saved Us $110K and Ended Our Database Nightmare 🚀

motion team — Tue, 24 Jun 2025 20:16:35 +0000

We were in crisis mode. Every week brought a new Sev0. Our database was going down repeatedly, bleeding money and eroding customer trust. Something had to change—fast.

Enter Sean, who took ownership in the most literal way possible.

The Problem That Was Killing Us 💀

Weekly database outages disrupting thousands of users
Escalating infrastructure costs eating into our runway
33% slower latencies frustrating our customers
Engineering morale plummeting from constant firefighting

One Engineer. One Mission. Zero Committee Meetings.

While most companies would form a task force, create a 6-month migration plan, and debate endlessly, Sean did something different. He rolled up his sleeves and single-handedly migrated our entire database to PostgreSQL.

No endless planning meetings. No bureaucracy. Just pure engineering ownership.

The Results Speak for Themselves 📊

Before Migration:

Weekly outages
$150K+ annual database costs
300ms average latency
Stressed on-call team

After Migration:

ZERO outages since migration ✅
$110,000+ annual savings 💰
200ms average latency (33% faster) ⚡
Happy engineers, happy customers

This Is How We Build at Motion

Sean's story isn't unique at Motion—it's our standard. We believe in:

Complete ownership: See a problem? Own the solution.
Swift execution: Ship fast, iterate faster.
Impact over process: Results matter more than meetings.

Why We're Sharing This

We're launching the Motion engineering blog because stories like Sean's deserve to be told. Real engineering. Real impact. Real lessons learned.

Whether it's database migrations, scaling challenges, or innovative solutions—we'll share the unfiltered truth about building products that matter.

Read the full technical deep-dive: Migrating to Postgres

We're hiring engineers who think like Sean. If you see a problem and your first instinct is to fix it rather than schedule a meeting about it, let's talk! https://jobs.ashbyhq.com/motion/4f5f6a29-3af0-4d79-99a4-988ff7c5ba05