Meenakshi Ramesh

Projects

Complex topics, delivered as clear outputs.

How I scope a problem, choose an approach, work with stakeholders and deliver results.

Confidentiality. Employer work is covered by an NDA, so results are described without client data, internal metrics or screenshots. I'm happy to talk through them in an interview.

Case study 01

Content quality & search visibility recovery

Context & problem

Objective: make the blog content on a network of regulation websites accurate and visible in Google and AI answers.

Challenge: an AI agent built on Bolt.new was publishing new articles every day across 5 websites. No one was overseeing the content, quality problems were spreading faster than anyone could review them, and Google was crawling many pages without indexing them.

Approach

  • Took ownership. Asked the CEO to let me take this on, because wrong information could damage the company's credibility.
  • Audited the content and found four recurring issues: broken (404) links, originality issues, outdated content and inconsistent structure.
  • Prioritised the sites P1, P2, P3: the GDPR site first (high impressions, no clicks), then the EU AI Act site, then the rest.
  • Learned SEO and AEO and turned them into a checklist for every post: short answer first, summary, key takeaways, H1 to H3 headings, internal and external links, conclusion and FAQ.
  • Delivered one website per week: content fixes and testing by me, technical fixes batched to the developer, re-indexing the next week.
  • Prevented a repeat: changed the AI agent's prompt, added a review step for new posts and handed the process over to the developer in writing.
Weekly cycle, repeated for each website
  1. Fix content
  2. Test
  3. Report technical fixes
  4. Developer fixes
  5. Re-index
  6. Review

Results

  • Quality: one consistent, search-ready structure for every blog post.
  • Speed: every optimised blog post on all 5 sites was indexed within a few days of requesting re-indexing.
  • Visibility: posts that had been crawled but not indexed began earning impressions and clicks, and rankings improved after the meta tag fix.
  • Lasting: a changed AI-agent prompt, a review step for new posts, and a documented handover to the developer.

Challenges

ChallengeHow we overcame it
After 15 days there was no improvement, and the CEO wanted to drop the projectExplained that re-indexing can take up to 30 days and agreed 2 more weeks. In that time I found the meta tags and descriptions were stale; the CEO added them to scope, the developer fixed them and rankings improved
The AI agent kept making mistakes after its prompt was changedQuality improved, but output still varied, so a human review step for every new post became part of the process and was handed over to the developer
The developer and I disagreed on whether pages were indexedChecked the Pages report in Search Console myself and used it as the single source of truth
A shared developer was the bottleneck for every technical fixBatched fixes into one weekly report, so the developer's time was planned and re-indexing could happen at the start of the next week

Risks

RiskHow we overcame it
Wrong legal information published under the company's name, damaging its credibility with privacy buyersClaude checked every page against its source, then I checked every fact by hand
The AI agent creating new bad posts as fast as old ones were fixedChanged the prompt (no plagiarism, today's date, facts from the original source) and added a review step
The project being cancelled before indexing had time to show resultsSet expectations on the 30-day lag and agreed a 2-week extension with the CEO
Plagiarised text with no paid checker to catch itRan several free checkers, rechecked with OpenAI, then compared against the source
Fixes lost in a busy Slack channelWeekly batched report to the developer; lesson below

Lessons learned

  • Build validation in from day one. Plagiarism checks, source comparison and fact-checking belong before publishing, not after problems appear.
  • Check technical SEO before assuming content is the problem. The stale meta tags could have been found weeks earlier.
  • Set an interim checkpoint. A review point after 2 weeks would have let us adjust before the CEO lost confidence.
  • Use an issue tracker, not Slack. A shared log with URL, problem, evidence, owner and status would have avoided the back-and-forth over indexing.
  • Changing an AI prompt is not enough on its own. AI output still varies, so a human review step has to stay.

Project appreciation

"Meena is warm, charming, communicative, and a fast learner who brings a positive energy to any team."
Dan Storbaek, CEO, Secure Privacy · from his LinkedIn recommendation

Case study 02

EU AI Act content & readiness

Context & problem

Objective: help organisations prepare for the EU AI Act, and give the company a practical asset to start those conversations.

Challenge: a new, complex regulation. It wasn't clear where the market's offerings, the legal requirements, the company's own offering and buyers' real needs overlapped, or where the gaps were.

Approach

  • Gap analysis in four parts: what is available on the market, what the regulation requires, what the company already offers, and what users actually need.
  • Segmented by audience. Marketing, Technical and Legal/DPO buyers need different answers, so the content was split for each.
  • Leadership alignment. Prepared a readiness plan for leadership review.
Gap analysis
MarketWhat is available
RegulationWhat is required
CompanyWhat is offered today
UsersWhat they actually need
→ Segmented readiness checklist

Results

  • A client-facing EU AI Act readiness checklist, with a version for each audience.
  • Used as a lead-generation asset to start conversations with buyers.

Challenges

ChallengeHow we overcame it
One asset had to serve three buyers with different questions, across every kind of business the Act applies toSplit it into a version for each buyer audience instead of one document trying to serve everyone
A new regulation with little settled guidance to lean onWorked from the regulation itself as one of the four parts of the gap analysis
Leadership needed to agree before the asset went to clientsPrepared a readiness plan for leadership review

Risks

RiskHow we overcame it
A one-size checklist so broad that no buyer finds it useful, so it generates no leadsA version per audience, built around what users actually need
The checklist implying the product covers requirements it doesn't, creating false expectations in sales conversationsMapped what the company offers today and kept the checklist within it
Misstating obligations on a regulation buyers rely on for complianceTook requirements from the regulation text, not from market summaries

Lessons learned

  • Decide who the content is for before writing it. Covering every business in one version made it unclear; segmenting fixed that.
  • Start from the source text on a new regulation. Market summaries are useful for comparison, not for requirements.
  • Bring leadership in at the plan stage. Early review keeps the asset aligned with what the company sells.

Project appreciation

"Meena quickly expanded her responsibilities into AI-related projects and various sales activities."
Dan Storbaek, CEO, Secure Privacy · from his LinkedIn recommendation

Case study 03

GDPR enforcement series & regulation pages

Context & problem

Objective: make a large library of GDPR regulation pages more useful to readers and more visible in Google.

Challenge: pages were crawled by Google but not indexed. Readers got the legal text with no summary, no real-world examples and no clear path to the product.

Approach

  • Designed one page format for articles, recitals and key issues, so every page answers the same questions in the same order.
  • Built the UI for 50 pages with AI: the full page, including navigation, summary boxes, tables, FAQ and structured data.
  • Added an enforcement case study series: each page links to a hub of real regulator and court decisions, and each decision has its own page with background, findings, timeline, outcome and sources.
  • Reviewed with the CEO page by page, then handed over to the developer, who published them.
Structure of every page I built
  1. In short
  2. Key provisions
  3. Recitals
  4. Enforcement cases
  5. Checklist
  6. FAQ
Every enforcement case study page
  1. Background
  2. What was decided
  3. Timeline
  4. Outcome
  5. Recommendations
  6. Sources
Before and after, per page
BeforeAfter
Google statusCrawled, not indexedIndexed, on page 1
SummaryNone"In short" box and page contents at the top
RecitalsNot linkedLinked, with a one-line explanation
Enforcement examplesNoneCase table, hub and a page per case
Practical guidanceNoneChecklist and FAQ
Path to the productUnclearCall to action tied to the topic

Results

  • 50 pages rebuilt in one consistent format and published.
  • Indexing: pages that had been crawled but not indexed were indexed after the changes.
  • Page 1: every optimised page appeared on Google's first page after re-indexing.
  • Conversions: click-throughs from the call to action to the main product site in the latest 28 days were above the three-month average.

Challenges

ChallengeHow we overcame it
Getting executive sign-off on a new format across 50 pagesRevised the pages after each CEO review and turned his recurring feedback into rules in the page format, so later pages needed fewer changes
Delivering 50 pages without design or developer capacityBuilt the full UI myself with AI in one standard format, so the developer only had to publish
Dense legal text that readers skipPut an "In short" answer and page contents at the top, and explained each linked recital in one line

Risks

RiskHow we overcame it
A wrong fine, date or article number on a public legal reference siteEvery case page lists its sources, linking to the regulator's or court's own decision
Readers taking our advice as the regulator's findingRecommendations labelled as ours, with a note that they are not findings or orders of the authority
Pages still not indexed after all the workUnique title, description and canonical on every page, plus FAQ and breadcrumb structured data
The CEO rejecting the format after all 50 pages were builtReviewed with the CEO as pages were built, so changes were made early

Lessons learned

  • Turn feedback into rules. Building the CEO's recurring comments into the page format cut revisions on later pages; agreeing the format on the first few pages would have cut them further.
  • Source every legal fact on the page. Visible sources make review faster and build reader trust.
  • AI makes one person a page builder. Building the UI myself removed the developer as a bottleneck for design.

Project appreciation

"Her skills go far beyond sales, and she has great potential as a future project manager."
Dan Storbaek, CEO, Secure Privacy · from his LinkedIn recommendation

Case study 04

Pedigree Analyst: a content site, end to end

Context & problem

Objective: launch a credible, easy-to-read learning site built on a Chartered Accountant's expert knowledge.

Challenge: expert finance content is dense, and the site had to earn trust from both beginners and search engines.

Approach

  • Planned the structure: beginner and advanced tracks, a glossary and an economics section.
  • Ran the editorial workflow with the author, editing expert lessons into plain language.
  • Delivered in small releases: each change reviewed in GitHub and deployed to Cloudflare.
  • Built in visibility: structured data, sitemap, llms.txt and Google Search Console from launch.
Delivery pipeline
  1. Plan
  2. Write and edit
  3. Build
  4. Review
  5. Deploy
  6. Track

Results

  • Live: a maintained site with a regular publishing workflow.
  • Measured: traffic tracked in Google Search Console.

Challenges

ChallengeHow we overcame it
Scope creep: the author kept requesting revisions to lessons after they were published, delaying new onesShipped each revision as a small release and kept new lessons moving through the pipeline alongside them
Making expert finance content usable for beginners without losing accuracyEdited the lessons into plain language, with a glossary for terms, and the author reviewed every change

Risks

RiskHow we overcame it
Simplifying finance content until it becomes wrong, misleading beginner tradersThe Chartered Accountant author reviews every lesson before it goes live
Endless revisions stalling the publishing scheduleRevisions handled as small, separate releases
A new site with no authority being ignored by GoogleStructured data, sitemap, llms.txt and Search Console from day one

Lessons learned

  • Agree what "done" means before publishing. A sign-off step with the author would cut revisions after a lesson is live.
  • Batch post-publication feedback. Collecting changes into one review slot protects time for new content.
  • Build search visibility in at launch. Adding it later means re-indexing pages that could have been right the first time.

Case study 05

Setting up a therapy service from scratch

Context & problem

Objective: launch a new speech-language therapy service and make it profitable.

Challenge: there was no existing service, process or referral network to build on, and the budget was limited.

Approach

  • Planned the service before launch: what we would offer, to whom and how.
  • Owned marketing and sales: responsible for the activities that brought clients to the new service.
  • Built a stakeholder network to bring in referrals and clients.
  • Led a team of two speech-language pathologists while delivering care myself, reporting to the clinical head.
  • Set SMART goals and tracked leads, conversion and retention in Excel dashboards.
From nothing to a profitable service
  1. Plan
  2. Build network
  3. Launch
  4. Track
  5. Profit

Results

  • INR 50,000 profit within the first few months: four months after setup, the service was named monthly winner.
  • Measured: leads, conversion and retention tracked against SMART goals.

Challenges

ChallengeHow we overcame it
Setting up a service with no existing process, clients or referral networkBroke the setup into stages: plan the service, build the network, launch, then track against SMART goals
Potential partners were hesitant to sign a partnership with a newcomerKept building the network one partner at a time, using the service's early results to earn trust
Pressure from all sides to deliver fastPrioritised against the SMART goals and used the dashboards to show progress on leads, conversion and retention
Running the setup while delivering care, on a limited budgetShared the caseload across the team and grew through referrals rather than paid channels

Risks

RiskHow we overcame it
Launching with too few clients to cover costsBuilt the stakeholder network for referrals before and during launch
Partnerships not being signed, leaving the service without referralsApproached partners one at a time and used early results as evidence
Clients dropping out of therapy before it could help themTracked retention in the dashboard alongside leads and conversion
Setup work pulling time away from patient careShared the caseload across a team of three

Lessons learned

  • Trust follows results. Partners hesitant to work with a newcomer came round once there was evidence the service worked.
  • Measure from the first month. The dashboards showed what was working long before results were obvious.
  • Find a mentor early. Without anyone to guide me, some lessons came through trial and error.

Project appreciation

"She had to set up everything from scratch. She straddled setup issues and care delivery with ease and flair."
Sanjai Murali, Founder & CEO, JOGO Health · Recommendation

Case study 06

TJS: a speech therapy clinic platform

Context & problem

Objective: one workspace for a speech diagnostics department, a speech therapy department and university clinics where supervisors allot cases to students.

Challenge: the work passes through several roles and handoffs, and it holds sensitive health data about children and vulnerable adults, so privacy had to be designed in from the start.

Approach

  • Mapped the workflow from my clinical experience: register and assess, refer to therapy, allot to a therapist or student, then supervisor review of lesson plans and reports.
  • Defined who sees what: supervisors, diagnosticians, therapists and students each see only what their role needs.
  • Designed consent per purpose: nothing pre-ticked, five languages, an accessible mode, a tamper-evident record, and withdrawal that takes effect at once.
  • Built for the strictest law first: GDPR and India's DPDP Act, with a country setting for each clinic.
  • Delivered in small releases: from a session planner to the full clinic workflow, each step tested before the next.
  • Prepared for expert review: draft privacy notice, consent forms, risk assessment and questions for a lawyer.
The clinic workflow
  1. Register & consent
  2. Assessment
  3. Refer to therapy
  4. Allot
  5. Sessions & reports
  6. Supervisor review

Results

  • Live: an installable web app with a full demo clinic, published online.
  • Open source: licensed so it stays open, with my name kept on every copy.
  • Ready for review: automated tests, a security plan and legal drafts for a lawyer.

Challenges

ChallengeHow we overcame it
Showing the app to clinics without risking real patient dataSeparated a demo with fake patients from the clinic workspace, which starts empty and requires encryption before any patient is added
One clinic, many computers: staff and students working from the clinic, home and universityCompared nine ways to connect them and chose one clinic computer reached over a private network (VPN)
Different laws in each countryBuilt to the strictest rules, then added a country setting for the law, the complaints authority and the consent options

Risks

RiskHow we overcame it
Records seen by staff who don't need themRole-based access checked by the clinic server, plus an access log for supervisors
Consent that isn't valid: wrong person, pre-ticked, or in a language the family doesn't understandConsent recorded per purpose with who gave it, their relationship, the language and the notice version
Erased patients still readable in old backupsEach patient has their own encryption key, destroyed on erasure, with a deletion receipt
Bugs in AI-assisted codeAutomated tests now, and an independent security review planned before real patient data

Lessons learned

  • Domain knowledge sets the requirements. My clinical experience defined the workflow; AI sped up the build.
  • Design for the strictest rules first. Adapting down to a lighter law is easier than adding privacy later.
  • State the limits plainly. Clear notes on what still needs a lawyer or a security review build more trust than overclaiming.

Case study 07 · Supporting

Clinical research

Context & problem

Objective: produce reliable, publishable evidence in audiology and speech-language pathology.

Challenge: clinical studies mean many data points, repeated follow-ups and no room for gaps.

Approach

  • Region Örebro län (Sep 2023 – Sep 2024): research assistant. Data entry and management, statistical analysis, research writing and source referencing for a peer-reviewed article.
  • Lund University (2022): a systematic review of cognition and vestibular function in children with hearing loss.
  • Master's thesis, Bangalore University (2018 – 2019): three clinical studies following 15 to 35 child participants with cochlear implants over 12 months, coordinating data collection across multiple follow-up points.
  • Undergraduate project (2016): a team of three asking whether objective measures can be used for MAPping (programming) cochlear implants in children.
Research path
  1. Undergraduate project
  2. Master's thesis
  3. Systematic review
  4. Peer-reviewed publication

Results

  • Published (Region Örebro län): a peer-reviewed article in the International Journal of Audiology (2025): the Swedish version of the Hearing and Functioning in Everyday Life Questionnaire (HFEQ).
  • Awarded 2nd prize at a state-level conference: presented our team paper on objective measures for cochlear implant MAPping in children at the 7th TAN-ISHA CON (Nov 2016), the state conference of the Tamil Nadu branch of the Indian Speech and Hearing Association, and won 2nd prize.

Challenges

ChallengeHow we overcame it
Participants dropped out or missed follow-ups over 12 monthsIntroduced rewards for participants so they kept coming back to the final follow-up
Statistical analysis gave unexpected resultsChanged the analysis strategy and reran it until the results could support a conclusion

Risks

RiskHow we overcame it
Too few participants left at the final follow-up for valid resultsRewards to keep participants cooperating to the end
Unexpected results leaving the thesis without a usable conclusionRevised the analysis strategy and reran it

Lessons learned

  • Budget for retention up front. Participant rewards were not in the plan, and I ended up paying for them myself.
  • Plan for drop-outs. Recruit more participants than the minimum needed for valid results.
  • Agree an analysis plan with a fallback. Knowing in advance what to do if results are unexpected saves repeated reanalysis.
  • Build buffer into the timeline. Reanalysis and drop-outs were absorbed through overtime; a buffer would have absorbed them instead.

Project appreciation

  • 2nd prize at the 7th TAN-ISHA CON (2016), a state-level conference of the Indian Speech and Hearing Association.
  • Peer-reviewed publication in the International Journal of Audiology (2025).

See how I work

My approach Experience & skills