Phase 1 — Full-Site Redesign Plan v1.1 Planning status and evidence limitations This plan is based on the current repository source, route inventory, global templates, styles, existing workflow demonstrations, and Supabase inquiry implementation.
Two required sources were unavailable:
Approved professional fact sheet: The specified macOS path does not exist in this Linux environment: /Users/mahadevupadhyayula/.codex/attachments/81f066db-e092-479c-94f4-26efbfbeb66a/pasted-text.txt
Live-site rendering: Direct access to https://mahadevupadhyayula.com/ returned 401 Unauthorized through the available browser tool.
As a result:
Repository content is treated as the current-state source, not as verified professional evidence.
No PayPal, Donato Technologies, founder, ownership, experience-duration, numerical result, or customer-outcome claim is approved for new public copy by this plan.
Production parity must be checked before implementation.
The missing fact sheet must be supplied at an accessible repository or Linux filesystem path before credibility copy is implemented.
No repository or external changes were made.
- Executive recommendation Final positioning Position the practice as:
Human-approved AI workflow products for B2B teams.
Supporting promise:
Turn scattered revenue, customer, product, and operational inputs into structured, validated, reviewable outputs—before they shape a business decision or downstream work.
The site should consistently describe the same control system:
Scattered inputs → AI extraction and reconciliation → deterministic validation → source-linked review → human approval → controlled output
This is the central differentiator—not generic automation, chatbots, autonomous agents, or a broad AI-transformation service.
Target organizations Prioritize:
Mid-market and enterprise B2B SaaS companies.
B2B software companies.
Technology-enabled services firms.
Teams with recurring, evidence-heavy workflows and an accountable reviewer.
Primary buyers Revenue Operations and Sales Operations leaders.
Implementation, Professional Services, and Onboarding leaders.
Support, Quality, and Engineering Operations leaders.
Product, Product Operations, Discovery, and Customer Insights leaders.
Executive sponsors evaluating bounded AI workflow investments.
Four pillars Revenue Intelligence
Implementation Intelligence
Quality Intelligence
Product Evidence
Revenue Intelligence must become a peer of the other three pillars. The current homepage presents only Implementation, Quality, and Product Evidence, despite already containing relevant CRM, pre-CRM, quote, and MAWI evidence elsewhere.
Offer ladder Workflow Audit — fixed-fee, no public price.
AI Workflow Prototype Sprint — scoped project price, no public price.
AI Workflow Advisory — monthly retainer, no public price.
The current site instead leads almost exclusively with the Prototype Sprint and still presents “Fixed-Scope Workflow Build” and “Optional Optimization.” Those must be replaced by the approved offer ladder.
Conversion principle The site should guide buyers through:
Recognize a workflow failure → inspect relevant evidence → understand the control model → select the appropriate engagement → submit a non-confidential inquiry
Recommended CTA hierarchy:
Global primary: Start a Workflow Audit
Global secondary: Explore Workflow Evidence
Form submit: Send Workflow Inquiry
Contextual evidence action: Open Guided Demo, Inspect Workflow Evidence, or View Evidence Pack
The current AGENTS.md CTA wording is older than the user-approved strategy. During implementation, the user’s newer direct instructions take precedence.
- Current-state audit Primary routes Current route Current purpose Problems and stale remnants Recommendation SEO and claim controls / Homepage led by Implementation Intelligence Over-indexes on one pillar; omits Revenue Intelligence from the main framework; uses obsolete three-step engagement model; repeats generic portfolio sections; exposes unverified “Ex-PayPal,” “5+ years,” “0→1,” and founder claims Rewrite around the four-pillar practice, control model, evidence, offers, measurement, and Audit CTA Replace unverified trust row; broaden title and description only after final positioning approval /services/ Prototype Sprint sales page Presents only one primary offer; calls other pillars “secondary”; exposes four-to-six-week duration without current confirmation; has no Audit or Advisory comparison Convert to three-offer decision page Replace single-Service schema with accurately scoped offer/service markup /case-studies/ Mixed proof and portfolio index “Case Studies” can imply client work; mixes representative workflows, employment experience, founder claims, personal products, working demos, and concepts Migrate to /workflow-evidence/ with explicit evidence taxonomy Every card must state evidence type, data status, deployment status, demonstrated behavior, and non-claims /about/ Personal credibility and working philosophy Metadata says “AI Workflow Automation Consultant”; emphasizes older CRM/research/quote positioning; repeats service content; contains facts needing verification Rewrite as a concise, warm, evidence-controlled About page Publish only fact-sheet-verified employment, scope, dates, and metrics /work-with-me/ Prototype Sprint inquiry page Only supports Sprint framing; mixes offer and workflow categories; includes public budget bands; uses obsolete CTA and route name Migrate to /start-a-workflow-audit/ while supporting all three offers Preserve old URL via redirect; separate engagement and pillar fields /blogs/ Automatic blog index Generic “AI Workflow Automation” metadata; broad topic mix; public editorial backlog; no pillar-based organization Migrate to /insights/ and curate the feed Preserve article URLs; update index title, description, canonical, and topic structure /product-deep-dive/ Generic project-deep-dive index Weak buyer relevance; supports personal product material rather than the consulting practice Remove from primary navigation; preserve or redirect after traffic review Consider noindex only after analytics and inbound-link review The homepage’s metadata is already closer to the desired positioning than some other pages, but its visible hero narrows the practice to implementation workflows. The About and Insights metadata still use generic automation language.
Workflow-proof and case-study routes Current route Status Recommendation Claim-control concern /case-studies/implementation-intelligence/ Representative workflow proof with guided demo Elevate to /workflow-evidence/implementation-intelligence/; preserve old URL through redirect Keep synthetic/representative disclosure; replace modeled ROI language with buyer-supplied pilot variables /workflow-demos/sales-to-implementation-handoff-validator/ Guided synthetic demo Preserve exact route and feature prominently Continue stating that data is synthetic and the demo is not a client deployment /case-studies/quality-intelligence/ Representative workflow proof Elevate to /workflow-evidence/quality-intelligence/ Do not add “live demo” until a real public artifact exists /case-studies/product-evidence/ Representative workflow proof Elevate to /workflow-evidence/product-evidence/ Do not imply autonomous prioritization, roadmap decisions, or customer results /case-studies/crm-hygiene-agent/ Portfolio prototype Incorporate into /workflow-evidence/revenue-intelligence/; rename user-facing concept to “CRM Hygiene Review Workflow” Label it as a portfolio prototype, not client work /case-studies/pre-crm-research-agent/ Portfolio workflow page Incorporate into Revenue Intelligence; remove “Agent” from primary public label Confirm implementation and deployment state before calling it a working demo /case-studies/mawi/ Reference implementation Use as a Revenue Intelligence architecture example Remove screenshot placeholders; do not add a live-demo claim without deployment, disclosure, and README work /case-studies/iquote/ Working commercial quote demonstration Preserve route and position as adjacent Revenue Intelligence evidence Verify the public deployment before launch; retain representative-data and non-production disclosures /case-studies/product-impact-at-paypal/ Employment-experience evidence Remove from primary Workflow Evidence grid; retain only as secondary experience evidence if fact-sheet approved Employer, role scope, ownership wording, metrics, confidentiality, and publication permission require confirmation /case-studies/g2-organic-products/ Founder/operator-style evidence Remove from primary evidence grid pending confirmation Current title and description assert founder-led work; do not reuse without explicit approval /case-studies/insight-driven-journaling-app/ Independent personal product Move to independent/selected builds on About or archive Label as independent product work Nested Insight Journal deep dives Detailed project documentation Preserve URLs but remove from primary buyer journey Avoid implying commercial deployment /case-studies/relationship-intelligence-copilot-for-linkedin/ Concept/product case study Archive from primary evidence Do not imply live deployment or verified impact /case-studies/long-form-blog-content-generator/ Secondary content workflow Remove from the main commercial pillar grid Generic content automation is not a core offer Other deep-dive routes Supporting product documentation Preserve initially; consolidate only after link review Use explicit project-status labels Existing metadata already distinguishes several workflows as “representative,” “portfolio,” or “working,” which provides a sound foundation for the evidence taxonomy. {line_range_start=3 line_range_end=5 path=Case Studies/implementation-intelligence.md git_url=”https://github.com/mahadevupadhyayula/mahadevupadhyayula.github.io/blob/main/Case Studies/implementation-intelligence.md#L3-L5”}{line_range_start=3 line_range_end=5 path=Case Studies/crm-hygiene-agent.md git_url=”https://github.com/mahadevupadhyayula/mahadevupadhyayula.github.io/blob/main/Case Studies/crm-hygiene-agent.md#L3-L5”}{line_range_start=3 line_range_end=5 path=Case Studies/iquote.md git_url=”https://github.com/mahadevupadhyayula/mahadevupadhyayula.github.io/blob/main/Case Studies/iquote.md#L3-L5”}
Global components and visual system Header Current navigation uses older labels and conversion paths. Replace it with:
Services
Workflow Evidence
Insights
About
Start a Workflow Audit
The wordmark should remain the Home link.
Footer Reduce generic portfolio and external-platform prominence. Include:
One-sentence practice position.
Four pillar links.
Primary routes.
Email, LinkedIn, and GitHub.
Restrained secondary Contra link, if Mahadev confirms it remains useful.
Privacy reminder.
Start a Workflow Audit CTA.
Form/modal The existing shared form provides a reusable foundation, but workflow_type currently combines a commercial offer with multiple workflow categories. The browser and Edge Function also maintain duplicated allowlists that must be migrated together.
Metadata The configuration already uses the custom canonical domain and suitable global social links. Page-level metadata is inconsistent and must be normalized.
Sitemap The sitemap currently emits every non-noindex page, including pages that may later become redirect-only or archival. The migration must ensure redirect shells do not remain canonical sitemap destinations.
- Claim inventory and approval controls Because the approved fact sheet was unavailable, this section defines a conservative publication boundary.
A. Safe public claims These are safe when stated as practice positioning, process description, or demonstrable repository behavior—not as historical achievements:
Mahadev designs or builds human-approved AI workflow products.
The intended audiences are B2B SaaS, B2B software, and technology-enabled services teams.
The control system combines:
AI-assisted extraction and reconciliation;
deterministic validation;
source-linked review;
human approval;
controlled outputs.
The site contains a guided Sales-to-Implementation Validator using representative synthetic data.
iQuote can be described as a portfolio build only after its deployment and current behavior are reverified.
CRM Hygiene can be described as a portfolio prototype because its current source labels it that way. {line_range_start=3 line_range_end=5 path=Case Studies/crm-hygiene-agent.md git_url=”https://github.com/mahadevupadhyayula/mahadevupadhyayula.github.io/blob/main/Case Studies/crm-hygiene-agent.md#L3-L5”}
Implementation, Quality, and Product Evidence can be described as representative workflow proofs because their current metadata does so. {line_range_start=3 line_range_end=5 path=Case Studies/implementation-intelligence.md git_url=”https://github.com/mahadevupadhyayula/mahadevupadhyayula.github.io/blob/main/Case Studies/implementation-intelligence.md#L3-L5”}{line_range_start=3 line_range_end=5 path=Case Studies/quality-intelligence.md git_url=”https://github.com/mahadevupadhyayula/mahadevupadhyayula.github.io/blob/main/Case Studies/quality-intelligence.md#L3-L5”}{line_range_start=3 line_range_end=5 path=Case Studies/product-evidence.md git_url=”https://github.com/mahadevupadhyayula/mahadevupadhyayula.github.io/blob/main/Case Studies/product-evidence.md#L3-L5”}
B. Portfolio and demo claims requiring explicit labels Use one of these labels on every applicable artifact:
Guided synthetic demo
Working portfolio demo
Portfolio prototype
Reference implementation
Representative workflow brief
Independent product build
Employment experience
Concept/archive
Every evidence card must answer:
What is demonstrated?
What data is used?
Is it publicly deployed?
What human decision remains?
What is not claimed?
Is it client work? If not, say so.
C. Needs Mahadev confirmation Do not put the following in recommended public copy until supported by the fact sheet and explicitly approved:
Employment at PayPal or Donato Technologies.
Exact titles, dates, and responsibilities.
“Ex-PayPal.”
“5+ years” or any experience-duration claim.
Ownership of particular PayPal initiatives.
Contribution versus co-ownership wording.
Numerical PayPal metrics.
The metric definition, baseline, period, sample, attribution, confidentiality status, and publication permission.
Founder or owner status for G2 Organic Products.
Operational or financial results associated with G2 Organic Products.
Whether MAWI is deployed and publicly accessible.
Whether CRM Hygiene has a stable public demo.
Whether iQuote’s current public deployment may be promoted commercially.
Sprint duration.
Workflow Audit deliverables and fixed-fee boundary.
Advisory cadence and minimum term.
Availability, geography, and time-zone wording.
A personal detail for About.
Whether Contra remains an active procurement channel.
D. Facts that should not be used Unless new, explicit evidence is supplied:
Invented client names or logos.
Testimonials not supplied by their authors.
Claims that representative workflows are client work.
“Proven ROI,” “guaranteed savings,” or equivalent promises.
Illustrative monetary models presented as expected outcomes.
Unsupported customer adoption, deployment, or production claims.
“Founder” where only project creation or operational contribution is verified.
Full ownership where the source says contribution or co-ownership.
Autonomous-decision language where a reviewer remains accountable.
Planned prototypes described as demos.
Confidential employer information.
Supabase keys, customer records, or internal submissions.
Claim register for implementation Create a private implementation worksheet with:
Claim Proposed wording Source Ownership level Confidentiality approved Public-use approved Status Example Exact public sentence Fact-sheet line or public artifact Owned / co-owned / contributed Yes/No Yes/No Approved / blocked No credibility claim should ship without an approved row.
- Final sitemap and route migration plan Final primary sitemap Destination Canonical route Role Home / Practice proposition and conversion overview Services /services/ Three-offer comparison and qualification Workflow Evidence /workflow-evidence/ Evidence taxonomy and pillar hub Revenue Intelligence /workflow-evidence/revenue-intelligence/ Revenue workflow evidence Implementation Intelligence /workflow-evidence/implementation-intelligence/ Handoff validation evidence and guided demo Quality Intelligence /workflow-evidence/quality-intelligence/ Escalation-to-defect evidence Product Evidence /workflow-evidence/product-evidence/ Customer-request evidence packs Insights /insights/ Buyer-oriented workflow guidance About /about/ Verified credibility, principles, and human context Start a Workflow Audit /start-a-workflow-audit/ Canonical inquiry destination The four pillar routes should be children of Workflow Evidence, not four separate top-level desktop navigation links.
Redirect plan Old route Destination /case-studies/ /workflow-evidence/ /case-studies/implementation-intelligence/ /workflow-evidence/implementation-intelligence/ /case-studies/quality-intelligence/ /workflow-evidence/quality-intelligence/ /case-studies/product-evidence/ /workflow-evidence/product-evidence/ /case-studies/crm-hygiene-agent/ /workflow-evidence/revenue-intelligence/#crm-hygiene /case-studies/pre-crm-research-agent/ /workflow-evidence/revenue-intelligence/#pre-crm-validation /work-with-me/ /start-a-workflow-audit/ /blogs/ /insights/ Sales-to-Implementation demo Preserve unchanged /case-studies/iquote/ Preserve /case-studies/mawi/ Preserve until Revenue Intelligence consolidation is complete Individual blog URLs Preserve Independent projects Preserve initially; remove from navigation Nested product deep dives Preserve initially; evaluate later Redirect implementation Because this is a static Jekyll/GitHub Pages project:
Update all internal links first.
Add lightweight legacy pages with:
canonical destination;
immediate meta refresh;
visible fallback link;
noindex;
accessible explanatory text.
Use server- or edge-level 301 redirects later if the hosting architecture supports them.
Preserve query parameters where practical, especially intent, UTM parameters, and pillar context.
Exclude redirect-only pages from the canonical sitemap.
- Global design and messaging system Navigation Desktop Text wordmark/Home.
Services.
Workflow Evidence.
Insights.
About.
Solid primary CTA: Start a Workflow Audit.
Workflow Evidence may use an accessible dropdown containing the four pillars, but the hub must remain directly selectable.
Mobile Compact header.
Explicit “Menu” button.
Full navigation panel with identical ordering.
CTA inside the menu rather than permanently covering content.
Focus enters the panel when opened and returns to the trigger when closed.
Escape closes the panel.
CTA hierarchy Primary Start a Workflow Audit
Use in the header, homepage, Services, About, evidence pages, footer, and article conclusions.
Secondary Explore Workflow Evidence
Use on the homepage and Services.
Lead submit Send Workflow Inquiry
Use only on the form’s submission button.
Context-specific evidence links Open Guided Demo
Inspect the Workflow
View the Evidence Pack
Review the Architecture
View Working Portfolio Demo
Do not create several synonymous commercial CTAs.
Core message pattern Every workflow explanation should identify:
Scattered inputs.
AI extraction/reconciliation.
Deterministic checks.
Source-linked review.
Accountable reviewer.
Controlled output.
Pilot measure.
System boundary.
Visual states State Visual role Required textual cue Source evidence Neutral navy/gray Source name and evidence type AI proposal Muted blue outline “Proposed” Confirmed evidence Blue or green “Confirmed” and source link Gap Amber “Missing” or “Needs review” Conflict/blocker Red or strong amber “Conflict” or “Blocking” Reviewer decision High-contrast solid treatment Explicit decision verb Controlled output Bordered final panel “Approved output” or “Pending approval” Color must never be the only state indicator.
Typography Retain the existing system stack; add no font dependency.
Recommended scale:
H1: clamp(2.5rem, 6vw, 4.75rem)
H2: clamp(1.9rem, 4vw, 3rem)
H3: 1.25rem–1.5rem
Lead: 1.125rem–1.375rem
Body: 1rem–1.0625rem
Small/meta: 0.8125rem–0.9rem
Keep body copy near 65–75 characters per line.
Layout Maximum shell width: 1200–1280px.
Reading width: 680–760px.
Gutters:
mobile: 20px;
tablet: 32px;
desktop: 48–64px.
Section spacing:
mobile: 64–80px;
desktop: 96–128px.
Avoid making every section an identical card grid.
Use realistic workflow artifacts to establish visual hierarchy.
Card system Use separate component roles:
Pillar card.
Offer card.
Source-evidence card.
Validation finding.
Reviewer-decision panel.
Approved-output panel.
Workflow Evidence card.
Insight card.
Recommended radius: 16–24px, with restrained borders and shadows.
Responsive behavior Four-column sections collapse to two and then one.
Comparison tables become labeled offer cards on narrow screens.
Workflow diagrams switch from horizontal to vertical.
Evidence artifacts order as:
inputs;
findings;
validation;
reviewer;
output.
No meaningful content should require horizontal scrolling at 320 CSS pixels.
Buttons may become full-width below 480px.
Accessibility requirements Target WCAG 2.2 AA:
Semantic landmarks.
Skip link.
One H1.
Logical heading hierarchy.
Keyboard-operable navigation, dialogs, accordions, and demos.
Visible focus.
Minimum 44×44-pixel targets.
Text alternatives for meaningful images.
Decorative images use empty alt text.
State never conveyed by color alone.
Form error summary plus linked field errors.
aria-live status for form submission.
Reduced-motion support.
200% zoom testing.
320-pixel viewport testing.
No placeholder-only labels.
No autoplaying video.
Captions or transcript for demonstrations.
- Page-by-page blueprints Home — / Goal Explain the full practice quickly and route buyers to either evidence or an Audit.
Target buyer Executive sponsor or operating leader who recognizes recurring evidence/review friction but may not yet know which intervention is appropriate.
Information architecture Hero.
Control-layer diagram.
Four pillars.
Tangible workflow evidence.
Differentiation.
Three offers.
Measurement method.
Verified credibility.
Final CTA.
Heading direction Eyebrow
Human-approved AI workflow products for B2B teams
H1
Turn scattered business evidence into reviewable decisions.
Supporting copy
Design and prototype AI-assisted workflows that structure evidence, apply deterministic checks, surface gaps and conflicts, and keep an accountable person in control of what moves downstream.
Proof requirements Use a representative workspace showing:
source items;
AI-proposed findings;
validation results;
one confirmed item;
one gap;
one conflict;
reviewer disposition;
approved-output preview.
CTAs Primary: Start a Workflow Audit
Secondary: Explore Workflow Evidence
Claim boundary The credibility section remains unpublished or generic until the fact sheet is accessible.
Services — /services/ Goal Help buyers choose Audit, Prototype Sprint, or Advisory.
Target buyer A leader deciding how much workflow definition, prototyping, or ongoing guidance is needed.
Information architecture Services hero.
Three-offer comparison.
“Which engagement fits?” decision aid.
Detailed offer sections.
Shared measurement discipline.
Four pillar examples.
Good-fit and poor-fit criteria.
FAQ.
Audit CTA.
Heading direction Choose the smallest engagement that can produce a useful workflow decision.
Proof requirements Deliverable previews for each offer.
One example baseline/hypothesis worksheet.
Clear boundaries around prototypes and production implementation.
CTAs Primary: Start a Workflow Audit
Secondary: Explore Workflow Evidence
Contextual: Discuss a Prototype Sprint / Discuss Advisory
Claim boundary Do not publish duration, capacity, pricing, or delivery cadence until confirmed.
Workflow Evidence — /workflow-evidence/ Goal Demonstrate how the practice works without implying unverified client results.
Information architecture Evidence philosophy.
Disclosure banner.
Four pillar cards.
Built and guided demonstrations.
Reference implementations.
Independent or employment evidence, clearly separated.
Evidence taxonomy.
Audit CTA.
Heading direction Inspect how evidence becomes a controlled output.
Proof requirements Each card states:
Evidence type.
Data type.
Deployment status.
Reviewer.
Demonstrated behavior.
Explicit non-claim.
CTAs Primary: Start a Workflow Audit
Secondary: Select a pillar
Revenue Intelligence Goal Connect CRM hygiene, pre-CRM validation, account research, MAWI, and adjacent commercial workflow evidence.
Target buyer CRO, RevOps leader, Sales Operations leader, GTM Operations leader.
Information architecture Revenue workflow failure.
Shared control model.
CRM Hygiene module.
Pre-CRM Validation module.
Buyer/Account Research module.
MAWI reference architecture.
Adjacent iQuote evidence.
Pilot measures.
Boundaries.
CTA.
Heading direction Improve the evidence before it becomes a CRM record or commercial action.
Visual requirement A source-backed record-review workspace showing field proposal, authority, conflict, missing data, reviewer correction, and approved update.
CTAs Primary: Start a Workflow Audit
Secondary: Inspect CRM Hygiene Evidence
Conditional: Open Working Demo, only after verification
Claim boundary No CRM Hygiene or MAWI live-demo claim until deployment is verified.
Implementation Intelligence Goal Show how a sales-to-implementation handoff can be reconciled and reviewed before kickoff.
Target buyer VP Implementation, Professional Services leader, Customer Onboarding leader, Implementation Operations leader.
Information architecture Handoff failure.
Input and source hierarchy.
Extraction and reconciliation.
Deterministic validation.
Reviewer disposition.
Controlled delivery baseline.
Guided demo.
Pilot measures.
Workflow boundaries.
CTA.
Heading direction Reconcile what was sold, promised, and required before implementation begins.
CTAs Primary evidence: Open Guided Demo
Commercial: Start a Workflow Audit
Claim boundary The guided demo remains explicitly synthetic and representative. Its current metadata already reflects this boundary.
Quality Intelligence Goal Show how fragmented escalation evidence becomes an engineering-ready defect candidate.
Target buyer VP Support, Head of Quality, Engineering Operations leader, Product Operations leader.
Information architecture Escalation failure.
Evidence inputs.
Expected versus observed behavior.
Duplicate and known-defect checks.
Routing and completeness validation.
Accountable triage.
Controlled defect candidate.
Pilot measures.
Boundaries.
CTA.
Visual requirement Synthetic triage workspace with tickets, environment context, logs, gaps, possible duplicate, and reviewer disposition.
CTAs Primary: Start a Workflow Audit
Secondary: Inspect the Representative Workflow
Do not say “Open Demo” until an interactive artifact exists.
Product Evidence Goal Show how customer requests become source-linked discovery evidence without automating roadmap decisions.
Target buyer VP Product, Product Operations leader, Discovery leader, Customer Insights leader.
Information architecture “A request is not yet a product problem.”
Evidence sources.
Deduplication and normalization.
Supporting and contradicting evidence.
Affected roles and contexts.
Missing research.
PM review.
Controlled discovery pack.
Pilot measures.
Boundaries and CTA.
Visual requirement Evidence pack with source-linked claims, alternatives, gaps, and unmistakable PM decision state.
CTAs Primary: Start a Workflow Audit
Secondary: Inspect the Evidence-Pack Pattern
Claim boundary Do not imply automated prioritization, roadmap commitment, or revenue forecasting.
Insights — /insights/ Goal Build buyer confidence through practical guidance about controlled workflows.
Target buyer Operating, product, quality, implementation, and revenue leaders evaluating workflow improvements.
Information architecture Featured guide.
Pillar filters.
Workflow Design and Measurement filter.
Curated article grid.
Newsletter only if an actual subscription process exists.
Audit CTA.
Heading direction Practical guidance for designing reviewable AI workflows.
Claim boundary Articles must distinguish guidance, hypothesis, public third-party analysis, and demonstrated practice.
About — /about/ Goal Explain why Mahadev focuses on reviewable workflows and establish credible human trust.
Information architecture Headshot and concise introduction.
Why reviewable workflows matter.
Verified experience.
Working principles.
Selected relevant builds.
Working style.
One verified personal detail.
CTA.
Heading direction Building AI-assisted workflows that people can inspect, challenge, and control.
CTAs Primary: Start a Workflow Audit
Secondary: Explore Workflow Evidence
Claim boundary Do not carry forward the homepage’s current “Ex-PayPal,” duration, product-ownership, or founder wording until approved.
Start a Workflow Audit Goal Collect enough non-confidential context to evaluate fit without forcing the buyer to write a specification.
Information architecture What the Audit is.
Who it is for.
What information is useful.
What Mahadev returns.
What happens next.
Privacy warning.
Inquiry form.
Direct email fallback.
Heading direction Start with one workflow where evidence and judgment keep colliding.
CTAs Submit: Send Workflow Inquiry
Secondary: Email Mahadev
Claim boundary Do not publish fixed-fee amount, turnaround, or deliverables until commercially confirmed.
- Four-pillar framework Revenue Intelligence Owner/buyer: CRO, RevOps, Sales Ops, GTM Operations.
Inputs: call notes, emails, CRM fields, account sources, qualification rules, buyer signals, quote/commercial inputs.
Deterministic checks: required fields, source authority, freshness, duplicates, allowed values, conflicting claims, policy rules.
Reviewer: RevOps manager, sales manager, account owner, or commercial approver.
Controlled output: approved CRM update, validated account brief, qualification disposition, research pack, or approved quote package.
Baseline metrics: correction returns, missing fields, unsupported fields, duplicate records, review time.
Pilot hypothesis: earlier source-backed validation can reduce avoidable record correction while maintaining or improving evidence quality.
Existing proof: CRM Hygiene portfolio prototype; pre-CRM page; MAWI reference implementation; iQuote working portfolio workflow pending deployment verification.
Required assets: verified screenshots, README, deployment status, synthetic-data disclosure, interaction boundary.
Implementation Intelligence Owner/buyer: Implementation, Professional Services, Onboarding Operations.
Inputs: CRM opportunity, contract/order form, discovery notes, scope documents, solution design, security requirements, handoff communication.
Deterministic checks: required artifacts, source hierarchy, unresolved owners, conflicting dates, scope mismatch, security gaps, dependency completeness.
Reviewer: implementation manager or delivery owner.
Controlled output: approved delivery baseline, clarification request, internal kickoff brief, readiness disposition.
Baseline metrics: returned handoffs, missing requirements, unresolved owners, post-kickoff rework, review cycle time.
Pilot hypothesis: detecting gaps before kickoff can reduce avoidable clarification returns without weakening implementation review.
Existing proof: representative workflow page and guided synthetic demo.
Required assets: production-quality screenshots, mobile capture, accessibility review, explicit synthetic-data label.
Quality Intelligence Owner/buyer: Support, Quality, Engineering Operations, Product Operations.
Inputs: ticket history, tenant data, reproduction steps, logs, screenshots, release context, known defects, internal notes.
Deterministic checks: evidence completeness, reproduction requirements, duplicate lookup, environment consistency, allowed routing, severity prerequisites.
Reviewer: escalation manager, quality lead, or engineering triager.
Controlled output: evidence-ready defect candidate, duplicate association, diagnostic request, or routing decision.
Baseline metrics: rerouted cases, missing evidence, duplicate creation, time to accepted defect, reviewer override.
Pilot hypothesis: validating escalation evidence before engineering handoff can increase accepted defect-candidate quality without suppressing valid escalations.
Existing proof: representative workflow brief; no verified public interactive demo.
Required assets: synthetic triage workspace, interaction specification, reviewer states, disclosure.
Product Evidence Owner/buyer: Product, Product Operations, Discovery, Customer Insights.
Inputs: feature requests, support cases, CRM/CS notes, implementation workarounds, research, usage summaries, product documentation.
Deterministic checks: source presence, duplication, recency, customer/context identity, distinct-needs separation, unsupported claims, contradiction detection.
Reviewer: product manager or discovery lead.
Controlled output: source-linked customer-request evidence pack and next-research decision.
Baseline metrics: duplicates, unsupported claims, incorrectly merged needs, missing context, review time, rewrite rate.
Pilot hypothesis: structured evidence preparation can reduce avoidable research assembly without automating prioritization.
Existing proof: representative workflow brief; no verified public interactive demo.
Required assets: synthetic evidence-pack workspace, source citations, contradicting evidence, reviewer decision, disclosure.
Pilot metric guardrails Every speed or throughput measure must have a quality guardrail:
Faster review must not increase unsupported claims.
Fewer escalations must not suppress valid defects.
More complete CRM records must not introduce uncertain data.
More evidence packs must not collapse distinct customer needs.
Greater automation must not remove accountable approval.
- Services and conversion architecture Offer comparison Offer Best fit Buyer decision Core deliverables Boundary Workflow Audit Workflow is painful but not yet sufficiently bounded Proceed, refine, or stop before prototyping Current-state map, inputs, owner/reviewer map, baseline, operating/economic hypothesis, controls, prototype recommendation, executive readout Analysis and recommendation—not a production workflow AI Workflow Prototype Sprint Workflow, reviewer, representative inputs, and output are sufficiently clear Whether the workflow warrants a pilot or implementation plan Focused prototype, extraction/reconciliation, deterministic checks, reviewer controls, representative evaluation, pilot plan Evaluable prototype—not unrestricted production deployment AI Workflow Advisory Team has active workflow initiatives and needs recurring support What to prioritize, measure, refine, scale, or stop Recurring reviews, metric interpretation, validation/control guidance, architecture decision support, workflow portfolio prioritization Advisory and bounded decision support—not embedded full-time delivery Measurement discipline Every offer must use:
Current baseline → workflow measure → target improvement hypothesis → pilot measurement → scale / refine / stop decision
Example:
Baseline: handoffs regularly return for clarification.
Workflow measure: handoffs returned after implementation review.
Hypothesis: earlier gap detection can reduce avoidable returns.
Pilot: compare a defined sample against the current workflow.
Quality guardrail: no increase in overlooked material requirements.
Decision: scale, refine, or stop.
Do not insert assumed dollar values into public calculators.
CTA routing Source Primary route Preselection Global navigation /start-a-workflow-audit/ Workflow Audit / Not sure Homepage /start-a-workflow-audit/ Workflow Audit Services Audit /start-a-workflow-audit/?engagement=audit Audit Sprint section /start-a-workflow-audit/?engagement=prototype Prototype Sprint Advisory section /start-a-workflow-audit/?engagement=advisory Advisory Pillar page Audit route plus pillar query Relevant pillar Article Audit route plus source context Not sure or relevant pillar All preselected values must remain editable.
Engagement boundaries State globally:
No autonomous high-consequence business decisions.
No production-readiness claim from a prototype.
No unrestricted access to confidential customer data during initial inquiry.
No guaranteed ROI.
No company-wide transformation promise.
Production implementation, monitoring, security, and support require separately defined scope.
- Supabase inquiry-form plan Current implementation The current design uses:
Browser form → Supabase Edge Function → server-side service-role insert
This is appropriate because the service-role credential remains server-side and the database intentionally provides no anonymous insert policy.
Current collected fields include:
name;
work email;
company;
intent;
workflow type;
current workflow;
desired output;
human approval;
tools;
timeline;
budget range;
page URL;
referrer;
user agent.
The current Edge Function:
normalizes email;
validates required fields;
enforces workflow-type allowlists;
applies length limits;
uses permissive Access-Control-Allow-Origin: *;
truncates optional strings before insertion.
Recommended fields Required Name.
Work email.
Company.
Owning team.
Engagement interest:
Not sure / Workflow Audit;
Prototype Sprint;
Advisory.
Workflow pillar:
Revenue Intelligence;
Implementation Intelligence;
Quality Intelligence;
Product Evidence;
Other.
Current workflow and source inputs.
Decision, handoff, or output at stake.
Accountable reviewer role.
Current failure or friction.
Privacy/non-confidential submission acknowledgement.
Optional Systems involved.
Current baseline.
Timeline.
Preferred contact method.
Referral context.
Budget readiness:
Scope first;
Budget approved;
Budget under review.
Do not display numeric budget bands without explicit approval.
Hidden/derived CTA intent.
Source page.
UTM fields.
Referrer.
Schema version.
Server-generated submission timestamp.
Honeypot.
User agent only if operationally necessary and disclosed.
Validation Preserve client validation for usability and server validation for authority.
Separate engagement and pillar allowlists.
Normalize email to lowercase.
Reject overlong critical narratives instead of silently truncating them.
Validate URLs only when supplied.
Restrict accepted origins to production and approved preview domains.
Add accessible error summary and field-linked errors.
Add rate limiting.
Do not accept files or confidential source records in the first-contact form.
Preserve a direct-email fallback.
Routing Store new structured fields:
engagement_interest
workflow_pillar
owning_team
reviewer_role
current_failure
baseline
privacy_acknowledged
UTM values
schema_version
Suggested internal statuses:
new;
reviewing;
needs clarification;
qualified;
not now;
not fit;
closed.
Backward-compatible migration Inspect the actual production schema.
Add new columns as nullable.
Expand the Edge Function to accept both old and new payloads.
Deploy the backward-compatible server first.
Update the browser form second.
Test new and old payload shapes.
Backfill only reliably mapped values.
Add constraints after backfill.
Remove obsolete fields in a later migration.
Document rollback.
Key risks Frontend, Edge Function, and SQL constraints contain duplicated allowlists.
Changing the form first could produce rejected production submissions.
Old workflow_type values mix engagement and use-case taxonomies.
- CORS unnecessarily broadens accepted browser origins.
Silent optional-field truncation could conceal data-quality problems.
Redirect query parameters could be lost.
Production Supabase schema may not exactly match local migrations.
No form or Supabase changes belong in Phase 1.
- About-page plan Why Mahadev focuses on reviewable workflow products The narrative should explain that AI becomes operationally useful when:
source evidence remains inspectable;
extraction is separated from validation;
uncertainty is visible;
policies and required checks are deterministic;
an accountable person controls downstream action.
This is a working philosophy, not a biography-first pitch.
Verified experience that may inform the approach Use only facts in the accessible approved fact sheet. Potential categories, not yet approved claims:
Product work.
Quality or testing experience.
Implementation or onboarding operations.
Data/ML-related product contribution.
Independent workflow-product builds.
Commercial or operating experience.
How Mahadev thinks Present five principles:
Evidence before assertion.
Validation outside the model where rules are deterministic.
Source links for consequential findings.
Human approval at the decision boundary.
Bounded pilots measured against a baseline.
What it is like to work with him Proposed framing, subject to confirmation:
Starts with one bounded workflow.
Works from representative evidence rather than abstract AI strategy.
Makes assumptions and constraints visible.
Separates prototype behavior from production readiness.
Defines scale/refine/stop criteria before expansion.
Buyer-relevant facts After fact-sheet review, select no more than three headline facts. Prefer:
Relevant role or product scope.
Relevant workflow or quality experience.
Publicly demonstrable independent build.
Avoid a large resume timeline.
Human element Use the existing headshot as the initial warm asset. Request one genuine personal detail, such as:
why this work matters personally;
a building or learning practice;
a relevant operator experience;
a non-sensitive interest that makes the page feel human.
Do not invent it.
- Insights strategy Retain and feature AI Agents Are Overhyped — The Real Future Is Workflow-First Systems Strong positioning fit. Refresh around control boundaries, validation, review, and workflow evaluation.
Why AI Accuracy Metrics Can Mislead Product Teams Strong measurement fit. Add reviewer override, unsupported-claim, downstream-error, and workflow-level quality measures.
Retain and reposition Data-Driven vs Driven by Data Position under Product Evidence and evidence-informed decision-making.
The North Star Metric in AI-Driven Product Development Rework around workflow measures and quality guardrails rather than generic product metrics.
Inside Zapier’s AI Playbook Keep as secondary third-party analysis. Clearly separate external analysis from Mahadev’s demonstrated practice.
The AI Red Ocean Trap Keep in the archive or broader strategy category, not as a primary featured article.
Substantially rewrite or remove from the main feed The Invisible Workflows Its “dynamic multi-agent orchestration” framing conflicts with the restrained, human-approved positioning. Rewrite around visible controls or archive it.
Why I Am Building Evidra.ai Move to Independent Projects or a personal-build archive. It does not directly serve the consulting buyer.
Remove from the public index Remove the visible future-topic backlog from the live page. Maintain it privately.
Future buyer-intent topics Foundation How to Choose a B2B Workflow for an AI Pilot.
AI Extraction Is Not Validation.
How to Design a Human Approval Gate.
A Practical Measurement Model for AI Workflow Pilots.
Source-Linked Evidence Between AI Output and Business Decisions.
When to Scale, Refine, or Stop a Workflow Pilot.
Revenue Intelligence CRM Hygiene Without Autonomous Record Updates.
What to Validate Before Account Research Enters the CRM.
A Review Model for AI-Assisted Account Research.
Implementation Intelligence What a Sales-to-Implementation Handoff Must Prove.
Detecting Scope, Owner, Security, and Timeline Conflicts.
Measuring an Implementation-Handoff Pilot Without Promising ROI.
Quality Intelligence From Support Escalation to Engineering-Ready Defect Evidence.
What AI Should Not Decide in Defect Triage.
Measuring Escalation Quality Beyond Resolution Time.
Product Evidence A Customer Request Is Not Yet a Product Problem.
Building a Source-Linked Customer-Request Evidence Pack.
Deduplicating Feedback Without Erasing Distinct Needs.
Editorial template Each buyer-focused article should include:
target buyer;
workflow boundary;
source inputs;
reviewer;
controlled output;
failure modes;
baseline;
pilot hypothesis;
quality guardrail;
contextual Audit CTA.
- Implementation plan Phase 1 — Evidence, claims, and content architecture Scope Obtain and review the approved fact sheet.
Crawl production.
Build claim register.
Confirm demos and deployment status.
Approve final routes, labels, offers, and CTA system.
Prepare final content matrix.
Dependencies Accessible fact sheet.
Production access.
Offer confirmation.
Demo URLs and README status.
Analytics/inbound-route data.
Acceptance criteria Every proposed public claim has an approved source.
Every route has a keep, migrate, redirect, archive, or remove decision.
Every artifact has an evidence label.
No numerical result remains unreviewed.
Verification Production/local route comparison.
Metadata inventory.
Broken-link baseline.
Claim-register review.
Demo health check.
Approval required Mahadev approves claims, route map, offer definitions, and archive decisions.
Phase 2 — Shared shell and design system Scope Update tokens, typography, layout, buttons, evidence states, cards, header, footer, modal, and metadata conventions.
Build reusable evidence and offer components.
Preserve existing routes while shared components change.
Dependencies Phase 1 messaging and CTA approval.
Approved visual direction.
No new dependencies.
Acceptance criteria Global navigation works on desktop and mobile.
Evidence states are consistent.
Focus behavior is correct.
Header and footer use final routes and CTA hierarchy.
Existing important routes still render.
Verification Jekyll build.
Keyboard navigation.
Responsive viewport checks.
200% zoom.
Contrast and semantic structure.
Screenshot review.
Approval required Mahadev approves shared shell and representative page components before full rollout.
Phase 3 — Core routes and Workflow Evidence Scope Implement:
Home.
Services.
Workflow Evidence hub.
Four pillar pages.
About.
Insights.
Start a Workflow Audit.
Create representative Quality and Product Evidence artifacts if approved.
Dependencies Approved page copy.
Approved claims.
Approved assets and disclosures.
Confirmed demo states.
Acceptance criteria Four pillars appear consistently.
Services presents exactly three primary offers.
No public pricing.
All evidence has status labels.
No fake demo or placeholder.
About contains only approved claims.
Insights is curated.
Verification Build.
Full route crawl.
Internal-link check.
Metadata and canonical check.
Structured-data validation.
Accessibility checks.
Desktop and mobile screenshots.
Approval required Mahadev approves all buyer-facing copy and evidence artifacts.
Phase 4 — Redirects, form migration, archive, and launch QA Scope Add legacy-route redirects.
Migrate the form schema safely.
Update Edge Function and frontend in backward-compatible order.
Reclassify independent and employment material.
Update sitemap and robots behavior.
Perform launch QA.
Dependencies Production Supabase schema inspection.
Approved form fields and privacy text.
Notification/routing decisions.
Analytics/inbound-route review.
Production deployment access.
Acceptance criteria Old important routes redirect or remain accessible.
Old and new form payloads work during migration.
No secrets enter client code.
Demo links are healthy.
Canonical sitemap contains only intended public destinations.
No unapproved claims or placeholders remain.
Build passes.
Verification Build command.
Redirect crawl.
Form validation matrix.
Controlled end-to-end test submissions.
CORS/origin test.
Broken-link test.
Metadata/canonical test.
Mobile and accessibility regression.
Deployment-parity review.
Approval required Mahadev approves the production form test, redirect report, and final launch checklist before publication.
- Decisions needed from Mahadev Place the approved fact sheet inside the repository or provide an accessible Linux path. Placed
Confirm whether PayPal and Donato Technologies may be named publicly. Yes
Confirm approved role titles, dates, responsibility scope, and ownership wording. Yes Confirm whether any numerical PayPal metric may be published, including definition, period, contribution, confidentiality, and approval. No Confirm whether founder or owner language may be used for G2 Organic Products. Ignore this role Approve the exact Workflow Audit deliverables and boundaries. approved Confirm Prototype Sprint duration and deliverables. approved Confirm Advisory cadence, boundaries, and minimum term. approved Approve the canonical routes:
/workflow-evidence/;
/insights/;
/start-a-workflow-audit/.
approved Decide whether CRM Hygiene and pre-CRM pages consolidate fully or retain detailed child pages. Retain detailed child pages Confirm public deployment status for CRM Hygiene, MAWI, and iQuote. iQuote Deployed. Demo Link: https://i-quote-seven.vercel.app/quotes
Approve removal of MAWI placeholders until genuine artifacts exist. Yes
Confirm whether Contra remains in the footer as a secondary procurement option. Yes
Approve removal of numeric budget bands from the public inquiry form. Yes
Provide inquiry privacy, retention, and notification preferences. Yes
Approve archiving Evidra, Insight Journal deep dives, Relationship Intelligence, and generic content automation from the main buyer journey. Yes
Approve the CTA hierarchy. Yes
Provide or approve Quality and Product Evidence workspace assets. Yes
Supply one verified personal detail for About. Yes
Confirm whether production analytics are available for route and redirect decisions. Yes