DEV Community: Nikita Sivtsov

Your App Is "Up." Your Users Still Think It's Broken

Nikita Sivtsov — Mon, 03 Aug 2026 14:37:19 +0000

A support ticket comes in: "Checkout feels slow on Tuesdays." No error, no stack trace, no screenshot. You check the status page. Everything's green.

That gap between "the dashboard says fine" and "a paying customer says otherwise" is where most performance problems actually live. Here's how to close it without waiting for an engineer to have free time.

Up and fast are not the same promise

A server is "up" when it answers a request. It's "fast" when it answers before the person waiting notices the delay. A status page only checks the first one.

Picture that Tuesday checkout: request goes out, four seconds pass, confirmation appears. No error fired. Nothing crashed. The server did its job. The customer still thinks your app broke, because a four-second spinner during payment feels like death.

And the cost of that four seconds is real. Cart abandonment climbs sharply once load time crosses a few seconds, and even a tenth-of-a-second improvement can move conversion numbers. None of that shows up as a red light on a dashboard. It shows up as silence, as people quietly leaving.

A green status check tells you the patient is alive. It says nothing about whether they're in pain.

Averages hide the exact people you're looking for

This is the one lesson worth remembering above everything else in this post: averages lie, percentiles don't.

Say you've got ten checkout requests. Nine finish in under 100ms. One takes two full seconds. Average it out and you get a perfectly respectable-looking number, something like 257ms. That number describes literally none of the actual requests. It's worse than 90% of them and way better than the one that mattered.

This is why percentiles exist. p95 means 1 in 20 users waited longer than that number, it's your early warning sign. p99 means 1 in 100 users waited longer, and that's usually where churn actually lives. The average, meanwhile, is just a number that describes almost nobody.

Next time someone shows you a "response time looks fine" chart, ask for p95 and p99 instead. If the answer is "we only track the average," that's your first red flag right there.

Throughput and error rate won't save you either

Error rate tells you what percentage of requests failed outright. Worth watching, but your Tuesday problem never threw an error. It just took forever to succeed. A clean error rate can sit right next to a customer rage-quitting your checkout.

Throughput (requests over time) is more useful as a pattern-matcher. Steady traffic plus a climbing p99 is the fingerprint of a bottleneck hiding inside an app that technically works. If throughput is flat and response time is climbing, something changed on your end, not because more people showed up.

Is it your app or the network

Before you send an engineer chasing a phantom bug, rule this out: a phone on bad wifi will make your backend look slow even when it answered instantly. That's network latency, not application latency, and it's a completely different fix.

A quick sanity check: if even a trivial database round-trip consistently takes 100ms or more from your own app server, the problem probably isn't your query. It's the network between your app and the database.

Do this: separate "this user's connection is bad" from "our app is slow" before looping anyone in.
Don't do this: assume every slow-page report is a code problem.

*Tracing turns "checkout is slow" into "this step is slow"
*
A high p99 tells you pain exists somewhere. It doesn't tell you where. For that you need distributed tracing: give a single request a unique ID and record how long each hop takes as it moves from your app, to a payment API, to the database, and back.

Instead of a wall of graphs saying "checkout is slow," you get a timeline of one specific slow checkout, broken into steps, with actual seconds attached to each one. That's the difference between guessing and pointing.

It's almost always the database

Trace enough slow requests and they converge on the same ending, over and over: a database query nobody optimized.
Three usual suspects:

N+1 queries — fetch 10 orders, then fire 10 more queries to get the customer for each one. Common in ORMs with lazy loading turned on by default.
Missing indexes — without one, the database scans every row. Fine on a small table, brutal on a big one.
Queries that don't scale — a query that runs in 50ms on your dev machine with 1,000 rows can take 15+ seconds in production with 10 million rows. This is exactly why the problem only shows up "on Tuesdays," when traffic peaks and the query finally buckles under load.

That third one is your whole Tuesday mystery, solved.

Two terms worth knowing before your next standup:

Slow query log: the database's own record of every query that ran past a threshold you set. Just ask what's in it.
Eager loading: the standard fix for N+1, fetching related data in one query instead of a loop.

The actual sentence to bring to your engineers: "Under Tuesday load, p99 on checkout spikes and the trace points at the database. Can we check the slow query log for an N+1 or a missing index?" That's a hypothesis they can act on in an hour, not a vague complaint.

Catching it before the support ticket

Once you know where to look, you can stop waiting for customers to tell you:

Real user monitoring ties slow load times to actual sessions, devices, and networks, so you're not guessing whether it was your app or someone's hotel wifi.
Synthetic monitoring runs scripted checkouts on a schedule, catching a slowdown as it builds instead of after it's already cost you carts.
Threshold alerts mean you hear about a rising p99 from a rule, not from an angry email.

The checklist

Take the vague complaint seriously and pin it to a specific flow.
Check p95 and p99 on that flow. Never the average.
Trace one slow request end to end to find which hop ate the time.
Suspect the database first. Check the slow query log for N+1s or missing indexes.

And the tell that a team is running monitoring without ever finding anything: they only report averages, they only watch up/down status, they hear about slowness from customers instead of alerts, and they can't trace a single request start to finish.

If your team is doing two or more of those, the monitoring isn't broken. It's just not being asked the right questions.

This is the condensed version. The full writeup digs deeper into Apdex scoring, SLA/SLO targets built on p99 instead of averages, and how fragmented tooling quietly adds hours to incident resolution. Worth a read if you want the complete picture: How to Find Application Performance Monitoring Bottlenecks

MVP vs MLP: How to Pick the Right Launch Strategy

Nikita Sivtsov — Tue, 16 Jun 2026 14:27:08 +0000

Every founder faces the same question before shipping: how much should we build before letting anyone in?

Two frameworks try to answer it. The Minimum Viable Product and the Minimum Lovable Product. They look similar on the surface - both are about shipping small - but they point at completely different problems. Picking the wrong one for your situation is one of the more expensive mistakes you can make early on.

Where these ideas came from

The term MVP was coined in 2001 by Frank Robinson, CEO of SyncDev, who described it as the product that "maximizes return on risk for both the vendor and the customer." Eric Ries then popularized it through the Lean Startup movement, and for a decade it became the default playbook: ship rough, learn fast, iterate.

But somewhere along the way founders started using "MVP" as cover for shipping broken things. Users got tired of being beta testers.

That reaction is where MLP came in. Brian de Haaff of Aha! introduced the term in 2013. His argument was simple: a product people tolerate is not the same as a product they reach for.

What MVP actually means

An MVP is a stripped-down version of a product built to test one hypothesis with real users. Not "let's ship something and see." One specific hypothesis.

The clearest example is Drew Houston with Dropbox in 2008. Instead of building cloud sync infrastructure, he recorded a four-minute demo video showing how the product would work. The waitlist jumped from a few thousand to 75,000 overnight. No working product. Just a demand test.

Airbnb was even rougher. Chesky and Gebbia rented out three air mattresses for $80 each during a design conference in San Francisco. A site, some mattresses, breakfast included. They were not building a hospitality platform - they were checking whether strangers would pay to sleep on a stranger's floor.

"Viable" means the smallest thing that produces a real signal. Signal says yes, you build. Signal says no, you pivot before the costs pile up.

What MLP brings to the table

An MLP is a small first version that people genuinely enjoy using. Not "works fine" - actually enjoy.

De Haaff had a sharp way of putting it: you could eat cat food if you really had to, but you are unlikely to be clamoring for a second serving. Most MVPs are the cat food version of a product. They work. Nobody wants seconds.

An MLP cuts scope just as ruthlessly as an MVP. But the savings get reinvested into what ships. Copy is production-ready. Onboarding feels considered. Every surviving feature gets the full treatment instead of being left half-finished.

The actual comparison

	MVP	MLP
Goal	Test whether anyone wants this	Test whether users will return and tell friends
Mindset	Chase data	Chase delight
Features	Bare minimum to validate a use case	Fewer features, but each one polished
Design/UX	Rough UI, no brand work	Design is core to the build
Time to launch	Weeks	Months or more
Cost	Low	Higher upfront
Best for	Unproven demand, short runway	Validated demand, competitive market
Examples	Dropbox demo video, Airbnb mattresses	Superhuman, Linear

The underlying difference: MVP asks "will anyone use this?" MLP asks "will the people who try it come back and stay?"

When MVP makes sense

MVP is the right call when your biggest unknown is demand. If you are not sure anyone wants the thing, the fastest way to find out is to put a rough version in front of real people and watch what happens. Polish slows down the answer here.

MVP wins in these situations:

Untested markets where you cannot name a single competitor
B2B tools and internal pilots, where buyers tolerate rough edges if the workflow saves time
Short runway, where shipping in six weeks vs six months is the difference between learning and dying
Concierge or Wizard of Oz services, where the back end is humans doing the work manually

One warning attached: do not ship rough into a market where users already expect polish. A consumer photo app launching in 2025 against established players cannot get away with a half-finished onboarding. The bar has been set by someone else, and an MVP that ignores that reads as broken, not scrappy.

When MLP wins

MLP wins when demand is already validated. You know people want a better email client or a better issue tracker. The question is whether they will love yours enough to switch and stay.

Superhuman is the textbook case. Rahul Vohra spent a year on user interviews before writing much product code, then three more years building before public launch. He personally onboarded early users in two-hour sessions. When the product-market fit score sat at 22%, the team did not ship harder - they went back to survey data and doubled down on speed and keyboard shortcuts. Within a year the score hit 58%. Email already existed. The bet was that craft would pull the right users across.

Linear tells the same story from a different angle. By 2025 the company had 15,000 paying customers and a $1.25B valuation on almost no marketing spend, mostly through word of mouth from people who found the product unusually well-built. When management at some companies tried to consolidate onto incumbent tools, the teams using Linear revolted. That kind of loyalty comes from MLP discipline applied from day one.

How to actually choose

Before committing to either approach, four questions help:

What is the bigger risk - demand or retention? Demand risk points to MVP. Retention risk points to MLP.
Has a competitor already set a high quality bar? If yes, shipping rough will read as broken.
How much runway do you have? Under six months forces MVP whether you like it or not.
Can you name your earliest user and what they currently use? If no, go talk to people before picking either approach.

One more honest check: teams sometimes pick MLP because they are afraid of negative feedback on a rough product. And sometimes pick MVP because they do not want to invest in design. Both are bad reasons. Pick the approach that matches what you are actually testing.

If you want to go deeper on this - the full breakdown with more examples and a decision framework is here: MVP vs MLP: Which Launch Strategy Fits Your Product

MVP Architecture Mistakes That Will Ruin Your Life in 6 Months

Nikita Sivtsov — Wed, 27 May 2026 14:54:14 +0000

We've been building products for startups at Pollume for a while now, and there's a pattern that comes up so often it's almost funny. Team moves fast, ships something, gets traction, and then suddenly everything grinds to a halt. Adding a new feature takes two weeks. Fixing one bug breaks three other things. The codebase that felt totally fine at 100 users is quietly falling apart at 1000.
The worst part? Most of these situations were completely avoidable. They trace back to decisions made in the first few weeks of the project, when everyone was excited and moving fast and not really thinking about what happens later.
Here's what I keep seeing, and what actually helps.

Nobody talks about the monolith thing enough
There's this widespread belief in dev circles that microservices are the "correct" architecture and monoliths are just what you do before you know better. So teams reach for distributed architecture on day one, before they have a single paying user, before they even know if the product works.
What actually happens: you spend the first two months wiring services together instead of building product. Debugging becomes a nightmare because a request touches four different services. Deployment is a coordination exercise. And you're doing all of this complexity for a product that might pivot completely in three weeks anyway.
Shopify's Rails monolith handled 173 billion requests on Black Friday 2024. One codebase, massive scale. You do not need microservices on day one, and honestly probably not on day 300 either.
Start with a well-structured monolith where business logic lives in clear, isolated modules. You can extract services later when you actually have a reason to, not because it felt like the right thing to do in month one.

The database schema conversation nobody wants to have
I get it, schema design is boring. Everyone wants to start writing code. But the database is the thing that's hardest to change later, and getting it wrong is genuinely painful.
The mistake I see most often is picking a database based on familiarity and then just... winging the data model. Tables that made sense at first start doing weird things when they have a million rows and no proper indexing. Queries that took 10ms at launch take 4 seconds six months later.
Foursquare had a 17-hour outage in 2010 because their data became unbalanced as the platform grew. Not a code bug, not a server issue. Just a data model that wasn't designed for scale.
Spending an extra day mapping out your actual data relationships before writing code is one of the highest-leverage things you can do early on.

Writing code for problems you don't have yet
This one is a bit uncomfortable to talk about because it's so common. Teams build complex infrastructure for scale they haven't reached. They add caching layers, job queues, and elaborate abstractions to handle traffic spikes that don't exist yet, while the core product is completely unvalidated.
Startup Genome research found that premature scaling causes 74% of startup failures, and failed companies tend to write over three times more code than successful ones. Three times.
The version of this I see most often is teams building features nobody asked for because they seemed like obvious next steps. Meanwhile the one thing the product actually needs to do well is mediocre because the team's attention was spread across ten other things.
Define the one core action your product needs to do really well. Build only that. Measure whether people actually use it before adding anything else. It sounds obvious and it is genuinely hard to stick to.

Technical debt doesn't go away on its own, shockingly
Every team I've ever worked with has said some version of "we'll clean this up after the next release." And then the next release comes and there's a new urgent thing, and the shortcuts from three months ago are now load-bearing walls.
Shopify allocates about 10% of every sprint specifically to technical debt. Not as a special cleanup sprint, not as something that happens when things are quiet. Every sprint, 10%. That's how a 20-year-old Rails codebase still works at massive scale.
Even a small consistent allocation is better than a big cleanup that never happens, which is what "we'll deal with it later" always turns into.

The API stuff that seems fine until it isn't
Inconsistent endpoints, no versioning, internal database structure leaking into API responses — all of these feel like minor sins when you're building fast. They become a real problem when you have mobile clients on old versions, third-party integrations depending on specific response shapes, or a backend you want to refactor without breaking everything downstream.
A few things that cost almost nothing to do correctly from the start: consistent response formats, versioning (/api/v1/ from day one), and keeping what the API exposes separate from what's in the database. Boring stuff that saves weeks later.

I wrote a much more detailed version of all of this on the Pollume blog, including a full breakdown of how to structure your requirements before you write a single line of code: How to Build an MVP: Architecture Guide for 2026
If you've shipped an MVP and hit any of these walls, curious to hear what tripped you up the most. Drop it in the comments.