Shopify App Review — Operating Model

This document defines Blinto’s approved lightweight operating model for the Shopify App Review pilot. The Core Strategy + SOP 1–7 in source-sops/ remain the detailed knowledge base.

Objective

Build authoritative, evidence-based Shopify app reviews using Blinto’s technical/product expertise without requiring developers and designers to become professional writers.

Human Reviewer + AI Writer → Human Verification → SEO Check → Publish.

Roles

Human Reviewer / Named Author

One ClickUp assignee owns each review. Their normal Blinto role may be developer, designer, or another technical/product role. They do not need professional writing experience.

They own real-world app testing, screenshots/evidence, observations, product/UX/technical judgment, answers to AI questions, and final factual approval. The published byline remains the human reviewer because the experience, evaluation, judgment, and verification are theirs.

AI Writer

ChatGPT, Claude, or another approved AI assistant with repository context acts as researcher, interviewer, evidence organizer, editor, QA assistant, and primary prose writer.

The AI may write the entire article. It should proactively guide the human through the repository process, ask for missing manual evidence sequentially, conduct legitimate public research, organize evidence, create the brief/SEO direction, draft the complete review, edit it, and prepare it for repository preview.

AI may write 100% of the prose. AI may invent 0% of the experience or evidence.

It must never fabricate testing, product behavior, screenshots, pricing, merchant feedback, quotations, statistics, scores, citations, or technical verification.

SEO / Quality Check

Owner: Shemanto, or a calibrated SEO agent later.

This is the only routine human review handoff. Shemanto reviews the rendered Content Preview linked from ClickUp. If changes are requested, the task remains in SEO Check and the original reviewer works with their AI assistant to resolve them.

Publishing

Owner: Fazle or Shemanto.

After SEO Check passes, the task moves to Ready to Publish. Publication and final live QA then move it to Published.

Source of Truth

1. source-sops/ — detailed original strategy and SOP knowledge.
2. docs/ — approved execution model.
3. templates/ — working structures and task templates.
4. reviews/ — review content/evidence records and content source of truth.
5. GitHub — version history and collaboration layer.
6. ClickUp — assignment, due date, stage, blockers, and working links.
7. Review Hub — rendered private content preview and human-friendly process interface.

Production Workflow

Backlog → Research & Write → SEO Check → Ready to Publish → Published

Assigned is handled by the assignee field, not a status. Monitoring is handled as post-publication maintenance, not a production-board status.

Handoff Contract

The reviewer cannot move a task from Research & Write to SEO Check until:

• The complete AI-written review has been fact-checked by the human reviewer.
• The review is committed/pushed under reviews/.
• The deployed Review Hub renders the review.
• The exact https://reviews.blinto.co/reviews/.../ Content Preview URL is added to ClickUp.

This means Shemanto should never need to hunt through GitHub or inspect raw Markdown to review an article.

Review Hub Contract

The Astro site loads reviews/**/*.{md,mdx} as the reviews content collection and generates a route for every review at /reviews/[review-file-id]/. Therefore a correctly formatted review committed to the deployed branch is part of the Review Hub build automatically.

The AI/reviewer should use a stable, URL-safe review filename/ID and record the resulting preview URL in ClickUp after deployment.

Evidence & Testing Standard

Every review must state its actual evaluation level:

1. Full Hands-On Test
2. Partial Hands-On Test
3. Demo and Documentation Review
4. Research-Only Evaluation
5. Insufficient Evidence

Never present partial/documentation research as full hands-on testing. Keep developer claims, Blinto observations, and merchant feedback distinct. Verify/date pricing. Mark missing evidence rather than filling gaps by assumption.

Required ClickUp Entry Points

Every production task should contain:

• Shopify App — direct App Store listing.
• GitHub Repository — source of truth.
• Review Hub — process/preview interface.
• Content Preview — exact review page; mandatory before SEO Check.
• Published URL — once live publicly.

Editorial Independence

Founder relationships, partnerships, sponsorships, affiliate opportunities, discounts, free access, or potential Blinto business cannot control the review conclusion. Factual corrections can be considered and independently verified; external parties do not control pros/cons, rankings, verdicts, or publication decisions.

Validation Before Scale

Start with the five-review pilot and optimize for learning and publishing velocity. The broader SOP validation target remains 10 pieces: 3 category/bulk reviews, 5 single-app reviews, and 2 comparisons. Scale toward 100 only after the program demonstrates useful SEO/business outcomes and a repeatable production model.

Non-Negotiables

• One human reviewer/assignee per review.
• Human owns testing, evidence, judgment, and factual approval.
• AI is expected to produce the polished content and may write the full article.
• AI cannot invent evidence or experience.
• Reviewer must fact-check before handoff.
• Content Preview URL is mandatory before SEO Check.
• One routine final SEO/quality gate: Shemanto.
• Fazle or Shemanto publishes after that gate passes.
• No separate Technical Review, Revision, Final Approval, Assigned, or Monitoring production status.
• Testing level and limitations must be transparent.
• Keep the pilot simple; add gates only when observed problems justify them.

Shopify App Review — Execution Workflow

This is the approved practical workflow for the Shopify App Review operation.

The detailed requirements remain in source-sops/. The execution layer stays lightweight while preserving evidence, transparency, SEO quality, merchant usefulness, and internal learning.

Two Required Outputs

Every completed app review must create two distinct outputs:

1. External — Merchant Decision Output: help a Shopify merchant make a better app decision through independent, evidence-based, hands-on evaluation. The published article must visibly demonstrate Blinto’s testing through selected publication-safe evidence.
2. Internal — Founder Intelligence Output: help Blinto understand the app company, merchant pain, product/growth gaps, unanswered questions, and where Blinto could genuinely help the founder.

The public editorial conclusion must be independent of any sales opportunity. Lock the editorial verdict before founder intelligence is converted into CRM or outreach. A company becoming a prospect must never make its review more positive.

Core Authenticity Principle

Blinto does not ask readers to trust that we tested an app; the published review should show enough evidence for readers to see that we did.

Internal evidence proves the work to Blinto. Selected public evidence proves the work to the merchant.

Every Level 1 or Level 2 review must therefore combine:

• a realistic hands-on merchant scenario;
• explicit first-hand observations such as “In our test…”, “We built…”, “We found…”, or “This took us…”;
• normally 3–5 purposeful publication screenshots from the actual test;
• a short screen recording when motion materially proves an important workflow or finding;
• clear disclosure of what was and was not tested;
• evidence placed beside the finding it supports rather than in a detached gallery.

A screenshot is not valuable because it exists. It must help prove a merchant-relevant claim, workflow, result, limitation, or plan boundary.

Core Model

Research → merchant decision → human reviewer tests a realistic scenario → capture evidence → findings → AI researches/interviews/writes → embed selected evidence with findings → human fact-checks → quality score → editorial verdict locked → founder intelligence → preview → SEO Check → publish → CRM/outreach when appropriate.

The app is the subject of each single-app review. The merchant problem is the evaluation lens.

The human assignee is the named reviewer/author and owns the experience, evidence, judgment, and factual approval. The AI assistant produces the complete polished article from verified public research plus the reviewer’s supplied testing experience and evidence.

AI may write 100% of the prose. AI may invent 0% of the experience or evidence.

Public vs Internal Evidence

The public article and internal research file have different evidence responsibilities:

• Internal research page: complete testing record, raw evidence inventory, unused screenshots, sensitive/redacted material, scorecard, contradictions, limitations, Founder Intelligence, and other working notes.
• Published article: the strongest publication-safe evidence needed to substantiate the merchant decision and Blinto’s original findings.

Do not publish raw internal notes, Founder Intelligence, the internal quality scorecard, sensitive store/customer information, or every screenshot captured during testing.

Do not hide all evidence internally either. If a major Blinto finding is central to the published recommendation, the article should normally show the screenshot/recording that demonstrates it or describe the direct hands-on observation precisely when visual proof is not meaningful.

Internal UI Rule

The quality scorecard and Founder Intelligence are internal working data. They must appear on the private Research page for the app, not inside the public review article.

The Review Hub dashboard should show only the review’s final quality score and status as a compact summary so the team can quickly see which reviews are ready, need revision, or are below standard.

ClickUp Workflow

Backlog → Research & Write → SEO Check → Ready to Publish → Published

1. Backlog

An approved/proposed review task waits here until production starts. The task should contain the Shopify App Store link, GitHub repository link, Review Hub link, app/category/assignee, and any approval blocker.

2. Research & Write — Human Reviewer + AI Writer

When the assignee starts, move the task to Research & Write and open the repository with ChatGPT or Claude.

Step A — Define the merchant decision

Before testing becomes a feature walkthrough, establish:

1. What real merchant problem causes someone to consider this app?
2. What does the app promise to solve?
3. What is the most important buying/install question this review should answer?
4. What realistic scenario must we test to answer it?
5. What evidence would allow a merchant to see that Blinto genuinely tested the important parts of that scenario?

The question can evolve as hands-on evidence reveals a more important trade-off.

Examples:

• Judge.me: Can a Shopify merchant genuinely run product reviews for free, or will the limitations quickly require the paid plan?
• PageFly: Can a non-technical merchant build and launch a professional custom Shopify page without relying on a developer?

Step B — Test the merchant scenario and capture proof

Use the dedicated development/test store for normal reviews. Do not merely inspect screens. Complete the realistic workflow needed to evaluate the app’s core promise where practical.

Examples include test products, test customers/orders, review requests, submitted reviews, email flows, discounts, imports, automations, published pages, responsive behavior, theme interactions, and outputs.

Use real-world/live validation only when a conclusion genuinely depends on traffic, conversion, revenue, real customers, long-term operations, or another condition a development store cannot establish.

Never claim beyond the testing level. If a workflow was only inspected rather than completed, say so or avoid the claim.

During testing, collect publication evidence at the moment the finding occurs. For Level 1 and Level 2 reviews, the normal public set is 3–5 purposeful screenshots:

1. App homepage, dashboard, or clearest overview when it helps establish what was tested.
2. Core tested workflow or intermediate step that answers the merchant decision question.
3. Actual result/output produced by the test when materially different from the workflow screen.
4. Exact issue, limitation, friction, contradiction, or plan boundary discovered during testing.
5. Current in-app or official pricing screen when pricing materially affects the recommendation.

Three screenshots are enough when they prove the important findings. Five are appropriate when the merchant decision genuinely requires more evidence. Never add filler to hit a number.

For every selected screenshot, record what claim it proves. If it proves nothing important, it should not be in the article.

A short screen recording is recommended when motion or sequence materially strengthens authenticity — for example a page-building flow, onboarding sequence, automation, upsell configuration, publishing workflow, or reproducible issue. It is optional when screenshots communicate the evidence adequately. A recording supplements rather than replaces the core screenshot evidence.

Before publication, crop/redact sensitive customer, staff, store, credential, analytics, or commercially confidential information.

Human reviewer owns

• Real app access and hands-on testing.
• Running the realistic merchant scenario requested by the review plan.
• Capturing screenshots/evidence while testing rather than reconstructing evidence afterward.
• Explaining what each evidence item proves.
• Optional short screen recording when it materially strengthens evidence.
• Raw observations, opinions, UX/technical/product judgment, problems, strengths, limitations, and merchant-fit conclusions.
• Answering AI follow-up questions when experience cannot be learned from public sources.
• Final factual verification of the generated article and confirmation that published evidence accurately represents the test.

AI assistant owns

• Reading and following this repository, docs/, templates, and applicable source-sops/.
• Legitimate public research and source organization.
• Helping define the merchant problem and decision question.
• Designing/asking for the minimum realistic testing needed to answer that question.
• Asking the reviewer for missing testing, screenshots, recordings, observations, or decisions.
• Maintaining a claim → evidence relationship for major original findings.
• Separating developer claims, Blinto hands-on observations, and merchant feedback as distinct evidence classes.
• Converting technical findings into merchant/business implications without inventing outcomes.
• Writing the complete merchant-focused article in polished prose.
• Selecting the strongest publication-safe evidence and placing it beside the relevant finding.
• Editing, consistency checks, and pre-handoff QA.
• Creating/updating the review file in reviews/ and committing/pushing it when the connected environment supports GitHub writes.

AI must never fabricate testing, product behavior, pricing, merchant feedback, screenshots, recordings, scores, quotations, statistics, citations, technical verification, conversion impact, or revenue impact. Missing evidence must be requested, removed, qualified, or disclosed.

Step C — Write around the decision and show the evidence

The final review should normally follow this editorial logic:

Merchant problem → app promise → what we tested → what actually happened + evidence → important trade-offs + evidence → cost/value → who should use it → who should not → final recommendation.

Do not publish a heading called “Merchant Problem.” Establish it naturally in the introduction.

Every Level 1 or Level 2 article must include a visible What We Tested section. It should concisely state:

• test environment/store type where relevant;
• plan/tier tested;
• realistic scenario completed;
• important outputs/workflows actually verified;
• material limitations and things not tested.

This is not a lab report. Keep it useful to merchants and proportional to the buying decision.

Use first-hand language only for first-hand evidence. “We tested,” “we built,” “we observed,” and similar language must map to the research record. Developer claims and merchant reports must remain clearly attributed.

Technical findings are evidence. They should earn space because they change or support the merchant’s decision.

Place each selected screenshot at the point where it supports the claim/finding. The preferred pattern is immediately below the relevant section title or immediately before the paragraph that analyzes it. Do not create a detached screenshot gallery.

Alt text must describe what the image actually shows. The surrounding prose should explain why the evidence matters to the merchant, not merely repeat the image.

Screen recordings, when used, should sit beside the workflow/finding they demonstrate and include a concise description of what the reader should notice.

Alternatives may be mentioned briefly when useful, but a single-app review should not be forced into a comparison article.

Step D — Blinto Review Quality Score

Before the editorial verdict is locked, score the finished review out of 100:

Interpretation:

• 90–100 — Blinto Standard: strong enough to represent the review program.
• 80–89 — Publishable: minor improvements may still be useful.
• 70–79 — Revision required: another editorial/testing pass is needed.
• Below 70 — Not publishable: the review does not yet meet the standard.

Writing quality intentionally carries fewer points than authenticity and merchant usefulness. A polished generic article must not outscore genuine hands-on evaluation.

Authenticity and evidence scoring rule

The score must evaluate what the merchant can verify in the article, not only what Blinto holds privately.

• Hands-on authenticity (20): reward meaningful scenario completion, specific first-hand observations, transparent limitations, and a clear connection between testing and verdict.
• Evidence/screenshots (10): reward publication-safe screenshots/recordings actually rendered in the article and tied to important claims. Private evidence that never reaches the article can support internal verification but cannot earn full public-evidence points.

As a default, a Level 1/2 review with no real hands-on screenshots in the public article cannot receive more than 3/10 for Evidence/screenshots, regardless of how many private screenshots exist. Exceptions require a documented reason that visual evidence would be meaningless or unsafe.

Research page scorecard UI

The private research page should render all eight scoring categories with category name, points earned / maximum points, evaluator note, total score out of 100, and derived status.

The underlying research Markdown stores the scorecard as structured frontmatter so the Research page and dashboard use the same source of truth.

Dashboard score summary

The Review Hub dashboard table should show a Quality Score column for every review that has a scorecard. Display the total plus derived status. Reviews that have not yet been scored should show Not scored rather than assuming zero.

Do not expose the internal Blinto quality score inside the public article unless a future editorial policy explicitly chooses to publish it.

Step E — Lock the editorial verdict

After fact-checking and scoring, lock the merchant-facing conclusion before doing commercial qualification. The verdict should clearly answer install / consider / skip — and for whom, using language appropriate to the evidence rather than forcing those exact labels into every article.

Do not change the verdict, criticism, score, or factual framing because the developer is a current client, prospective client, partner, sponsor, or outreach target.

Step F — Create the Founder Intelligence Output

The matching internal research/ file must include a concise Founder Intelligence section after the editorial verdict is locked. This section is internal and must not distort the published review.

Capture:

1. What the app does exceptionally well — useful strengths worth recognizing in founder conversations.
2. Merchant friction discovered — onboarding, UX, pricing, documentation, positioning, support, technical or workflow friction evidenced during research/testing.
3. Growth opportunities — SEO, content, positioning, App Store optimization, conversion, onboarding, retention, distribution, or other evidence-backed opportunities.
4. Product opportunities — recurring merchant requests, missing capabilities, workflow problems, integration gaps, or other product observations.
5. Questions for the founder — material things independent research/testing could not establish.
6. Blinto fit — one of: No obvious opportunity, Growth opportunity, UX opportunity, Development opportunity, or Multiple opportunities, followed by a short evidence-based reason.

Founder intelligence is not permission to manufacture a sales angle. If no meaningful opportunity exists, record that clearly.

3. Preview, Public Evidence Check & Human Fact-check

Every review file under reviews/ is automatically included in the Astro Review Hub collection. After the review is committed/pushed and deployment completes, its private preview is available at:

https://reviews.blinto.co/reviews/[review-file-id]/

Before handoff, the human reviewer must read the generated review and confirm it accurately represents what they tested and found.

The reviewer must also visually inspect the preview and confirm:

• selected hands-on screenshots actually render;
• each image/recording is attached to the correct finding;
• evidence is publication-safe and contains no sensitive data;
• the article’s first-hand claims match the internal research evidence;
• material testing limitations remain visible;
• no internal scorecard, Founder Intelligence, or private working notes leaked into the article.

The reviewer/AI must then add the exact Content Preview URL to the ClickUp task.

The matching internal evidence file under research/ renders privately at https://reviews.blinto.co/research/[research-file-id]/ for fact-checking context and founder intelligence. It is never the Content Preview URL.

A task is not ready for SEO Check until all seven are true:

1. Review content is committed/pushed to GitHub.
2. Rendered content preview is available on reviews.blinto.co.
3. Exact Content Preview URL is recorded in ClickUp.
4. Blinto Review Quality Score has been completed and is 80+.
5. Editorial verdict is locked and Founder Intelligence is recorded internally.
6. For Level 1/2 reviews, the selected hands-on publication evidence is actually embedded and rendering in the preview (normally 3–5 screenshots, plus recording when useful).
7. Human reviewer confirms the public evidence accurately represents the test and materially supports the merchant-facing findings.

4. SEO Check — Shemanto

The reviewer moves the task to SEO Check only after the preview handoff requirements are satisfied.

Shemanto checks search intent/topic alignment, title/H1 and headings, topical coverage, metadata direction, internal links, comparison/cannibalization opportunities, readability, merchant usefulness, disclosures, unsupported claims/evidence gaps, and whether evidence supports the article’s major original findings.

SEO optimization must preserve the review’s merchant-decision thesis rather than turning the article back into a generic feature/pricing/pros-cons template.

If corrections are needed, keep the task in SEO Check. The same human reviewer works with their AI assistant to resolve feedback and update the preview. SEO edits may improve presentation and discover factual gaps, but they must not quietly change a locked editorial verdict without returning the review to the reviewer for evidence-based reconsideration.

When the check passes, Shemanto moves the task to Ready to Publish.

5. Ready to Publish

The article has passed the quality and public-authenticity gates. Fazle or Shemanto completes final publishing/QA without adding another routine approval stage.

6. Published

Once the public article is live and verified, Fazle or Shemanto adds the published URL to ClickUp and moves the task to Published.

Only after the independent editorial verdict is locked may relevant Founder Intelligence be transferred into the sales CRM and used for respectful, evidence-based founder outreach.

Performance tracking, refreshes, pricing/product changes, and maintenance continue according to SOP 7, outside the production-board statuses.

Existing Published Review Upgrade Rule

Reviews published before this public-evidence standard should be progressively upgraded rather than treated as permanently complete.

For each existing review:

1. Re-open the internal research/evidence record.
2. Identify the 3–5 strongest merchant-relevant evidence items already captured.
3. If evidence for a major claim is missing, re-test that workflow instead of fabricating retrospective proof.
4. Export/crop/redact selected evidence into public/images/reviews/[app-slug]/ (or the approved media location).
5. Embed evidence beside the relevant findings in the article.
6. Add/strengthen the visible What We Tested disclosure.
7. Re-run the Blinto quality score using the public-evidence scoring rule.
8. Re-publish only after the upgraded article passes preview/fact-check.

Prioritize published reviews with strong internal evidence but weak public evidence first, because they can usually be upgraded without repeating the entire review.

Required ClickUp Links

Every review task should expose:

• Shopify App — direct Shopify App Store listing.
• GitHub Repository — teamblinto/blinto-shopify-app-reviews.
• Review Hub — https://reviews.blinto.co.
• Content Preview — exact rendered review URL; mandatory before SEO Check.
• Published URL — added after public publication.

Status Ownership

• Task created/approved → Backlog.
• Human reviewer starts → Research & Write.
• Human reviewer fact-checks + scores 80+ + locks verdict + records Founder Intelligence + public evidence renders + preview URL is in ClickUp → SEO Check.
• Shemanto passes SEO/quality/authenticity gate → Ready to Publish.
• Fazle/Shemanto publishes and verifies → Published.

Planning/topic-validation work belongs in Shopify GTM Execution, not the review-production board.

CEO Process Improvement Rule

When CEO/final review discovers a recurring weakness, do not fix only that article. Record the observation and decide whether the workflow, template, evidence requirement, or SOP should change so future reviewers automatically follow the improved standard.

Use this simple improvement logic:

Observation → article issue → reusable process change.

This is how the review system should improve as Blinto completes more apps.