Halfdan Harring

Posted on May 21

How I, Halfdan Harring, Moved to Cursor, Vibe Coding, Firestore and Capacitor

#react #firebase #webdev #cursor

I’m Halfdan Harring, a fullstack developer from Denmark, and over the last period I’ve changed the way I build software quite a lot.

Not in a “I discovered one secret framework and now everything is fixed forever” way.

More like:

I stopped treating coding like bricklaying and started treating it like directing a very talented, slightly chaotic junior developer who never sleeps.

That junior developer is Cursor.

And the stack that makes the whole thing actually work for me is usually:

Cursor
React
TypeScript
Firebase
Firestore
Capacitor
a very large amount of coffee
and the occasional conversation with myself that starts with: “Why is this state updating twice?”

From traditional coding to vibe coding

“Vibe coding” sounds unserious.

And sometimes it is.

But for me, vibe coding does not mean:

“I have no idea what is happening, but the AI said ship it.”

That is not vibe coding. That is gambling with a keyboard.

For me, vibe coding means working from product intent first.

Instead of starting with:

“I need to write 47 files.”

I start with:

“This screen should feel like WhatsApp.”

“This running map should behave like Google Maps navigation.”

“This SaaS dashboard should feel simple enough that a non-technical business owner can use it.”

Then I use Cursor to move much faster from idea to working product.

I still need to understand the architecture. I still need to make decisions. I still need to review the code. But I no longer need to manually type every boring piece of glue code like it is 2014 and I am being punished by a forms library.

Why Cursor changed the workflow for me

The biggest shift is not that Cursor writes code.

The biggest shift is that Cursor lets me think in systems.

I can describe:

the UX
the user flow
the data model
the edge cases
the business rules
the feeling of the product

And then I can ask Cursor to help turn that into real code.

That is powerful because most software does not fail because someone forgot how to write a button.

It fails because the product intent was blurry.

Cursor is best when I am specific about what I want.

Bad prompt:

“Make this better.”

Good prompt:

“Redesign this onboarding flow so a first-time user understands the product in under 10 seconds. Keep the existing Firebase auth flow, preserve the current route structure, and split the UI into reusable React components under 250 lines each.”

That is where Cursor starts to feel less like autocomplete and more like a product-building partner.

Why Firestore fits this way of building

Firestore is almost suspiciously good for this kind of workflow.

When I build MVPs, SaaS tools, internal systems or mobile apps, I usually want to move fast on:

users
permissions
profiles
activity feeds
chat
notifications
app settings
subscriptions
content
admin tools
logs and events

Firestore gives me a database that is flexible enough to evolve while the product is still finding its shape.

That matters a lot when you build with AI-assisted tools.

Because in the early stage, the product is alive. The data model changes. The UX changes. The “simple feature” suddenly becomes a monster with three heads and a settings page.

With Firestore, I can move quickly without spending the first week designing a perfect relational schema for a product that might change tomorrow.

It lets me build like this:

Create the first version.
Test the flow.
See what the product actually wants to become.
Refactor the structure when the pattern becomes clear.

That fits vibe coding very well.

Not because structure does not matter.

But because premature structure can also kill speed.

Firestore is not magic, though

Firestore is great, but it does not remove the need to think.

You still need to care about:

document structure
security rules
indexes
read costs
denormalization
permissions
naming conventions
migration strategy

The trick is not to treat Firestore like a junk drawer.

The trick is to treat it like LEGO.

Flexible, fast, modular — but still painful if you step on it barefoot at 02:13.

When working with Cursor, I try to be very explicit about Firestore structure.

For example:

“Use a users/{userId} document for profile data, a projects/{projectId} collection for app projects, and keep user-specific permissions in projectMembers/{userId} documents. Do not duplicate private user data into public documents.”

The clearer the Firestore model is, the better Cursor performs.

AI coding gets much better when the database has a clear mental model.

Why Capacitor is part of the equation

Capacitor is another reason this workflow works for me.

I like building web apps with React, but I also like shipping things that feel close to native on iOS and Android.

Capacitor gives me a bridge between those worlds.

I can build a React app and still access native-ish things like:

push notifications
haptics
camera
app links
storage
status bar handling
native sharing
mobile app packaging

That is useful because many app ideas do not need a fully native Swift or Kotlin build from day one.

They need to feel real.

They need to be installable.

They need to be testable on a phone.

They need to get into users’ hands before the founder spends six months polishing an architecture diagram that nobody asked for.

Capacitor fits my way of building because it lets me move from:

“This is a web prototype”

to:

“This is an actual app on my phone”

much faster.

And when you combine Capacitor with Cursor, the feedback loop gets very short.

Idea → prompt → code → test on phone → adjust → repeat.

That loop is addictive in the best possible way.

The real unlock: product taste + AI speed

The more I use Cursor, the more I think the future is not “AI replaces developers.”

It is more like:

AI makes taste, clarity and product judgment more valuable.

Because if everyone can generate code faster, the difference becomes:

Who knows what to build?
Who can describe it clearly?
Who understands users?
Who can spot bad UX?
Who can keep the codebase from becoming spaghetti with a login screen?
Who can say no to features that do not matter?

Cursor can produce a lot of code.

That is both the magic and the danger.

The job is not just to generate.

The job is to direct.

My current rule for AI-assisted coding

I try to follow this rule:

Let AI help with speed, but do not outsource taste.

Cursor can help me write components, refactor files, debug state, generate Firebase functions and think through edge cases.

But I still need to own the product.

I need to know when something feels wrong.

I need to know when the UI is too complicated.

I need to know when Firestore structure is becoming messy.

I need to know when a mobile app feels like a website wearing an App Store costume.

That last one is especially important with Capacitor.

A Capacitor app should not feel like a web page trapped inside a phone.

It should respect mobile patterns, gestures, safe areas, loading states, haptics and transitions.

That is where the craft still matters.

What I’m building around this workflow

I use this workflow for building SaaS products, app ideas, internal tools and client projects.

My focus is usually the same:

build fast
keep the product simple
make the UX feel real
use Firebase/Firestore for speed
use Capacitor when the product needs to live on mobile
use Cursor to move from idea to implementation faster

I write more about my work here:

I’m especially interested in the new type of developer workflow where you are part engineer, part product designer, part prompt writer, part chaos manager.

It is weird.

It is powerful.

And honestly, it is a lot more fun than pretending every MVP needs enterprise architecture on day one.

Final thought

Cursor, Firestore and Capacitor work well together because they all support the same kind of building:

Fast feedback.

Real products.

Small teams.

Less ceremony.

More shipping.

For me, that is the interesting part.

Not AI as a gimmick.

Not vibe coding as a meme.

But a new workflow where one person can go from idea to usable product much faster — if they have enough taste, discipline and curiosity to keep the machine pointed in the right direction.

I’m Halfdan Harring, and this is the way I build now.

DEV Community