Editorial Policy
How I choose topics, how I write reviews, and what I will and will not claim.
How I choose topics
Topics come from two places: questions I have personally dealt with while building sites, and questions that keep appearing in communities I read. I do not write a topic just because it has search volume. If I cannot add real context from experience or careful research, I do not write it.
The site covers the journey from WordPress on shared hosting, through VPS, into modern static stack. Every article lives somewhere on that path. Topics that do not serve a reader at one of those stages are probably not here.
How I separate hands-on experience from research
This is the most important distinction on this site. Every review, comparison, and recommendation carries an explicit experience level. There are four tiers:
I have used this tool in a real project. Configured it, broken it, fixed it, shipped something with it. When I write "I've seen this in production," this is what I mean.
I have used this tool, but my experience is limited, mixed, or dated. I will share what I observed, but I will not make strong recommendations based on that alone.
Tried in a demo, sandbox, or short experiment. Not in a real production project. I can describe what the tool does. I cannot speak to how it behaves under real conditions.
I have not used this tool at all. Evaluated through official documentation, feature pages, and community discussions. I can compare it on paper. I will not write "I've found" or "in my experience" about it.
The full list of tools with confidence levels is on the Uses page.
How I write reviews
A review covers: what the tool is for, who it is designed for, what I actually did with it, what worked, what did not, pricing with honest notes about renewal rates or hidden costs, and a recommendation with a stated context. A recommendation without context is not useful.
Reviews label their experience tier prominently. A research-based review says so at the top. I will not write a section called "My Experience" for a tool I have not used. That section will be labeled "Research Note" instead and will say explicitly what the information is based on.
I do not publish reviews to fill a content calendar. If I do not have enough real information to say something useful, the review waits.
How I write comparisons
Comparisons have a clear winner, but the winner is always qualified by context. "Platform A is better" is not a conclusion. "Platform A is better when you control the content and performance is the priority; Platform B is better when clients need to edit without calling you" is a conclusion.
Two rules that I consider non-negotiable in every comparison:
- WordPress gets its strongest fair case. It is a mature platform with the most plugin ecosystem depth, the most WooCommerce maturity, and the most practical editorial dashboard available for non-technical users. I will not frame it as a legacy tool or beginner-only option. Anyone who tells you WordPress is dead is probably trying to sell you the alternative.
- Astro's real limitations are stated honestly. No built-in admin dashboard. No WooCommerce. No user accounts without external services. Not suitable for clients who need to edit content themselves. I use Astro in production. I am not trying to oversell it.
How I use affiliate links
Affiliate links are present on this site. The full disclosure is on the Affiliate Disclosure page. Commission does not determine recommendations. If a product is not the right fit for your situation, I say so even if I have a link for it.
Affiliate links go through /go/[slug] redirect URLs so they are
always identifiable. Recommendations include context: who they are for and what
stage of the reader journey they serve.
Research-only products will not receive strong affiliate endorsement. I can describe them, compare them on paper, and link to them. I will not write a first-person recommendation for a tool I have not used.
Corrections policy
Pricing changes. Features are added and removed. Tools get acquired or shut down. If something I have written is factually wrong or outdated, I want to know. Contact me at contact@doancongtuan.com with a correction and a source. I will update the article and note the change.
I do not quietly edit articles to remove outdated claims. When a significant fact changes, the article will note when it was updated and what changed.
What I will not claim
- I will not write "I've used this" about a tool I have only researched.
- I will not attribute performance problems to a single cause unless I can demonstrate the connection. Tools and configurations interact.
- I will not frame a tool as universally bad based on my specific workflow. Not my workflow does not mean bad software.
- I will not claim to be an Astro expert. I use it in real projects and am still learning by building.
- I will not guarantee income from affiliate strategies or site-building approaches.
Why some recommendations are cautious
If I am not confident enough in my experience with a tool to make a strong call, I will say the recommendation is cautious or based on research only. A qualified opinion beats a confident one I cannot back up. Product data can fill a page. It cannot replace judgment built from actually using the thing.