¡HolaOlas!

learned something building a real booking system in production.

A critical path should never depend on implicit state.

Here’s what I mean.

As long as a user is filling a form, losing state is fine.
Reload the page, start over. No harm done.

But the moment there’s:

• money

• availability

• inventory

• real users involved

everything changes.

If a user clicks “Book” and:

• the page reloads

• the browser crashes

• localStorage is wiped

• Stripe redirects fail

the system must still know the truth.

Not because the frontend remembers it.
But because the backend explicitly does.

Pending reservations.
Clear statuses.
Server-side source of truth.
Time-bound expiration.

A simple mental model I now use:

Form state → can be lost
Commit action → must be persisted
Payment flow → must be resumable or expire cleanly

No “normally it already happened”.
No “the UI should still have it”.

My test now is simple:

If the frontend disappears, does the system still know exactly where it is?

If not, it’s implicit state.
And implicit state eventually lies.

This mindset saved me bugs.
But more importantly, it saved me mental energy.

Curious how others here draw the line between acceptable state loss and critical guarantees.

I launched a B2B app.

Within 24 hours, companies tried to hijack it.
Not users.
B2B companies with vague names, generic promises, and very specific intentions.

They signed up fast.
Too fast.

They didn’t explore.
They didn’t try to understand the product.

They went straight to one thing:
“Where do I connect Stripe?”

That was the first lesson.

Real users wander.
They click around.
They hesitate.
They get excited, then overwhelmed, then come back later.

Fraud doesn’t wander.
Fraud scans.

So I tightened the public surface.
Set guardrails.
Protected visibility.
Let people create, but not instantly broadcast chaos.

I thought that was it.

It wasn’t.

Phase 2: the speedrunners

This time it wasn’t 1 attempt.
It was 6.

Fake company names.
Fake business identities.
Very real Stripe accounts connected within minutes.

No website.
No social presence.
Instagram accounts created three days ago with two cat photos.
A “yoga experience” for 85 people that existed nowhere on earth.

And yet, payment-ready.

Again, same pattern.

Create account.
Ignore everything.
Hunt for Stripe.

Clarity became my best friend.
Watching sessions told the story better than logs ever could.

This isn’t how honest users behave.
This is how people look for valves.

So I closed them.

Hard.

No emails.
No back-and-forth.
No long explanations.

Just a clean in-app message:

“We detected suspicious activity.
Please contact the platform.”

I knew nobody would.
And if I was wrong, I’d apologize and explain.

But I wasn’t.

The uncomfortable truth

If you build something useful,
people will try to abuse it.

Not later.
Immediately.

If your onboarding is too soft,
you’re not being kind.

You’re being naïve.

Filtering early isn’t hostility.
It’s respect for your real users.

So now:

• You want to activate a business?
  Show me you exist.

• No website, no socials, no footprint?
  Fine. Then give me more context.

• You’re connecting Stripe from one country
  for a “local” business in a tiny village
  on the other side of the world?
  Cool. Explain.

Nobody is blocked by default.
But trust is earned progressively.

This app is built for people on the ground.
Not for opportunists speedrunning new products
to see what they can extract.

The lesson

Yesterday it was B2B companies using chaos as a sales tactic.
Today it’s fraudsters looking for fresh surfaces.

Same rule applies.

If you don’t define the framework,
others will test it for you.

Aggressively.

I’m building a solid product.
My reputation matters.
My real clients matter even more.

And I’ll keep tightening the valves.
Quietly.
Continuously.

This is not a one-time fix.
It’s part of the job.

The first sign-ups came in fast.
Too fast.

They weren’t users.
They were very generic B2B companies.
The kind selling “automate your leads”, “AI for growth”, “optimize your funnel”.

They signed up.
They built a first awkward experience.
Then a second one.

Nothing illegal.
Nothing broken.
Just out of bounds.

I noticed it very concretely on my public page.
You know, when a close-up photo of a scalp, clinical vibe,
ends up right in the middle of turquoise Caribbean waters.

In this case, that image wasn’t there by accident.
It was deliberately out of context.

That’s when you realize it’s not an aesthetic problem.
It’s an authority problem.

And you also understand why Squarespace only showcases
the very best sites built on its platform.

While I was dealing with RLS policies, webhooks,
random TypeScript errors coming out of nowhere,
that page was open without guardrails.

A place where some people came to test the limits
(and my nerves) at 2 a.m.,
while I was still figuring out where those limits were.

They weren’t using my product.
They were very clearly showing me
what I hadn’t locked down yet.

Later, I understood why.

That image wasn’t a mistake.
It was a message.

A very concrete way to show me
why I would “need” their service,
by creating chaos exactly where
I hadn’t planned guardrails yet.

I fixed it immediately.

Users can create, test, and iterate.
The public showcase, however, is protected.
New accounts don’t appear there by default.
Public visibility is switched ON
only when the framework is respected.

Since then, the public showcase does its job.

It shows the product.
Not experiments.
Not abuse.
Not disguised sales demos.

The framework is set.
The use cases are clear.
And now, finally,
the product speaks for itself.

Big booking platforms dictate tourism. I didn’t agree, so I built an alternative.

I’m a full-stack developer.
And for the past 5 years, I’ve also been a tour operator, running a fleet of sailboats in Bacalar, Mexico.

When I founded Adorable Sailing, one thing was non-negotiable:
I would never list my business on the big booking platforms.

Why?

Because when you spend 12 hours a day under a burning sun, maintaining boats, managing crews, and welcoming travelers from all over the world,
sending 20% commission to a platform on the other side of the planet feels borderline insulting.

I’m not saying their model is bad.
I’m saying it no longer feels fair for operators on the ground.

These platforms don’t just connect supply and demand.
They dictate tourism worldwide.

Experience creators become dependent in their own businesses.

I’ve always had my own booking system.
But around me, I kept seeing the same reality, over and over again.

So I did what I know how to do best.

I built it.

¡HolaOlas! is not a platform,
it’s not an intermediary,
and it never touches customer money.

Payments go directly to the provider’s own Stripe account.
We’re a tool, not a middleman.

What ¡HolaOlas! actually does

• Create and manage experiences (private, shared, hotels, activities)

• Direct payments via Stripe (deposit or full payment)

• Google Calendar integration

• Cancellations, modifications, refunds

• Multi-currency, multi-language

• Embeddable web component for any website

• Ready-to-use booking pages for providers without a website

• An ultra-simple dashboard, designed for people in the field, not behind a desk

Zero commission.
Zero lock-in.
Zero bullshit.

This isn’t a startup born from a pitch deck.
It’s a tool built inside a real business, with real constraints.

When a tool doesn’t exist,
and it’s necessary,
you build it.

I just launched ¡HolaOlas!.

It’s a commission-free booking and payment system, built from real-world use.

It’s live, handling real reservations and real payments.

I’m intentionally looking for a small group of people to push the system hard, explore edge cases, and tell me where it bends — before more customers rely on it.

If you enjoy pressure-testing real products, you’re welcome.