Editorial Policy
How we create, review, and govern technical architecture content. No fabricated case studies, no ghostwriters, and explicit transparency in our engineering documentation.
At AI Dev Planner, our content serves as an extension of our technical capability. We bypass generic marketing fluff in favor of rigorous, mathematically sound engineering blueprints. This policy outlines our standard operating procedure for content governance.
1. Authorship & Subject Matter Expertise
All technical architecture guides, case studies, and engineering blog posts are exclusively written by Obaid Tariq, Founder and Lead Engineer at AI Dev Planner.
We do not employ freelance copywriters, ghostwriters, or non-technical marketing staff to produce our technical content. Every code snippet, structural recommendation, and scaling assumption is authored by the engineer who designs our client systems. You can verify the author's technical background and operational stack on our Founder Profile.
2. Research & Source Selection
When documenting technology selections (e.g., Next.js vs Vite, or PostgreSQL indexing limits), our primary source of truth is official vendor documentation, direct GitHub repository metrics, and localized benchmarks we have run internally.
We prioritize primary sources (RFCs, official framework documentation, authenticated cloud provider SLAs) over secondary interpretations. If we cite third-party benchmark data, we explicitly link to the exact test environment or GitHub commit guaranteeing researchers can reproduce the results.
3. Technical Review & Factual Verification
Because our content is authored by our Lead Engineer, the technical review process is integrated natively into the drafting phase. We do not engage separate editorial layers to "check" technical facts; rather, code examples and architectural claims are cross-referenced directly against active development environments.
- Code Snippets: Validated against current stable releases of the referenced frameworks (e.g., Next.js App Router).
- Quantitative Metrics: If we state a performance gain or cost reduction, it is either derived from our own Proven Experience case studies or explicitly cited to an external primary source.
4. AI-Assisted Content Handling
We are an AI development consultancy, and we actively use AI tools in our internal workflows. However, we maintain strict boundaries on how AI intersects with published content:
- Drafting & Architecture: The structural thesis, technical arguments, constraints mapping, and final code decisions are 100% human-authored.
- Formatting & Proofreading: We utilize Large Language Models (LLMs) to catch typographical errors, standardize Markdown formatting, and suggest readability flow improvements.
- Zero Hallucinated Metrics: We explicitly forbid the use of AI to generate statistics, market trends, or client outcomes.
5. Iteration, Updates & Corrections
Technology moves fast. Structural recommendations holding true for Next.js 13 may be obsolete in Next.js 15.
Handling Outdated Information: We conduct periodic reviews of high-traffic technical guides. Articles that reference deprecated APIs or obsolete architecture patterns will either be updated with a new "Last Modified" timestamp or explicitly marked with a disclaimer indicating the versioning constraints applicable at the time of writing.
Corrections Policy: If a factual error, broken code implementation, or invalid metric is identified after publication, we will correct the source file natively. We do not issue formal press releases for minor typographical patches, but critical structural logic errors will be appended with an explicit "Update" note at the footer of the article explaining the correction.
6. Commercial Disclosures
Transparency in our recommendations is paramount.
- No Affiliate Links: We do not monetize our content via referral tracking links. If we recommend Vercel, Supabase, or Stripe, it is because we deploy them in our client environments, not because we receive a commission.
- First-Party Work: When we showcase technology configurations resulting from our paid consultancy operations, we explicitly label these as "Proven Experience" case studies subject to client NDAs.
7. Reporting Factual Inaccuracies
If you discover a hallucinated statistic, a broken code example, or a materially inaccurate architectural claim within our documentation, we want to fix it.
Please report any factual issues directly to us at support@aidevplanner.com. Include the URL of the article and a brief description of the technical discrepancy. Our Lead Engineer evaluates all reports directly.