DEV Community: Mariyam Gadhawala

PHP2Shell Is a Wake-Up Call: Why Strapi + Next.js Deserves a Serious Look

Mariyam Gadhawala — Fri, 23 Oct 2026 13:43:08 +0000

The recent PHP2Shell vulnerabilities have put a spotlight on a problem businesses often overlook: the long-term security and maintainability of their website architecture.

On October 21, 2026, two critical vulnerabilities in the PHP runtime were disclosed that could allow unauthenticated remote code execution on affected servers. The incident has reinforced the importance of keeping web infrastructure patched and reviewing how applications expose their backend systems.

For businesses running WordPress or other PHP-based platforms, this is a good opportunity to consider whether a headless architecture would better fit their needs.

Why Consider Strapi + Next.js?

Traditional WordPress combines content management and website presentation in one platform. That simplicity is useful, but businesses with growing integration requirements or custom frontend needs may benefit from separating these responsibilities.

With Strapi + Next.js:

Strapi manages structured content and exposes it through APIs.
Next.js delivers the frontend with flexible rendering and caching options.
Decoupled architecture allows teams to develop the frontend independently of the CMS.
API-driven delivery makes it easier to reuse content across websites and other applications.

This makes Strapi + Next.js a compelling alternative for businesses that need more control over their digital experiences than a traditional CMS setup provides.

Does Moving Away From PHP Solve Security Problems?

Not automatically. A headless CMS still requires security updates, protected APIs, appropriate permissions, and secure hosting. However, separating the public-facing frontend from the CMS administration layer can reduce certain exposure risks when implemented correctly.

For existing WordPress websites, the decision should go beyond the latest security headline. Businesses should consider whether their current architecture is difficult to maintain, limits custom functionality, or creates unnecessary dependencies.

When Is Migration Worth It?

If a business needs a straightforward blog, WordPress may remain sufficient. But when complex integrations, custom user experiences, multi-channel content delivery, and independent frontend development become priorities, Strapi + Next.js can provide a more adaptable foundation.

The recent PHP security disclosures make this evaluation timely, particularly for organizations maintaining older or difficult-to-update infrastructure. They do not, however, make WordPress-to-Strapi migration mandatory.

For teams planning a transition, a Strapi developer can help assess content models, API requirements, migration risks, and the right Next.js implementation before the rebuild begins.

The takeaway: Don't migrate simply because a vulnerability makes headlines. Migrate when your business needs a more flexible architecture, and use the current security discussion as a reason to evaluate whether your existing stack is still the right fit.

What Can Product Teams Learn From Careem's Shift From Ride-Hailing to an Everything App?

Mariyam Gadhawala — Thu, 24 Sep 2026 12:21:16 +0000

Careem's evolution from a ride-hailing tool into a multi-service "everything app" offers a masterclass in platform scaling, retention strategy, and hyperlocal product design. The transition wasn't about adding random features, it was about systematically leveraging shared infrastructure, unified customer identity, and deep regional understanding to create compounding value across services.

For product teams navigating similar transitions, Careem's playbook reveals five critical lessons that extend far beyond the Middle East market.

1. Start with a Trojan Horse, Not a Shopping Mall

The biggest mistake product teams make when building multi-service platforms is launching with 10+ features on Day 1. Careem's approach was fundamentally different.

The Strategy:
Start with a high-frequency, trusted core service that naturally acquires users. For Careem, this was ride-hailing, a daily need with clear value proposition. Only after achieving strong market position in rides did they layer on food delivery, groceries, and fintech.

Why This Works:
Natural acquisition: Users download the app for one clear reason (booking a cab)

Trust building: Reliable core service creates brand loyalty for future expansions

Behavioral data: Ride patterns reveal lifestyle insights (gym, office, restaurants) for personalization

Lower CAC: Acquiring users for one service is cheaper than marketing 10 services simultaneously

The Metric That Matters:
Industry benchmarks suggest significant cross-service adoption within 90 days in mature super app ecosystems. If cross-service adoption is low, the expansion strategy needs rethinking.

For Product Teams:
Don't ask: "What features should we launch with?"

Ask: "What single service can we dominate so thoroughly that users trust us with everything else?"

2. Shared Infrastructure Is the Real Moat

The strongest argument for the everything-app model isn't that users can access more services from one app. It's that multiple businesses can share the same underlying infrastructure.

The real moat isn't the number of services. It's the number of services that can reuse the same primitives.

What Gets Shared:

The Compounding Effect:

More services
→ More transactions
→ More behavioral data
→ Better personalization
→ Higher engagement
→ Lower friction for launching the next service

This creates a structural advantage that standalone apps can't replicate without massive capital investment.

The Challenge:

However, every additional vertical also increases:
Operational complexity (different supply chains, workflows)
Regulatory exposure (food safety, financial licensing, labor laws)
Failure modes (more services = more things that can break)

The Solution:
Build strong shared primitives while keeping individual business domains independently scalable:

Shared Infrastructure:

Identity & authentication
Payments & wallet
Location & mapping
Notifications (push, SMS, email)
Experimentation platform (A/B testing)
Trust & safety (fraud detection, content moderation)
Observability (monitoring, logging, alerting)
Customer support systems
Dispatch/logistics engines
Data/ML pipelines

Independent Business Domains:

Rides (own P&L, own metrics)
Food (own P&L, own metrics)
Groceries (own P&L, own metrics)
Fintech (own P&L, own metrics)

This balance allows the platform to scale horizontally (more services) while maintaining operational focus within each vertical.

For Product Teams:

When considering a new vertical, ask:

"What existing infrastructure can this service reuse?"
"Does this share customers, payments, logistics, or supply with existing services?"
"Or does it require an entirely separate operating model?"

If a new vertical requires building everything from scratch with little cross-service leverage, the everything-app thesis becomes harder to justify.

3. Hyperlocal Customization Beats Imported Playbooks

Unlike global tech platforms that roll out rigid, identical features across all borders, Careem won market share by designing features specifically tailored to regional nuances in the MENA region.

What "Hyperlocal" Actually Means:

It's not just translating the app into Arabic. It's designing workflows that reflect how people actually live in the region.

Careem's Local Adaptations:

The Lesson:
Geographic scaling requires deliberate local empathy and custom workflows, not just translated text.

For Product Teams:

Before expanding to a new market, spend 2-4 weeks on the ground:

Observe how people actually use your product
Identify friction points that global playbooks miss
Talk to customers in their native language
Understand payment preferences, cultural norms, regulatory constraints

Then adapt your product, not just your marketing.

4. Unified Subscriptions Create Retention Flywheels

A major risk for everything-apps is cognitive overload—users getting confused by too many choices. Careem solved this by unifying their ecosystem under a single loyalty and subscription program: Careem Plus.

- Careem Plus Structure:

Price: Monthly subscription fee
Benefits:
Free delivery on food and groceries
Ride discounts
Instant cashback on payments
Priority support

Why It Works:

Reduces friction: Users don't decide per-order whether to pay for delivery
Locks in ecosystem: Canceling means losing benefits across all services
Predictable revenue: Recurring subscription income independent of transaction volume
Higher LTV: Subscribers show significantly higher lifetime value than non-subscribers

The Flywheel Effect:

User subscribes to Careem Plus

→ Uses more services to "get value" from subscription

→ Generates more transaction data

→ Receives better personalization

→ Becomes more engaged

→ Less likely to churn

→ More likely to try new services

For Product Teams:

If you're building a multi-service platform, consider:

Bundled subscriptions: One fee for access to multiple services
Cross-service rewards: Points earned in one vertical redeemable in others
Tiered loyalty: Bronze/Silver/Gold based on total ecosystem spend (not just one service)

The goal is to transform single-intent transactional users into multi-service daily active users.

5. Intent-Driven Navigation Prevents Feature Fatigue

When an app transitions from a direct tool ("tap to call a car") into a marketplace of 15+ services, the UI can quickly become cluttered. Careem underwent significant design system evolution to prevent feature fatigue.

The Problem:
Traditional super app home screens look like this:

This "icon graveyard" overwhelms users and reduces discoverability.

Careem's Solution:
Intent-driven navigation centered around user needs, not service categories:

The Design Principles:

Group by intent, not service: Users think "I need to eat" not "I need food delivery"
Dynamic surfacing: Show relevant services based on time, location, past behavior
Progressive disclosure: Don't show all 15 services at once—reveal as user explores
Consistent patterns: Same booking flow, same payment experience, same support across all verticals

For Product Teams:

When designing multi-service navigation:

Map user intents: What problems are users trying to solve? (not what services do you offer?)
Test icon overload: If users can't find key services in 5 seconds, simplify
Use data to prioritize: Surface high-frequency services prominently, hide niche services in secondary menus
Maintain consistency: Same design system, same interaction patterns across all verticals

The goal is discoverability without visual exhaustion.

6. Measure the Ecosystem, Not Just the Vertical

One of the hardest product questions in a multi-service platform is deciding whether a new service is creating incremental value or simply shifting existing transactions around.

A new vertical should therefore be measured at two levels:

Vertical Metrics:

Conversion rates
Retention (Day 1, Day 7, Day 30)
Contribution margin
Order frequency
CAC and LTV for the vertical

Ecosystem Metrics:

Cross-service adoption rate
Incremental transactions per user (not just shifted transactions)
Shared customer retention (do multi-service users churn less?)
Cost to serve (does this vertical increase or decrease overall support costs?)
Payment and infrastructure reuse (what percentage of existing infrastructure does this leverage?)
Change in overall customer lifetime value

The Critical Question:
A service can look successful on its own while making the overall platform worse if it adds operational complexity without increasing customer value.

The important question isn't simply:

"Is this service growing?"

It's:

"Is this service making the entire ecosystem more valuable?"

For Product Teams:

Before launching a new vertical, define:
Success metrics at vertical level: What does "good" look like for this service alone?
Success metrics at ecosystem level: How will we know this service strengthens the overall platform?
Cannibalization checks: Are we just shifting transactions from existing services, or creating incremental value?
Infrastructure leverage: What percentage of existing infrastructure (identity, payments, logistics, support) does this reuse?

If a service performs well on vertical metrics but poorly on ecosystem metrics, it may be adding complexity without creating real value.

Where the Model Breaks: Knowing What NOT to Build

More services do not automatically create more value.

A super app can become difficult to operate when every new vertical introduces its own supply chain, regulatory requirements, support workflows, unit economics, and failure modes.

Good Expansion (Shares Infrastructure):

Grocery delivery: Uses same Captain network, same payment system, same app
Fintech: Uses same user base, same identity layer, same trust relationship
Food delivery: Uses same location infrastructure, same dispatch algorithm, same wallet

Harder-to-Justify Expansion:

Services where customer behavior, supply infrastructure, regulatory requirements, and economics have little overlap with the existing ecosystem.

Examples might include:

Services requiring entirely different supply chains with no logistics overlap
Verticals with fundamentally different customer behavior patterns (e.g., infrequent, high-value transactions vs. frequent, low-value)
Categories with heavy, specialized regulation that doesn't leverage existing compliance infrastructure

The Litmus Test:
If a new vertical shares customers, payments, logistics, identity, or supply with existing services, it can strengthen the ecosystem.

If it requires an entirely separate operating model with little cross-service leverage, the everything-app thesis becomes much harder to justify.

That distinction is what separates ecosystem expansion from simply adding more icons to an app.

Practical Takeaways for Product Teams

If You're Scaling a Single Vertical:

Prove repeatable product-market fit first: Don't expand simply because adjacent services are available. Expand when the core service has strong retention, reliable operations, and a clear path to sustainable unit economics.
Build reusable infrastructure: Design APIs, data models, and workflows that future services can leverage
Collect behavioral data: Use core service interactions to understand user preferences for future personalization

If You're Planning Multi-App Consolidation:

Unify identity first: Single login across all apps before merging into one super app
Standardize payments: Same wallet, same payment methods, same checkout experience
Create cross-service rewards: Points earned in one app redeemable in others

If You're Focusing on Regional Expansion:

Spend time on the ground: 2-4 weeks observing local behavior before launching
Adapt payment methods: Cash, local cards, mobile wallets vary by market
Design for local language: Arabic-first UX, not just translated English
Respect cultural norms: Women-only options, religious period features, local holidays

The Bottom Line

Careem's shift from ride-hailing to everything-app wasn't about copying WeChat or Grab. It was about systematically leveraging shared infrastructure, unified customer identity, and deep regional understanding to create compounding value across services.

For Product Teams:
The question isn't "Should I build an everything-app?" but:

"What single service can we dominate so thoroughly that users trust us with everything else?"
"What existing infrastructure can new services reuse?"
"How do we design for local realities, not imported playbooks?"
"How do we bundle services to create retention flywheels?"
"How do we prevent feature fatigue while maintaining discoverability?"
"How do we measure ecosystem value, not just vertical performance?"

Careem's journey offers a masterclass in what works, what doesn't, and what to prioritize in 2026 and beyond.

How Does Memory Architecture Work in AI Girlfriend Apps?

Mariyam Gadhawala — Thu, 17 Sep 2026 07:45:18 +0000

The interesting part isn't making an AI girlfriend app remember something.

It's deciding what is worth remembering in the first place.

If every conversation were pushed into a vector database and retrieved later, the system would eventually become noisy, expensive, and surprisingly bad at personalization.

A better memory architecture treats memory as a pipeline.

But there is an important layer missing from many simplified architectures:

forgetting and updating.
Imagine a user says:

“I love coffee.”

Six months later:

“I've stopped drinking coffee.”
A system that only stores facts has two memories.

A system designed for long-term interaction needs to understand that the second statement updates the first.

What should an AI girlfriend app actually remember?

Not every message deserves permanent storage.

A practical architecture can separate memory into different categories:

1. Working memory

Recent conversation turns used to maintain immediate context.

2. Semantic memory

Stable facts such as preferences, interests, names, routines, or recurring topics.

3. Episodic memory

Specific past events: “We talked about your exam last Tuesday.”

4. Relationship state

Longitudinal signals such as conversation patterns, recurring interests, or interaction history.

5. Expiring memory

Temporary information that should disappear or become irrelevant after a defined period.

This distinction matters because “remember everything” is not the same as “understand what matters.”

Research on AI memory increasingly treats consolidation, updating, indexing, forgetting, retrieval, and compression as separate memory operations.

How does retrieval work?

Suppose a user says:

“I'm nervous about tomorrow.”

The system shouldn't retrieve 500 old messages.

It might retrieve:

• a previous conversation about the same event
• the user's relevant preference
• a recent related interaction
• the latest relationship context

Then rank those memories by relevance, recency, confidence, and context before sending only the useful information to the model.

That is closer to how production memory systems need to work than simply “store embeddings and search them.”

Recent research on persistent AI agents is also exploring retrieval strategies that preserve conversational episodes rather than relying entirely on lossy memory extraction.

And then comes the part that is easy to underestimate: privacy.

AI girlfriend apps can accumulate unusually personal information because users may disclose things they wouldn't normally tell a conventional chatbot.

That creates a different engineering question:

Should the system remember something just because it can?

Probably not.

Memory architecture should include:

Consent → collection rules → classification → retention policy → encryption/access control → user visibility → correction/deletion

A user should ideally be able to understand what the system remembers, why it remembers it, and how to remove or correct it.

That isn't just a UX feature. It's an architectural requirement.

NIST's privacy guidance emphasizes data minimization, while its Generative AI Risk Management Profile treats privacy, security, reliability, and lifecycle risk as part of trustworthy AI development.

Where AI girlfriend apps are heading

The next generation of companion apps won't compete only on larger models or more realistic avatars.

The bigger differentiator may be memory quality:

1. How accurately does the system remember?

2. How quickly does it update outdated information?

3. When does it intentionally forget?

4. Can it distinguish an important event from casual conversation?

5. Can users control that memory?

That changes the architecture from:

LLM + chatbot + database
to something closer to:

LLM + memory orchestration + retrieval + personalization + privacy controls + evaluation

And that's a much more interesting engineering problem.

The future of AI companions may not depend on making AI remember everything.

It may depend on teaching AI what not to remember.

When should you build an AI agent instead of a workflow?

Mariyam Gadhawala — Thu, 27 Aug 2026 09:51:23 +0000

This sounds like an architecture question, but it’s really a product decision.

A common mistake is to make an LLM “agentic” simply because the technology allows it.

If the process is predictable, a workflow is often better:

Input → validation → retrieval → business logic → action → approval

You get clearer failure modes, easier testing, predictable costs, and better control.

An AI agent becomes more useful when the path cannot be completely predefined, for example, when the system needs to decide which tools to use, what information to retrieve, or what sequence of actions will solve the task.

Anthropic makes a similar distinction between workflows, where the application controls the process, and agents, where the model dynamically directs its own tool use.

How do you decide?

Ask these questions before adding agentic complexity:

How predictable is the task?
If 90% of requests follow the same path, start with a workflow.
When does the system need to make decisions?
If it genuinely needs to choose between tools, data sources, or approaches, an agent may make sense.
Which actions can the model execute?
Don't give an agent broad access just because an API exists.

OWASP's 2025 LLM guidance specifically highlights Excessive Agency: unexpected or manipulated model outputs can cause damaging actions when systems give LLMs too much authority.

How will you evaluate it? “Looks good in testing” isn't enough.

Track things like:

task success rate
tool-call accuracy
retrieval quality
hallucination/error rate
latency
cost per task
human escalation rate

What happens when it fails? A production AI system needs an explicit failure path — retry, fallback model, human approval, or safe termination.

NIST's Generative AI Profile also treats risk management as something that should span the AI lifecycle rather than being added after deployment.

The practical rule

Use a workflow when you know the path.
Use an agent when the system genuinely needs to determine the path.

More autonomy doesn't automatically mean a better AI product.

Sometimes the most technically mature decision is not to use an agent.

That distinction matters when moving from an AI demo to something people can actually depend on.

Useful references:
Anthropic — Building Effective AI Agents
OWASP — LLM & GenAI Security Risks
NIST — Generative AI Risk Management Profile

AIAgents #AgenticAI #AIEngineering #LLM #RAG #SoftwareArchitecture #DevCommunity