
Thoughts on building a boring startup
Some personal reflections after reading 'The boring way to build a startup' by Hricha Shandily from Plausible Analytics.
May 12, 2026 · 9 min read
I recently read The boring way to build a startup by Hricha Shandily, a content creator at Plausible Analytics. This isn't a "10 steps to startup success" piece or a story about raising millions. Instead, it's about building a company in a pretty ordinary, slow, even boring way.
But that very "boringness" is what impressed me.

Plausible isn't an unfamiliar name to many web developers. It's a lightweight, privacy-friendly, open-source analytics tool often seen as an alternative to Google Analytics. What's interesting is that the Plausible team didn't follow the typical startup playbook: raise money, burn cash, grow fast, figure it out later. They chose to sustain the company with real revenue from real customers.
After reading, I found a lot worth thinking about — especially for developers or anyone working on side projects.
Boring is sometimes an advantage
In the startup world, people tend to like things that sound big. The product must be disruptive, the market must be massive, growth must follow a hockey stick curve, and the story must be compelling enough to pitch investors.
But not every product needs that.
Some products just need to solve a clear problem, do it slightly better than existing options, and be trustworthy enough for people to pay monthly. It doesn't need to be sexy. Doesn't need to be trendy. Doesn't need AI shoved into every corner. But it needs to be stable, easy to understand, and genuinely valuable.
Plausible is a pretty clear example. Analytics is an old space. Not new. Not glamorous. But the need is always there. Every website needs to know where traffic comes from, which posts get read, which campaigns are working. If there's a lighter, more privacy-respecting, easier-to-use alternative to Google Analytics, there's still a market.
What I like here is the practicality. Sometimes a "boring business" is actually good because the problem has already been proven real. Users are already accustomed to paying for this type of product. You don't need to educate the market from scratch.

A boring business doesn't mean an unattractive business. Sometimes it just means the business is solving a very real problem.
For developers, this is a pretty valuable perspective. I think many of us when building side projects want to make something truly novel. But too novel is sometimes hard to sell. Meanwhile, a small tool that saves time, reduces costs, or makes a familiar workflow slightly better has a better chance of surviving long-term.
Self-funded keeps you clear-headed
Another point I really liked in the article is how Plausible chose to be self-funded. No fundraising, no depending on investors, growing based on customer revenue.
Sounds slow. And it is slow.
But in return, the team has the right to decide their own direction. No chasing growth metrics to make a dashboard look good. No expanding the team too fast just because they raised a new round. No compromising the product to serve an exit narrative.
I'm not saying fundraising is bad. Many business models need large capital, speed, networks, and investor support. But not every startup needs to go that route.
For small products — especially SaaS for developers, indie hackers, or bootstrapped businesses — self-funding helps maintain focus. Paying customers are a very clear signal. If they keep paying, the product is still creating value. If churn is high, something needs fixing. Everything becomes much more real.
I think the hardest part of self-funding isn't technical. The hardest part is patience. Because you have to live with the real speed of the business, with no funding to cover up the problems underneath.
In Vietnam, I think this approach also fits many developers well. Many people can build products very well but don't necessarily want to run a large company. A micro SaaS, a dev tool, a template, a plugin, or a product serving a niche market could be a more suitable path.
Not everyone needs to build a unicorn. Sometimes a small but profitable product, low pressure, sustaining a small team, fits life much better.
Sustainable growth sounds slow but stays healthy
One thing I think Plausible does well is they don't try to grow at all costs. They chose organic growth — content, open-source community, trust, and a good product.
This path isn't fast. But it has a foundation.
When users find you because they genuinely need the product, because they read a useful article, or because they believe in the privacy-friendly value — that relationship is different from them coming through a short-term ad campaign. Slower but more durable.
I think this is also a good lesson for content and product work. If you only look short-term, it's very easy to get impatient. Article has no traffic yet — discouraged. Product launch has no users — want to quit. MRR growing slowly — feels like failure.
But many things need time to accumulate. SEO needs time. Trust needs time. Product needs time to be good enough. The feedback loop also needs time to become clearer.
Of course, slow doesn't mean lazy. Sustainable doesn't mean no growth. It just means you don't trade everything for a few nice numbers in the short term.
For me, this is very worth reflecting on. A good product isn't just one with many features. It's also one with a healthy operating model, a team that isn't burned out, customers who clearly understand what they're paying for, and a company that can survive for many years.
Connecting to developer side projects
Reading this article, I thought a lot about developer side projects. Most of us usually start with the technical side. Have an idea, open a repo, pick a stack, set up a database, write an API, deploy to a server. This part is very fun.
But business isn't just building.
A product that wants to survive needs many fairly boring things: writing docs, answering emails, fixing small bugs, handling billing, customer support, writing changelogs, optimizing onboarding, tracking churn, improving pricing. These things aren't as cool as writing a new framework, but they determine whether the product makes money or not.
This is where I find the Plausible article quite honest. Startups aren't always glamorous moments. Often it's a series of days doing repetitive things, optimizing bit by bit, and keeping promises to customers.
I find this similar to blogging. A single article might not make a big difference. But if you write consistently, maintain decent quality, choose topics you genuinely care about — after a while it becomes a small asset. Not too loud, but valuable.
Same with side projects. A small project that's well-maintained for 2-3 years can go much further than a project that launches with great fanfare then gets abandoned after a few weeks.
I'm also walking this path with Knowns
Speaking of "boring startup," I think I should share a bit. I'm currently building a tool called Knowns — together with the Knowns Dev team.
Knowns is a repository memory layer for humans and AI agents. Simply put, it's a place to manage tasks, docs, templates, specs, and workflow state right inside the repo, while helping AI agents have enough context to work effectively. When tools like Claude Code, Cursor, or other coding agents interact with a codebase, they need structured "memory" rather than re-reading everything from scratch each time. Knowns handles that part.

I'm not building Knowns in the raise-money-then-burn-fast style. Not setting targets like "must have X thousand users in 3 months." Instead, we're going slowly: solving real problems that developers actually face daily when working with AI, shipping small features, listening to feedback, then improving.
If you're curious about what Knowns is and how it works, you can learn more at the homepage. I'll write a more detailed post about Knowns soon.
This is why I resonate with the Plausible article. When you're building a product yourself, you clearly understand the pressure of choosing between "grow fast but high risk" and "go slow but with foundation." Every technical decision, every feature added, every line of docs written has a cost. And when there's no funding to cover mistakes, you're forced to be more clear-headed with each step.
I won't claim this approach guarantees success. But at least it helps me stay focused on what actually matters: does the product genuinely solve a problem, do users come back, and do I have enough patience to maintain it long-term.
Conclusion
Hricha's article made me feel lighter about how I view startups. Not every path needs to be loud. Not every product needs fundraising. And not every growth needs to explode to be worth being proud of.
The boring way to build a startup might not suit everyone. It requires patience, discipline, and the ability to accept slow speed. But for those who want to build a sustainable, profitable product with real customers and less external pressure — this is a very valuable reminder.
I think sometimes we should look at our current projects through this lens. Instead of asking "how do I make it viral," maybe the better question is "does it solve a real problem, and can I maintain it long enough."
If you're building a small startup, indie product, or side project, this article is very worth reading and reflecting on. Not too long, but quite honest.
See yah.
References
- Original article: The boring way to build a startup - Hricha Shandily, Plausible Analytics
- Plausible signups chart referenced from the original blog post
- Plausible Analytics homepage: plausible.io