DEV Community: Flaviu Z

Your Database Is Small. That Doesn’t Mean Your Queries Are Fast

Flaviu Z — Sun, 04 Oct 2026 20:43:38 +0000

“My database is only 50 MB. Why is my API slow?”

It's an easy assumption to make.

Small database = fast database.

Unfortunately, database size tells you surprisingly little about how quickly a particular request will execute.

You can have gigabytes of data and extremely fast queries.

You can also have a tiny database and an endpoint that takes two seconds.

The interesting question isn't:

How big is the database?

It's:

What are you asking the database to do?

One request might actually be 50 queries

Imagine loading a page containing 50 products.

You query the products:

SELECT * FROM products LIMIT 50;

Fast.

Then, for every product, your application separately requests the seller.

Suddenly:

1 query for products

50 queries for sellers = 51 queries

You haven't got a large database.

You've got an inefficient access pattern.

This is the classic N+1 query problem.

Depending on your ORM, it can also be surprisingly easy to create without noticing.

Indexes matter

Suppose you frequently search users by email:

SELECT * FROM users WHERE email = ?;

With a suitable index, the database can locate matching records efficiently.

Without one, it may need to examine far more data.

As your dataset grows, the difference becomes increasingly noticeable.

But adding indexes everywhere isn't the solution either.

Indexes consume storage and have a cost when writing data.

The goal is to index based on actual query patterns.

Your database may not even be the bottleneck

Let's say an API endpoint takes 800ms.

It's tempting to blame PostgreSQL or MySQL.

But maybe the query takes 40ms.

The rest could be:

authentication,

external API calls,

serialization,

application logic,

network latency,

file operations,

or several sequential operations.

Optimizing a 40ms database query down to 20ms won't fix an 800ms endpoint.

Measure before optimizing.

Sequential requests add up

Consider:

Get user 100ms
Get orders 150ms
Get messages 200ms
Get statistics 180ms

If these operations unnecessarily run sequentially, the user could wait around 630ms.

If independent operations can safely run concurrently, the experience may be very different.

The individual operations weren't necessarily slow.

The architecture made them slow together.

Location matters too

Imagine:

User → US

Application server → Europe

Database → Europe

Even if your database query is extremely fast, the user still has to communicate with infrastructure thousands of kilometers away.

Now imagine the frontend makes several sequential requests.

Network latency gets multiplied by application design.

This is one reason a site can feel fast for the developer and slow for users elsewhere.

Cache what makes sense

Not everything needs to hit the database every time.

Some information changes constantly.

Other information might remain identical for hours.

If something is expensive to calculate and frequently requested, caching may help significantly.

But caching everything introduces its own problems.

Now you have to think about invalidation and stale data.

As usual, the answer isn't:

“Use caching.”

It's:

“Understand what you're caching and why.”

Look at the query plan

When a query becomes suspicious, don't immediately start rewriting your entire backend.

Ask the database what it's doing.

For PostgreSQL, EXPLAIN and EXPLAIN ANALYZE can show how the database plans and executes a query.

That can reveal things like sequential scans, expensive joins, unexpected row counts, and inefficient execution plans.

It's much better than optimizing based on intuition.

Measure first

Before changing infrastructure, collect some basic numbers:

Request duration: 920ms
Database: 85ms
External API: 610ms
Application logic: 40ms
Other/network: 185ms

Now the problem is obvious.

Changing database providers probably won't save you.

That 610ms external request deserves your attention.

Small doesn't mean fast

Performance isn't determined by how many megabytes your database consumes.

It depends on:

queries + indexes + application logic + network + architecture + workload

So the next time an API feels slow, don't start with:

“Do I need a bigger server?”

Start with:

“Where are those milliseconds actually going?”

That question will usually save you a lot more time — and potentially a lot more money.

Why More Traffic Won’t Fix a Product People Don’t Understand

Flaviu Z — Sun, 04 Oct 2026 20:39:34 +0000

When you're building an online product, low traffic feels like the obvious problem.

You check analytics and see 30 visitors.

The natural reaction is:

“I need more traffic.”

So you start thinking about SEO, ads, social media, backlinks, content, and every possible acquisition channel.

But there's a problem.

If 30 people visit your product and none of them understand what they're supposed to do, sending another 3,000 people probably won't solve much.

It will just help more people become confused.

Traffic amplifies what already exists

Imagine two landing pages.

The first converts 1% of visitors.

The second converts 5%.

Send 10,000 visitors to each:

Product A gets 100 conversions.

Product B gets 500.

Same traffic.

Completely different result.

That's why acquisition and product experience shouldn't be treated as separate problems.

Traffic is a multiplier.

If the underlying experience is weak, you're multiplying something weak.

The five-second test

Open your homepage and pretend you've never seen it before.

Within roughly five seconds, can you answer:

What is this?

Who is it for?

What can I do here?

This sounds ridiculously simple.

But when you've spent months building something, you already know how everything works.

Your visitors don't.

Terms that seem obvious to you might mean nothing to them.

Buttons you notice immediately might be invisible to someone visiting for the first time.

Features aren't positioning

This is something I've had to think about while building NexoRush.

A marketplace can have payments, profiles, search, messaging, recommendations, dashboards, reviews, and dozens of other features.

But listing all of those features doesn't necessarily explain why someone should use the product.

Users aren't looking for dashboards.

They're looking for outcomes.

A buyer doesn't wake up thinking:

“I really need a marketplace with advanced filtering today.”

They're thinking:

“I need someone to fix my website.”

That's a completely different way of looking at the product.

Watch what users do, not what you expect them to do

As developers, we design flows logically.

Homepage → Search → Profile → Checkout.

Then a real user arrives.

Homepage → About → Back → Random category → Homepage → Leave.

The user isn't wrong.

Your assumptions were wrong.

Analytics become much more useful when you stop asking only:

“How many visitors did I get?”

and start asking:

“What did those visitors actually do?”

Where did they leave?

Which pages did they visit?

Did they start the main workflow?

Did they complete it?

Fix leaks before opening the faucet

This doesn't mean you should wait for a perfect product before getting traffic.

You need visitors to learn.

But there's a difference between getting enough traffic to discover problems and spending heavily to scale traffic before fixing them.

Think of acquisition like opening a faucet.

If the bucket has holes, increasing the water pressure isn't the first problem to solve.

Fix the biggest holes.

Then increase the flow.

A useful metric isn't always visitor count

Early products often don't need millions of pageviews.

Sometimes 100 relevant visitors teach you more than 10,000 random ones.

I'd rather know:

how many people understood the product,

how many started the primary workflow,

where they stopped,

whether they returned,

and whether they achieved what they came for.

Those numbers tell you something about the product.

Traffic alone mostly tells you that someone managed to find it.

Distribution still matters

Of course, you eventually need distribution.

A great product nobody discovers isn't much better.

But acquisition becomes significantly more valuable once visitors understand the product and can reach its core outcome without unnecessary friction.

So before asking:

“How do I get 10x more traffic?”

it may be worth asking:

“What would happen if I actually got it?”

If the answer is “most visitors would leave,” you probably already know what to work on next.

Your Next.js App Feels Slow, but Lighthouse Says It’s Fast. Why?

Flaviu Z — Sat, 03 Oct 2026 02:27:16 +0000

You run Lighthouse.

Performance: 95.

Everything looks great.

Then you actually use the application.

You click a button.

Wait.

Open a dashboard.

Wait.

Submit a form.

Wait again.

Technically, your website is “fast.”

But it doesn't feel fast.

This is something that can be confusing when optimizing modern web applications, especially with frameworks like Next.js.

The reason is simple:

Page speed and perceived performance aren't exactly the same thing.

Lighthouse doesn't experience your app like a user

Performance tools are incredibly useful.

They can identify problems with things like:

Largest Contentful Paint

Cumulative Layout Shift

blocking resources

image optimization

JavaScript execution

caching

But users don't care about performance scores.

They care about what happens after they click something.

A page can load extremely quickly and still have interactions that feel slow.

The first load isn't the entire experience

Imagine a dashboard.

The initial page loads in 800ms.

Great.

Then the user clicks Orders.

Your application sends an API request.

The API queries the database.

The database takes 600ms.

The server processes the response.

The browser receives it.

React renders the result.

Suddenly the user has been waiting more than a second.

Your homepage performance score didn't tell you much about that experience.

For applications, you have to think about the entire chain:

User → Browser → Server → Database → Server → Browser → UI

Every step can introduce latency.

Loading states change how speed feels

Consider two applications.

Application A:

User clicks a button.

Nothing happens for 900ms.

Then the new page appears.

Application B:

User clicks a button.

The interface immediately shows that something is happening.

The new page appears after the same 900ms.

Technically, both took the same amount of time.

But Application B usually feels faster.

That's why loading states, skeletons, optimistic updates, and immediate visual feedback matter.

Performance isn't only about reducing milliseconds.

It's also about communicating what's happening during those milliseconds.

Don't fetch everything immediately

Another common problem is loading information that the user hasn't requested yet.

Imagine a dashboard containing:

profile information

notifications

messages

analytics

recent transactions

recommendations

It's tempting to fetch everything when the dashboard opens.

But does the user need everything immediately?

Probably not.

Prioritize what is visible and important.

Load secondary information later when appropriate.

A smaller initial workload can make the interface feel significantly more responsive.

Database latency becomes frontend latency

Frontend developers sometimes optimize everything in the browser while ignoring what happens behind the API.

Suppose your API request takes 1.5 seconds.

Removing 30ms of JavaScript isn't going to fix the experience.

Look at the entire request.

Maybe you're making multiple database queries when one would work.

Maybe a column isn't indexed.

Maybe you're repeatedly requesting information that could be cached.

Maybe your application server and database are geographically far apart.

Maybe you're performing expensive operations synchronously.

The bottleneck might have nothing to do with React.

Geography matters more than you think

If your server is in Europe and your user is also in Europe, network latency may barely be noticeable.

Now put the user in California.

Every request has to travel significantly farther.

And applications rarely make just one request.

A small amount of additional latency multiplied across many sequential operations can create a noticeably slower experience.

This is where CDNs, caching, edge infrastructure, and good server placement become important.

But that doesn't automatically mean you need servers everywhere.

Sometimes fixing unnecessary requests gives you a bigger improvement than adding infrastructure.

Be careful with premature infrastructure

When developers discover latency, it's easy to jump immediately to:

“We need multi-region infrastructure.”

Maybe.

But first ask why the application is making those requests.

If one interaction triggers eight sequential API calls, deploying the same inefficient architecture to five regions doesn't solve the underlying problem.

Measure first.

Optimize second.

Scale infrastructure when the measurements justify it.

Measure what users actually do

Instead of only testing the homepage, test workflows.

For example:

Measure how long each step takes.

You may discover something interesting.

Perhaps the initial page load is excellent, but saving an item takes two seconds.

That's probably where optimization will have the greatest impact.

The Next.js documentation is a good starting point for understanding the framework's caching, rendering, and optimization options, but architecture still depends heavily on your application's actual behavior.

Performance is a system problem

Modern web performance isn't just:

“How quickly does my HTML load?”

It's the combined result of:

Frontend + API + Database + Network + Infrastructure + UX

That's why chasing a perfect Lighthouse score can sometimes send developers in the wrong direction.

A 100/100 score is nice.

But I'd rather have an application scoring 90 that feels instantaneous during real workflows than one scoring 100 whose users stare at frozen buttons after every click.

Measure the experience, not just the score.

I Stopped Asking “What Feature Should I Build Next?”

Flaviu Z — Sat, 03 Oct 2026 02:20:20 +0000

When you're building a product, adding features feels like progress.

New dashboard.

Better search.

More filters.

Notifications.

AI integration.

Analytics.

Every new feature makes the product look more complete.

But at some point, I realized I was asking the wrong question.

Instead of:

“What feature should I build next?”

I started asking:

“What is stopping someone from completing what they came here to do?”

Those two questions lead to very different products.

Developers naturally see missing features

When you spend hours looking at your own application, it's easy to notice everything it doesn't have.

Competitor A has advanced filters.

Competitor B has a better dashboard.

Competitor C has AI recommendations.

Suddenly, your backlog contains 40 things.

The problem is that users don't experience your product as a feature checklist.

They arrive because they want something.

For a project management tool, they want to organize work.

For an e-commerce platform, they want to sell something.

For a freelance platform, they want to find someone who can solve a problem.

Everything between the user and that outcome is friction.

A feature can actually create more friction

This sounds obvious, but it's surprisingly easy to forget.

Imagine a search page with 15 filters.

From a development perspective, that's powerful.

Users can filter by:

location

experience

price

rating

availability

language

technology

Why Hiring a Developer Is Still Hard When There Are Thousands Available

Flaviu Z — Fri, 02 Oct 2026 00:14:38 +0000

There are more developers available online than ever before.

You can find frontend developers, backend engineers, WordPress specialists, AI developers, DevOps engineers, and entire development teams within minutes.

So hiring a developer should be easy.

Strangely, it isn't.

The problem is no longer access to talent.

The problem is figuring out which talent is actually right for the job.

A tech stack isn't a job description

Imagine a startup needs someone to work on an application built with:

Next.js

TypeScript

PostgreSQL

Stripe

AWS

Searching for developers who know these technologies could produce hundreds or thousands of candidates.

But knowing Next.js doesn't necessarily mean someone can maintain a production application.

Knowing Stripe doesn't mean they've built complex payment flows.

And listing AWS on a profile tells you almost nothing about what they've actually done with it.

Skills are useful filters, but they're weak signals when used alone.

Years of experience can be misleading

Another common shortcut is filtering candidates by years of experience.

Need a senior developer?

Set the requirement to five years.

Problem solved.

Except software development doesn't work like that.

One developer might spend five years maintaining similar WordPress websites.

Another might spend three years building APIs, debugging production systems, deploying applications, integrating payment providers, and making architectural decisions.

The second developer technically has less experience.

But which one would you want debugging your SaaS application at 2 AM?

Context matters more than the number.

Portfolios don't tell the entire story either

Portfolios are useful, but there's another problem.

You usually see the final result.

You don't see the starting point.

Was the developer responsible for the entire application?

Did they only implement the frontend?

Were they part of a team of 15 engineers?

Did they make the architectural decisions?

Did they inherit an existing codebase?

A beautiful final product doesn't necessarily tell you what the person actually contributed.

This is why good technical hiring requires questions about decisions, not just outcomes.

Instead of:

"Did you build this?"

Ask:

"What was the hardest technical problem you encountered while building this, and how did you solve it?"

The second question reveals much more.

Communication is a technical skill

This is especially important when working remotely.

A developer can be excellent technically and still be extremely difficult to work with.

Imagine receiving this update:

"Backend almost done."

What does that mean?

Compare it with:

"Authentication and the user API are complete. I'm currently working on Stripe webhooks. I found an issue with failed-payment handling, so I expect to finish that tomorrow."

Both developers may have written exactly the same amount of code.

But one gives the client significantly more visibility.

Good communication reduces uncertainty.

And reducing uncertainty is incredibly valuable when someone is working remotely on your product.

The best developer isn't always the right developer

This is probably the most overlooked part of hiring.

Suppose you're building a simple MVP.

You probably don't need someone designing an architecture capable of handling 50 million users.

You need someone who understands that:

shipping a good product today can be more valuable than designing the perfect system for three years from now.

The opposite is also true.

If you're processing thousands of transactions, hiring someone whose experience consists entirely of small landing pages probably isn't a good idea.

Hiring should be about matching the complexity of the problem with the experience of the person.

Search is becoming the interesting problem

This is something I've been thinking about while working on NexoRush.

Traditional freelance search is largely based on categories, keywords, ratings, and filters.

But a buyer doesn't really want to search for:

React + Node.js + PostgreSQL

They want to say:

"I have a SaaS application with a slow dashboard and I need someone to figure out what's causing it."

The interesting problem is translating that request into the skills and experience required to solve it.

That starts looking less like keyword search and more like a recommendation problem.

Maybe we have enough filters

Freelance platforms have spent years adding filters.

Technology.

Location.

Hourly rate.

Experience.

Rating.

Availability.

Language.

All of these are useful.

But adding another filter probably won't fundamentally improve hiring.

The bigger opportunity may be understanding the problem first and finding people based on that understanding.

In other words:

Don't start with the developer. Start with the problem.

That's something I'm increasingly convinced will shape how online hiring evolves.

What do you think?

Would you rather search through developer profiles yourself, or describe your problem and let a system recommend the most relevant people?