Forem: Serhiy

We Solved Most Mac Problems in 4 Months - Here’s How

Serhiy — Tue, 07 Apr 2026 11:45:27 +0000

We Built an All-in-One Mac Tool in 3 Months (Because We Were Sick of Overpriced Apps)

We tried not to use AI to write this post - because the ideas are ours
(Okay, maybe some phrasing help 😋)

We built Brow in ~3 months

Two senior devs
No big team
Just Claude Max running at 100% almost 24/7 and a lot of trying something → seeing if it works → fixing it if it doesn’t → repeating

Why we built it

It started with a simple question:

What do we actually use on our Macs?

We looked at tools like Raycast (we’ve used it for years).

Great product - but in reality?

We were using maybe 5 - 10 plugins max

You install a lot of them…

But most of the time, you don’t even remember they exist

The other 99%?
Just noise

The problem

Mac apps that really solve the problems are expensive

And worse, they’re fragmented

Want to:

limit battery charging?
control fans?
clean storage?
fix your menu bar?
connect Android phone?
adjust display settings?
and many more...

Cool

Now download 10–20 different apps

…and pay for each of them separately

Yeah, no thanks

What we did instead

We built the tool we wanted to use

Something that is:

simple
fast
actually useful
with a minimalistic design

One app that solves most real Mac problems

Not everything
Just the stuff people actually use

Built with Claude (and what actually worked)

We used Claude heavily, basically non-stop

But here’s the part most people get wrong:

1. Don’t start the feature implementation from scratch

If something already exists - ask claude to deeply research that topic first

Plan → then build.

This saves insane amounts of time and tokens

2. The beginning matters more than you think

Architecture is everything

Even with AI

We rewrote the core 3 times to get it right and push performance to the limit

Painful, but worth it

Now adding features is:

faster
cleaner
way less buggy

3. Most “AI dev hype” is noise

Agents, MCPs, complex setups…

Honestly?

Didn’t matter much.

What worked:

good prompts
clear structure
tight feedback loops (give Claude the ability to check what he did)

Build → check → fix → repeat

That loop wins

Pricing (and why)

We made almost everything free

Only AI features are paid - because they cost money for us.

No tricks

Distribution

No ads
No big launch

Just:

SEO
people finding it
people using it

And we’re good with that

Why we’re sharing this

We’re building this for ourselves

And for people who are tired of:

overpriced Mac apps
bloated tools
solving one problem per app

If that’s you - try it

Break it
Tell us what sucks

We’ll fix it

Goal

One app that fixes most of the stuff Apple didn’t

See ya
And Brow it 😄

Brow (Why We Built Brow in Swift, Not Electron)

Serhiy — Fri, 20 Mar 2026 16:30:39 +0000

A lot of Mac utilities talk about speed.

What matters more is why they feel fast, where the limits come from, and what trade-offs the architecture creates later.

That was one of the earliest decisions behind Brow: build it as a native Swift app from day one.

Not because “native” sounds good in marketing.

Because for the kind of product we wanted to build — launcher, notch layer, system utilities, hardware-aware modules — architecture changes what is possible.

The real question was never just “Swift vs Electron”

The real question was:

Do we want a Mac app that happens to run on macOS, or a Mac app that is built for macOS from the inside?

Electron is a valid choice for many teams. It optimizes for one codebase, faster iteration, and easier cross-platform shipping.

Raycast took a different route. Its app is native, but its extension ecosystem is built around React, TypeScript, and Node so developers can build on top of it quickly.

That is a smart trade-off.

But it is still a trade-off.

We wanted a different one.

Where the difference starts to matter

If you compare products like Brow and Raycast, the real difference is not just “which launcher is faster”.

The deeper difference is this:

how much of the product sits directly on native macOS frameworks
how much UI or extension logic depends on web tooling
how much low-level system behavior you can control directly
how much overhead you carry as the product grows

That architecture decision affects everything after it.

Why we chose Swift for Brow

We built Brow in Swift because we wanted the critical path to stay native.

That means no Electron shell, no Chromium runtime, and no browser stack in the core app flow.

For us, that mattered for four reasons.

1. Native system access is not a nice-to-have

Once you move beyond “open apps and search commands”, launcher products start touching awkward parts of the OS:

window management
clipboard pipelines
display control
hardware stats
menu bar behavior
screenshot flows
accessibility hooks
notch-adjacent UI

These are not areas where web-style abstraction helps much.

They are areas where being close to AppKit, Swift, macOS services, and system APIs matters.

This does not mean every Mac app must be written fully in Swift.

It means that if deep OS integration is central to the product, native architecture compounds in your favor.

2. Extension velocity and product coherence usually pull in opposite directions

This is one of the most interesting trade-offs in tools like Raycast.

A React/TypeScript-based extension system makes extension development much more accessible to web developers.

That helps ecosystem growth.

But it also means the platform has to constantly mediate between:

native host behavior
extension runtime constraints
API boundaries
consistency across third-party commands

That model is great for extensibility.

It is not automatically great for tight, system-level product design.

We wanted tighter control over behavior, performance envelopes, and module integration — even if that meant a slower road to ecosystem scale.

3. “Fast” is not only about launch time

People often reduce desktop performance to one thing: how quickly the window appears.

That matters, but it is only the surface layer.

The more important questions are:

How much memory does the product carry at idle?
What happens when multiple modules are active?
How much work is happening in the background?
How direct is the rendering path?
How many layers are sitting between intent and UI update?

For us, the goal was simple:

keep the stack small, direct, and native.

That is the advantage of building the core this way.

4. The longer-term constraint is complexity, not initial speed

Web-heavy architectures often win early.

They are easier to prototype, easier to staff, and easier to ship across platforms.

But the question we cared about was not:

What gets us to v1 fastest?

It was:

What architecture do we still want when the app becomes much more ambitious?

Because once a launcher becomes a platform, every abstraction starts charging rent.

That rent appears as:

more edge cases
more memory pressure
more runtime boundaries
more UI inconsistency
more special handling for modules that do not quite fit

Native code is not magically simple.

But for a Mac-only product, it can keep the stack more honest.

Is Brow better than Raycast?

That depends on what you value.

Raycast has a strong ecosystem, a mature extension story, and a smart developer adoption strategy.

But our argument is narrower:

For the kind of product Brow wants to be, staying fully native in the core gives us better foundations.

Not universally better.

Better for:

deep macOS integration
tighter control over performance behavior
lower architectural overhead in the core path
building features that feel like part of the OS, not layered on top of it

That was the point of choosing Swift.

The trade-off we accepted

This path is slower.

The ecosystem is smaller.

The tooling is narrower.

Some things are harder than they would be in web stacks.

But you also get something important in return:

a product whose architecture matches its platform.

For Brow, that trade was worth it.

Original posts: