How much of your work is actually WordPress?

Roughly 40 to 45%. It is the area I am known for and the one I go deepest in - Gutenberg and ACF block architecture, custom plugins and themes, WooCommerce, REST and GraphQL APIs, WP-CLI tooling, security hardening and VIP compliance. The remaining 55 to 60% is React and Next.js, AI engineering, commerce, SaaS, automation and infrastructure.

What does "clean architecture" mean on a real project?

Concretely: business logic that does not live in a template, a plugin layer that can be deployed without touching the theme, integrations that fail loudly with retries rather than silently swallowing errors, and boundaries clear enough that a new developer can change one feature without reading the whole codebase. It is a maintenance property, not an aesthetic one.

Do you take over existing codebases or only greenfield builds?

Mostly existing ones. Inherited platforms are where the interesting constraints are - you cannot redesign your way out, you have to understand why the current shape exists before changing it. Greenfield work happens too, but rescue and re-architecture is the more common brief.

How do you decide what to fix first on a slow platform?

Measure before touching anything. Query profiling and object-cache hit rates first, because a template that issues 400 queries will not be saved by asset optimisation. Then rendering strategy and cache layers, then front-end payload. The order matters: front-end work on top of an unprofiled backend produces numbers that regress the moment traffic changes.

Do you work solo or inside a team?

Both. Solo on audits, architecture design and focused engineering work; embedded inside client engineering teams for longer platform builds, where the work includes code review, mentoring and writing down the patterns so they survive after I leave.

About Praful Patel | Software Engineer & AI Architect

Short answer

Who is Praful Patel?

Praful Patel is an All-in-One Full-Stack Web Developer and AI Solutions Engineer based in Ahmedabad, India. His expertise spans modern JavaScript/TypeScript (React, Next.js, Node.js), Python & AI/LLM integration (OpenAI API, Anthropic Claude, RAG architectures, vector search, AI agents), workflow automation (n8n, Make.com), e-commerce platforms (Shopify, WooCommerce), enterprise CMS solutions (WordPress, Contentstack, HubSpot), REST/GraphQL APIs, and cloud infrastructure.

Primary focus: Full-Stack Web Development & AI Solutions
Tech Stack: React & Next.js, Node.js, Python, TypeScript, AI/LLMs
AI & Automation: AI Agents, RAG Pipelines, Vector Search, n8n, Make.com
CMS & Commerce: WordPress, Headless CMS, Shopify, WooCommerce
Community: WordCamp Organiser (2023, 2025, 2026)

04 Philosophy

Engineering philosophy

The principles that decide how a system is built, long before a framework does.

Clean architecture

Boundaries first. A module should be describable in one sentence, and replaceable without a rewrite.

Scalability

Design for the second year of traffic and features, not the launch demo. Growth should be a configuration change.

Performance

Measure, then remove work. Query budgets, cache boundaries, and Core Web Vitals beat opinions every time.

Security

Escaping, sanitisation, capability checks, and least privilege are defaults – not findings raised in review.

Maintainability

The next engineer is the primary user of the codebase. Clarity outranks cleverness, always.

Accessibility

Semantic markup, keyboard-complete flows, and real assistive-technology testing rather than an overlay script.

Standards

Coding standards and static analysis encoded as tooling, so review can be about design instead of formatting.

Automation

If a rule can be checked by a machine, it should be. CI/CD gates protect quality when attention runs out.

Developer experience

Fast local setup, honest error messages, and documentation written once so the same question is not answered twice.

Read the full story →

About the work, answered directly

How much of your work is actually WordPress?: Roughly 40 to 45%. It is the area I am known for and the one I go deepest in – Gutenberg and ACF block architecture, custom plugins and themes, WooCommerce, REST and GraphQL APIs, WP-CLI tooling, security hardening and VIP compliance. The remaining 55 to 60% is React and Next.js, AI engineering, commerce, SaaS, automation and infrastructure.
What does "clean architecture" mean on a real project?: Concretely: business logic that does not live in a template, a plugin layer that can be deployed without touching the theme, integrations that fail loudly with retries rather than silently swallowing errors, and boundaries clear enough that a new developer can change one feature without reading the whole codebase. It is a maintenance property, not an aesthetic one.
Do you take over existing codebases or only greenfield builds?: Mostly existing ones. Inherited platforms are where the interesting constraints are – you cannot redesign your way out, you have to understand why the current shape exists before changing it. Greenfield work happens too, but rescue and re-architecture is the more common brief.
How do you decide what to fix first on a slow platform?: Measure before touching anything. Query profiling and object-cache hit rates first, because a template that issues 400 queries will not be saved by asset optimisation. Then rendering strategy and cache layers, then front-end payload. The order matters: front-end work on top of an unprofiled backend produces numbers that regress the moment traffic changes.
Do you work solo or inside a team?: Both. Solo on audits, architecture design and focused engineering work; embedded inside client engineering teams for longer platform builds, where the work includes code review, mentoring and writing down the patterns so they survive after I leave.