DEV Community: Adrian Rinnus

The 80/20 landing page rule: Spend 80% here, get 300% more customers

Adrian Rinnus — Mon, 01 Dec 2025 11:47:13 +0000

I was sitting on my couch at 2 AM, phone in hand, staring at my bank account. That sinking feeling in your stomach when the numbers don't add up? Yeah, I had that. Hard.

My co-founders and I had built two solid products. We knew they worked. We knew they solved real problems. But here's the brutal truth: none of that matters if nobody's buying.

The money situation was getting tight. Really tight. And I kept asking myself the same question over and over: "What the hell do we need to do to get more clients?"

The answer hit me like a cold shower: We needed traffic on our landing page AND a landing page that actually converts that traffic into paying customers.

Now, building a page? That's easy for me. I'm a developer. I can spin up a Next.js app in my sleep. But here's where I face-planted: I had no clue WHAT to build. How should it be structured? What goes where? What's the most important section? Where do I even start?

So I went down the rabbit hole. I studied landing pages. I read books. I watched videos. I dissected pages from companies making millions. And what I found changed everything.

The Part Everyone Sees (And Where Most Conversions Die)

Here's a stat that should scare you: 100% of your visitors see your hero section. And most of them? They're gone in 3 seconds if you don't nail it.

Your hero section isn't there to look pretty. It has ONE job: Show people their dream outcome and make them believe they can actually achieve it.

Let me break this down with a real example. Take a trading journal app:

Bad headline: "Track Your Trades Efficiently"

Good headline: "Master Your Trading Strategy in 30 Days - No More Emotional Trades, No More Guessing"

See the difference? The second one shows you the end result. The dream. The thing you actually want.

But showing the dream isn't enough. You need to kill the fear too. This is where most developers (including past me) mess up. We forget that people are scared of:

Losing money
Wasting time
Looking stupid
Getting scammed

So right there in your hero, you derisk everything:

"30-day free trial"
"No credit card required"
"GDPR compliant"
"Cancel anytime"

These aren't just nice-to-haves. They're conversion boosters.

The "So That" Chain (This One's Gold)

Here's a copywriting trick that sounds stupid simple but works like crazy: The "so that" principle.

Start with your product and keep asking "so that" until you hit the real emotional outcome:

"You use a trading journal SO THAT you learn your strategies faster SO THAT you get more confident in them SO THAT you win more trades SO THAT you make more money SO THAT you can quit your job and travel the world."

See how we went from "tracking trades" to "financial freedom"? That's the dream outcome. That's what you sell.

The Effort Equation (Or Why People Don't Buy)

People don't just buy outcomes. They buy outcomes that feel achievable.

Think about it: Would you rather:

"Build your own analytics dashboard from scratch" or
"Get all the statistics you need automatically tracked"?

The second one, right? Because it requires zero effort from you.

This is where your copy does heavy lifting:

"We talked to 1000s of traders so you don't have to"
"We built all the statistics so you don't have to"
"We keep track of your data so you don't have to"

You're literally removing the work from their brain. And that's what sells.

Headlines That Actually Work (The Framework)

Different visitors need different hooks. Here's the cheat sheet I use:

If you're first-to-market (nobody knows what you do):

For achievement-focused products:
"[Achieve Specific Desire] With the [Only/Most Advanced/Largest] [Product Type] That [Does Valuable Unique Thing]"

Example: "Master Options Trading With the Only Journal That Predicts Your Win Rate"

For pain-focused products:
"[Eliminate Problem] With the [Only/Most Advanced/Largest] [Product Type] That [Does Valuable Unique Thing]"

Example: "Eliminate Emotional Trading With the Only Journal That Tracks Your Psychology"

If you're competing (people know the product category):

For achievement:
"The [Only/Most/Largest] [Product Type] That [Achieves Their Main Desire]"

Example: "The Most Advanced Trading Journal That Turns Losses Into Learning"

For pain elimination:
"The [Only/Most/Largest] [Product Type] That [Eliminates Their Main Problem]"

Example: "The Only Trading Journal That Stops Revenge Trading"

Why People Scroll (Or Don't)

Nobody scrolls just because. They need a reason.

Social proof is that reason.

But here's where early-stage founders mess up: If you only have 3 customers, don't write "Join thousands of traders." You look like a liar.

Instead, showcase one or two killer testimonials right in your hero section. Make them specific:

Bad testimonial: "Great product! Really helped me."

Good testimonial: "I went from losing $2,000/month to being profitable in 6 weeks. The strategy breakdown feature alone is worth 10x the price."

See the difference? Numbers. Specifics. Real outcomes.

Design Stuff That Actually Matters

Visual hierarchy isn't design fluff. It's psychology.

The rule is simple: Whatever is biggest and boldest gets read first.

So make your headline huge. Make your dream outcome bold. Make your CTA button impossible to miss.

And here's something that'll boost your conversions by 20-30%: Add a visual to your hero section.

The brain processes images 60,000 times faster than text. 90% of information transmitted to the brain is visual.

Your visual should show:

Who you are and what you do
The transformation your product creates
A compelling story

Video beats images. Images beat nothing.

The 80/20 Rule for Landing Pages

Here's the truth bomb: Spend 80% of your time on the hero section.

I know, I know. You want to build that beautiful testimonials section. You want to show off all your features. You want pricing tables and comparison charts.

But if your hero sucks, nobody sees that stuff anyway.

Get the hero right first. Everything else is secondary.

After the Hero (Keep It Simple, Stupid)

Once you nail the hero, you need to explain your value proposition. Use as many sections as you need, but keep each one simple.

The formula I use:

Increase the pain (remind them of the problem)
Show your solution
Show the outcome
Repeat

And for the love of all that's holy: Talk about pain, not features.

Nobody cares that you have "advanced charting capabilities." They care that they'll "stop losing money on bad trades."

Writing Copy That Converts

Use "YOU" everywhere. Not "we." Not "our product." YOU.

Bad: "Our platform helps traders make better decisions."

Good: "You'll make better trading decisions in your first week."

It's not about the company. It's about the user. Always.

The CTA Strategy (Don't Make People Think)

Your Call-to-Action buttons should be everywhere. Not literally everywhere, but strategically placed so users can convert at any point in their journey.

And make it frictionless:

Ask for "Full name" instead of "First name" + "Last name"
Keep labels visible even when typing
Reduce input fields to the absolute minimum

Your contact page should have:

Simple form (3 fields max)
Social proof nearby
Bullet points showing what happens next
A headline that explains WHY they should take action

Bad headline: "Contact Us"

Good headline: "Get Your Custom Trading Strategy in 24 Hours"

The "Learn More" Hack

Here's a pattern I see on every high-converting page: A "Learn More" button in the hero section.

It's genius because:

People scared of commitment can click it instead of "Sign Up"
It scrolls them down to more info (keeping them engaged)
You can place another CTA at the bottom where they land

Lower friction = higher conversions.

Social Proof Everywhere (Fight the FUD)

FUD = Fear, Uncertainty, Doubt.

Your job is to kill it. Constantly.

Next to every CTA, add trust signals:

"No credit card required"
"Money-back guarantee"
"Used by 1,000+ traders"
Small logos of recognizable companies/brands

And here's the pro move: Use your analytics to see where people drop off. Then place reassuring elements (testimonials, guarantees, stats) right at those spots.

Getting Testimonials That Actually Work

Random "Great product!" testimonials are worthless.

Ask your customers these specific questions:

How did you find us?
What problem were you trying to solve?
How do we help you solve it?
What were your goals?
What was your desired outcome?
What results did you get?

These questions give you testimonials with specifics, numbers, and real transformation stories.

And if you can: Get video testimonials. They convert 2-3x better than text.

The Brutal Truth

I wish I'd known this framework when I was sitting on that couch, stressed about money, wondering how to get customers.

It would've saved me months of building pages that looked good but converted like garbage.

The reality is: Your product doesn't matter if nobody buys it. And nobody buys it if your landing page doesn't do its job.

So spend the time. Get the hero section right. Talk about outcomes, not features. Kill the fear. Make it stupid-easy to say yes.

Because at the end of the day, a great landing page isn't about design or fancy copy. It's about understanding what people want and showing them the fastest path to get it.

Now stop reading and go fix your hero section. Your bank account will thank you.

What part of your landing page are you struggling with most? Drop a comment - I reply to all of them.

Production Is Where Bugs Go to Party 🐛🎉

Adrian Rinnus — Wed, 17 Sep 2025 19:51:27 +0000

This Time I’m Doing Everything Right

I’m sitting in the office, staring at my screen. Dinner is almost ready.

It’s 5:00 PM.

This time I’m doing everything right.

Merge early, leave time for proper testing, prepare my demo script for tomorrow’s presentation.

Not just click through my own features, but also understand the ones my teammates built.

Last time I just merged to production, loaded the data and thought:

“It’ll be fine.”

It wasn’t fine.

The presentation the next day was pure chaos – improvised workarounds and awkward explanations.

But not this time.

I merge the new code into production, open the site – everything looks good.

I lean back, take a deep breath, feel my body relax.

It feels like the calm after the storm.

I head to dinner.

While I’m eating, my buddy calls.

“So, are we still on for sports tonight?”

I look out the window, still optimistic, and say:

“Let’s postpone. I want to use the time to prepare the presentation.”

I get back to my desk, open my demo script.

While clicking through, I test the app again.

Everything works fine in the admin role.

Then I switch roles.

Click → loading spinner → nothing.

My stomach knots up.

My neck tightens.

My pulse jumps.

“Not again…”

I message my teammate:

“Dashboard doesn’t load for user role. Can you check?”

We start debugging together.

Minutes turn into hours.

My plan to go to bed early is long gone.

At 11:30 PM we’re still staring at server logs.

Finally, we find the culprit:

A query that was lightning-fast on my laptop had turned into a snail on the server.

This time, though, we made a conscious decision:

We shipped with the known performance issue and communicated it clearly in the client presentation.

And guess what – it wasn’t a big deal.

My confidence during the presentation mattered more than the bug itself.

I still spent the weekend fixing it –

but this time with a clear plan, not panic.

Now we have a staging environment, realistic data –

and I can merge without my stomach doing somersaults.

How We Walked Right Into the Trap

Looking back, the bug wasn’t really a surprise.

If I’m honest, we almost invited it.

We had been cranking out new code for weeks –

and a lot of it was AI-generated.

And I have to admit: I was excited.

The first suggestions looked great, everything worked locally,

and I felt like I was moving ten times faster than before.

And that’s when I let go of the reins.

I stopped reviewing as carefully.

“If it works, it can’t be that bad,” I told myself.

But with every merge, the code got more complex.

Our RLS policies became more and more nested,

and we had multiple joins across several tables.

On my laptop it all ran like butter.

Even the complex queries took virtually no time.

And that was the trap.

We never tested on the server –

no network latency, no real load, no production-scale data.

In production, these queries suddenly took so long

that the dashboard just sat there loading.

The fix was surprisingly simple – and honestly, liberating:

We eliminated the joins completely by storing the relevant IDs directly in the tables.

The result: 96% runtime reduction.

And the code is now simpler, cleaner, and less error-prone.

The big insight:

We had let complexity creep in without validating it under real conditions.

🎯 My Key Takeaways:

AI code isn’t a free pass. It can speed you up, but it can also lead you into a dead end.
Complexity eats performance. Joins aren’t evil, but they have a cost.
Local ≠ real. My laptop is not the truth. The real world has latency, big data, and nasty edge cases.

Now I know: if everything works perfectly on my machine,

that just means the real test is still ahead.

The New Solution: Staging Born Out of Necessity

After that release, it was clear:

We couldn’t risk shipping slow code to production again.

The system was already in use – one more major issue could break trust.

So a staging environment went from “nice-to-have” to mandatory.

Our challenge:

We don’t have revenue yet – that comes after the successful release.

We needed a way to deploy staging cheaply but with realistic conditions.

Here’s what we did:

Second Supabase account:

The free tier only gives you two databases,

which were already used by our production products.

So we spun up a second account.

It runs a copy of the production schema with anonymized data.
Deployment on AWS Amplify:

Not because Vercel is bad – we actually like Vercel –

but we have AWS Startup Credits.

This means our staging deploys are effectively free.

The only “extra” step compared to Vercel:

you need to create an amplify.yml and add all your env variables there.

Once done, it just works.
Logs:

They’re not as pretty as Vercel’s,

but they get the job done.

The best part:

Every developer can use staging.

We can log in, switch roles, run through real scenarios –

and do it all without touching production data.

This setup made all the difference.

We were able to test our performance optimizations against staging data

and, in just one weekend, deliver a solution that made our queries 96% faster –

without shipping more bugs to production.

🎯 My Key Takeaway:

Staging isn’t just a safety net –

it’s a turbocharger for structured debugging.

It gave us realistic conditions, let us isolate problems,

and helped us deploy with a clear head.

A New Release Process – Finally Calm

Releases used to feel like Russian roulette.

Merge straight to main, test quickly, cross fingers, deploy.

If it blew up, we’d fix it at midnight or sweat it out in front of the client.

Now it’s a whole different story.

We start by creating a release branch.

This gets deployed to staging with anonymized production data.

Then we do what we never did before:

we test together.

Everyone on the team clicks through their features,

switches roles, tries real user flows.

The result:

We catch issues before they reach the client.

We can even run performance tests safely,

without risking downtime.

When everything looks good, we merge to main, deploy to production –

and breathe easy.

No more heart racing, no more stomach knots, no more late-night log marathons.

Just a clear, repeatable process.

🔑 Key Takeaway:

Having a clear release process with staging already removed a lot of stress.

The next step is to add automated tests –

so we can keep shipping fast without fear of breaking things.

Want to follow along as we add more automation,

refine our release process, and learn more lessons the hard way?

Follow me – I share everything I learn as we go.

And if you’re up for it:

Tell me your worst production bug story

or how you handle staging and testing in your projects.

I genuinely reply – I probably learn as much from you as you do from me.