Forem: Kunal Pareek

How I Submitted My First WordPress Core Patch (And What I Learned)

Kunal Pareek — Sun, 17 May 2026 20:26:45 +0000

I always assumed contributing to WordPress core was for people with decades of open source experience. Senior engineers. People whose names you recognize in commit logs.

Turns out I was wrong. I submitted my first patch this week and the process was more straightforward than I expected. Not easy — but straightforward. Here is exactly what I did.

Finding a ticket worth working on

The first thing I learned is that most open tickets on Trac are not actually patchable. Either someone recently said they cannot reproduce the bug, or the fix requires a design decision that core committers have not agreed on yet, or the ticket is so old nobody cares anymore.

I filtered Trac for:

Status: new
Keywords: needs-patch
Component: REST API
Type: defect (bug)

I looked at three tickets before finding one worth touching. The first two had recent comments saying the bug could not be reproduced. I walked away from both immediately. Never spend time on a ticket where someone recently said "can't reproduce" — it is a dead end.

The ticket I picked

I landed on #48257. The bug was a REST API discoverability problem in the media upload endpoint.

When you POST to /wp/v2/media and the server runs out of resources mid-upload during image sub-size generation, WordPress sends an X-WP-Upload-Attachment-ID header back to the client. This tells the client the attachment ID so it can retry via the /post-process endpoint.

The problem is that WordPress never sent a Link header pointing to where that post-process endpoint actually lives. So REST clients had no standard way to discover it. They had to hardcode or guess the URL which is fragile and goes against REST API principles.

The ticket had been open since WordPress 5.3. Zero pull requests. Four years untouched.

Reading the code before writing anything

Before writing a single line I cloned WordPress develop:

git clone https://github.com/WordPress/wordpress-develop.git
cd wordpress-develop

Then I opened src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php and searched for X-WP-Upload-Attachment-ID.

Here is what I found. The raw header() call happens very early in create_item() before the $response object even exists. This is intentional. If the server fatals during wp_update_attachment_metadata() the client still gets the attachment ID from that header and can recover.

But the Link header does not need to go out at that same moment. It can be added to $response after the response object is constructed, right next to where the Location header is already being set. No order-of-operations problem at all.

The actual fix

After the Location header I added this:

/*
 * Add a Link header pointing to the post-process endpoint so REST clients
 * can formally discover it and resume image sub-size generation if the
 * initial upload processing fails due to a server error.
 *
 * @since 6.8.0
 */
$response->add_link(
    'https://api.w.org/action-post-process',
    rest_url( sprintf( '%s/%s/%d/post-process', $this->namespace, $this->rest_base, $attachment_id ) ),
    array( 'embeddable' => false )
);

One thing I want to explain here is the relation type. The original ticket suggested using edit-media as the link relation. But edit-media is already used by the /edit endpoint in the same controller. Using it for post-processing would be semantically wrong and would confuse clients that rely on relation types having consistent meaning. The api.w.org/action-* pattern is what core uses for action links so I followed that instead.

Generating the patch file

git diff src/wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php > 48257.patch

I ran cat 48257.patch to verify only my intended lines changed before uploading anything.

Writing the Trac comment

This is the part most people underestimate. The comment you write on the ticket is evaluated just as seriously as the code itself.

I explained what I understood the bug to be, why the order-of-operations issue is still present in trunk, why my approach works without hitting that issue, why I chose a different relation type than the one suggested, and what feedback I was looking for from core contributors.

That written explanation took me longer than the code change itself. But if you just upload a patch with no context you are making the reviewer do all the work of figuring out your reasoning. Most of the time they won't bother.

What I took away from this

Read the full ticket history including linked tickets before writing anything. The real context is almost always buried in the comments not the description.

Comment on the ticket before writing code. Post your intended approach and ask if it makes sense. This protects you from spending hours going in the wrong direction.

Small focused patches move faster. My patch changes 13 lines in one file. A reviewer can evaluate it in a few minutes.

The writing matters as much as the code. Your comment is a signal about how you think and communicate. For a distributed team that works async this is arguably more important than the code quality itself.

How to find your first ticket

Start here:

https://core.trac.wordpress.org/query?status=new&keywords=~needs-patch&component=REST+API&type=defect+%28bug%29

Sort by modified date descending. Look for tickets with zero pull requests and a clearly reproducible bug. Skip anything with recent "can't reproduce" comments or active disagreement between core committers about the right fix.

Pick something small. Read everything. Comment before you code. Write like you care about the reasoning not just the result.

That is genuinely the whole process.

How AI Changed My Development Workflow Without Replacing Engineering Thinking

Kunal Pareek — Sat, 16 May 2026 17:12:54 +0000

AI has significantly changed how I approach day to day development, mainly by reducing iteration time and helping me explore multiple implementation approaches faster.

I do not really use AI as a replacement for engineering decisions.

I use it more as an acceleration tool.

Most of my work involves moving between different parts of the stack:

frontend systems
APIs
backend logic
WordPress plugins
React and Next.js applications
automation workflows
debugging production issues

Switching contexts constantly can slow development down, especially in larger systems.

AI became useful because it reduces some of that friction.

For example, when working with React or Next.js applications, I often use AI to:

generate initial boilerplate
explore multiple component structures
validate implementation ideas
simplify repetitive setup work
quickly test alternative approaches

In backend workflows, it helps me move faster while working with:

REST APIs
request validation
database queries
automation systems
integration logic

One thing I found especially useful is debugging assistance.

Earlier, debugging often meant searching across documentation, GitHub issues, Stack Overflow threads, and multiple unrelated discussions just to narrow down possibilities.

Now AI helps reduce that search time significantly.

It becomes easier to:

identify likely causes
test hypotheses faster
compare implementation patterns
isolate edge cases
reason through unfamiliar systems

That said, I became equally careful about when not to rely on AI.

I still prefer thinking through:

architecture decisions
system design
plugin structure
scalability concerns
performance optimization
maintainability tradeoffs

using my own understanding first.

Especially in long term systems, maintainability matters much more than simply generating code quickly.

One thing that helped me here was building systems before AI tooling became part of my workflow.

Working deeply with:

WordPress plugins
frontend systems
APIs
production debugging
client workflows
maintainable architectures

forced me to understand how things work underneath the abstraction layers.

That foundation changed how I use AI today.

Instead of blindly accepting outputs, I usually:

validate implementation logic
review edge cases
simplify generated code
remove unnecessary complexity
adapt solutions to fit existing architecture

because generated code that technically works is not always production friendly.

I also noticed that AI works best when the developer already understands the problem clearly.

The quality of output depends heavily on:

context
engineering judgment
architectural understanding
ability to evaluate tradeoffs

Without that, it becomes very easy to generate fragile systems quickly.

Another thing AI improved for me is experimentation.

It is much easier now to:

prototype ideas
compare approaches
test unfamiliar libraries
explore architecture patterns
understand implementation tradeoffs

without spending hours setting up everything manually first.

That speeds up learning significantly.

At the same time, AI also reinforced something important for me:
strong engineering fundamentals matter even more now.

Because once code generation becomes easier, the harder problems become:

system design
maintainability
debugging
scalability
communication
architecture clarity
developer experience

Those are still deeply human engineering problems.

Overall, AI made me faster and more efficient, but it also made me value foundational understanding much more.

Knowing:

when to trust AI
when to question it
when to simplify generated solutions
and when to rely completely on your own reasoning

became an important engineering skill on its own.

Improving Plugin Developer Workflows in WordPress Projects

Kunal Pareek — Sat, 16 May 2026 17:07:48 +0000

Over the years, one thing I have noticed while building WordPress plugins is that development speed is rarely limited by coding itself.

Most of the time gets consumed by repetitive workflows.

Refreshing local environments.

Testing plugin activation repeatedly.

Switching between admin panels and code editors.

Manually clearing caches.

Rebuilding assets for small UI changes.

Debugging conflicts between plugins.

Setting up the same boilerplate structure again and again.

As projects grow, these small interruptions slowly reduce development quality and focus.

This article is about some practical workflow improvements that helped me build plugins more consistently and maintain them with less friction over time.

The Real Problem Is Context Switching

In many WordPress projects, developers constantly move between:

wp-admin
terminal
browser devtools
API testing tools
database tools
frontend build systems

That context switching becomes exhausting in larger projects.

I started realizing that improving developer workflow was not just about speed. It was about reducing mental overhead.

Good workflows make developers think more about systems and less about repetitive setup tasks.

Standardizing Plugin Structure Early

One mistake I made in older plugins was treating every project differently.

Different folder structures.

Different naming patterns.

Different initialization methods.

This becomes difficult to maintain after a few projects.

Now I try to keep a consistent structure across plugins:

plugin/
├── admin/
├── frontend/
├── includes/
├── assets/
├── templates/
├── languages/
├── build/
└── plugin.php

Even small consistency improvements help when returning to projects months later.

It also makes onboarding easier if another developer joins the project.

Separating Logic From Hooks

Earlier, I used to place too much logic directly inside WordPress hooks.

Example:

add_action('init', function () {
    // large logic block
});

This works initially but becomes difficult to debug and test later.

Now I prefer keeping hooks lightweight and moving actual logic into dedicated classes or services.

Example:

add_action('init', [Plugin_Bootstrap::class, 'init']);

Then the internal system handles responsibilities separately.

This small shift improves readability and long term maintainability significantly.

Using Local Development Environments Properly

For a long time I underestimated local environments.

I used shared staging environments for plugin development which created multiple problems:

inconsistent debugging
plugin conflicts
slow iteration
unstable testing

Moving to proper local WordPress setups improved development speed immediately.

Especially for:

database resets
plugin testing
API debugging
Gutenberg experiments
frontend asset rebuilding

Now I treat local setup as part of the engineering workflow itself.

Automating Repetitive Tasks

One of the biggest workflow improvements came from automating small repetitive tasks.

Examples:

automatic asset builds
plugin packaging
linting
formatting
environment setup
deployment preparation

Even basic npm scripts help a lot.

Example:

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "lint": "eslint ."
  }
}

The goal is not complexity.

The goal is reducing manual repetition.

Better Debugging Improves Development Speed

A surprising amount of plugin development time goes into debugging.

Especially:

hooks firing unexpectedly
AJAX failures
REST API permission issues
plugin conflicts
caching problems

I started improving debugging by:

using clearer logging
isolating plugin features
reducing hidden dependencies
organizing hooks properly
documenting critical flows

The cleaner the internal system becomes, the easier debugging gets later.

Documentation Is Part of the Workflow

I used to think documentation was something written after development.

Now I see it differently.

Good documentation improves development itself.

Especially in async environments.

Even simple things help:

folder explanations
API notes
setup instructions
hook references
architecture decisions

When returning to a project after months, documentation saves enormous time.

This becomes even more important in distributed teams.

Frontend Tooling Changed Plugin Development

Modern frontend tooling has improved WordPress plugin workflows significantly.

Using:

React
Vite
TypeScript
modular components

makes plugin admin interfaces much easier to scale.

At the same time, WordPress still teaches important lessons about backward compatibility, extensibility, and long term maintenance.

I think combining modern frontend workflows with WordPress architecture creates very strong engineering foundations.

Open Source Changed How I Think About Systems

Publishing code publicly changes development habits.

You naturally start:

organizing code better
documenting decisions
reducing shortcuts
improving readability
thinking about maintainability

Even small open source projects encourage better engineering discipline.

That mindset has influenced how I approach plugin systems today.

Final Thoughts

Improving developer workflows is not about chasing productivity trends.

It is about building systems that reduce friction over time.

The longer a project lives, the more important maintainability becomes.

Small workflow improvements compound:

cleaner structure
better tooling
reusable patterns
documentation
automation
reduced repetition

WordPress development taught me that sustainable systems matter more than fast temporary solutions.

And in long term engineering work, reducing friction is often more valuable than adding complexity.

What Years of WordPress Development Taught Me About Modern Frontend Systems

Kunal Pareek — Sat, 16 May 2026 13:18:37 +0000

A large part of my frontend experience started inside WordPress.

Themes, plugins, hooks, custom dashboards, admin workflows, template overrides, API integrations, and client driven systems were part of my daily work for years before I started working more deeply with React and Next.js.

At first, I thought modern frontend development would feel completely different from WordPress development.

But over time, I realized many of the most valuable lessons I use today actually came from building WordPress systems.

The tools changed.

The engineering principles mostly stayed the same.

WordPress Taught Me To Build For Real Usage

One thing WordPress teaches very quickly is that real production systems rarely stay clean for long.

Projects evolve continuously.

Clients request changes.
Plugins interact unexpectedly.
Requirements shift.
Legacy code remains active for years.

You learn very quickly that software is not only about shipping features. It is also about maintaining systems over time without creating unnecessary friction.

That mindset became extremely valuable later while working with React and Next.js applications.

Modern frontend systems also grow gradually.

Components expand.
State management becomes more complex.
Business logic spreads across the application.

The same maintainability problems appear again, only in different forms.

Reusability Became More Important Than Speed

Early in my career, I focused heavily on getting features working quickly.

But after building larger WordPress systems, I started paying much more attention to:

reusable architecture
modular systems
predictable structure
naming consistency
extensibility

because projects rarely stop growing after launch.

That thinking carried directly into how I now build React and Next.js applications.

I started treating frontend systems more like long term infrastructure instead of isolated pages.

WordPress Hooks Changed The Way I Think About Extensibility

One thing I still appreciate deeply about WordPress is its extensibility model.

Hooks force you to think carefully about:

separation of responsibilities
extensibility points
integration safety
backward compatibility

When I started working with React ecosystems, I noticed similar ideas appearing in different ways through:

reusable components
context systems
composition patterns
shared hooks
modular architecture

The implementation style changed, but the underlying engineering mindset felt surprisingly familiar.

Modern Frontend Development Increased My Focus On Architecture

Working with Next.js pushed me to think more carefully about frontend architecture itself.

I started paying more attention to:

rendering boundaries
API structure
route organization
hydration behavior
bundle optimization
caching strategies
deployment workflows

These were areas I rarely had to think deeply about in traditional WordPress theme development.

Modern frontend tooling exposes different engineering problems, and solving those problems improved the way I approach systems overall.

But WordPress Experience Continued Helping Me

Even after working more deeply with React and Next.js, my WordPress background kept helping me constantly.

Especially in areas like:

maintainability
debugging production issues
CMS workflows
plugin architecture
client facing systems
long term project stability

A lot of frontend applications look impressive initially but become difficult to maintain over time.

WordPress development taught me to value stability and clarity much more than constantly chasing complexity.

That mindset still influences how I structure frontend systems today.

Frontend Systems Are Not Only About UI

One thing that changed significantly while working across WordPress and modern frontend frameworks was my understanding of frontend engineering itself.

Frontend systems are not only about visuals anymore.

You start thinking much more about:

data flow
API boundaries
performance
caching
deployment
scalability
state management
maintainability

That naturally pushed me toward broader full stack development over time.

The boundary between frontend and backend became much smaller.

Different Tools Solve Different Problems

I do not really see WordPress and Next.js as competing technologies.

They solve different kinds of problems.

WordPress taught me:

practical maintainability
extensibility
CMS architecture
production stability
plugin ecosystems

Next.js taught me:

frontend system architecture
rendering strategies
scalable UI composition
modern deployment workflows
application level optimization

Working with both gave me a broader understanding of how frontend systems evolve as projects grow.

Simplicity Became More Valuable

One lesson that stayed consistent across both ecosystems is that simplicity matters more than making systems look advanced.

The projects that survive long term usually prioritize:

readability
maintainability
clear structure
predictable behavior
good communication

instead of unnecessary architectural complexity.

That became much more important to me over time than choosing a specific framework.

Final Thoughts

Looking back, years of WordPress development shaped the way I approach frontend engineering much more than I originally expected.

Working with React and Next.js introduced me to new frontend patterns and modern tooling, but many of the core engineering lessons still came from building maintainable WordPress systems in real production environments.

The technologies evolved, but the fundamentals remained surprisingly consistent:

build maintainable systems
keep architecture understandable
reduce developer friction
optimize for long term usability
write software that other developers can work with confidently later

Those are the lessons that stayed with me the most across both ecosystems.

UTM Tracking at Scale: Building a CRM Integration Pipeline for WordPress

Kunal Pareek — Sat, 16 May 2026 13:05:30 +0000

Why I Built This Plugin

This plugin started as a practical solution to a real problem I kept seeing in WordPress projects.

Marketing teams wanted attribution data.
Developers wanted flexibility.
Clients wanted ownership of their data.

Most existing solutions either depended heavily on third party SaaS platforms or became difficult to customize once workflows became more complex.

So I started building a lightweight tracking system directly inside WordPress.

GitHub Repository:
https://github.com/KunalPareek21/crm-utm-tracker

The goal was simple:

capture UTM data reliably
store it in a structured way
expose it through a clean REST API
visualize analytics directly inside WordPress

What looked simple at first quickly became a much deeper engineering problem.

Tracking Systems Fail Quietly

Pages still load.
Forms still work.
Leads still arrive.

But attribution slowly becomes inaccurate because of:

redirects
inconsistent parameters
frontend integration issues
caching layers
unreliable session handling

That forced me to think more carefully about reliability instead of just features.

I wanted the plugin to work predictably even under messy real world conditions.

Thinking Beyond Features

One of the biggest lessons from building this project was understanding how much maintainability matters in WordPress plugin development.

As the codebase grew, I stopped thinking only in terms of functionality and started thinking more about:

separation of responsibilities
predictable data flow
extensibility
debugging visibility
long term maintenance

The plugin eventually evolved into a more structured system with:

a custom post type for tracking links
REST API endpoints for external applications
analytics aggregation queries
AJAX powered dashboards
API key management
rate limiting
sanitization and capability checks
modular admin architecture

I tried to keep the architecture understandable instead of overly abstract.

WordPress projects often live for years.

Different developers touch the same codebase over time.
Clients request modifications months later.
Systems grow gradually instead of being rewritten from scratch.

That changes how you think about engineering decisions.

A plugin is not only code that works today.
It is code that somebody can still understand later.

Backend Engineering Lessons

Working on this project improved how I approach backend systems in general.

I spent a lot of time thinking about:

request validation
secure REST endpoints
indexed database queries
API design
rate limiting
structured analytics storage
performance under larger datasets

This was also one of the first projects where I started caring deeply about developer experience inside WordPress admin panels.

I did not want the dashboard to feel like an afterthought.

The plugin includes:

analytics charts
live AJAX filters
detailed per-link views
conversion metrics
tracking summaries
copyable tracking URLs

not because dashboards need visual polish for marketing screenshots, but because internal tools become easier to use when information is structured clearly.

Keeping Data Inside WordPress

Another important part of this project was keeping ownership of data inside WordPress itself.

A lot of modern tooling pushes users toward external analytics platforms for even basic attribution workflows.

I wanted to explore what a self hosted approach could look like when combined with:

REST APIs
modern admin interfaces
structured database design
frontend charting libraries

while still respecting WordPress conventions.

Small Details Matter

This project also taught me how important small implementation details are.

Things like:

sanitizing metadata
limiting payload sizes
protecting AJAX requests
validating capabilities
handling uninstall cleanup properly
indexing analytical queries

become very important once software starts handling real usage instead of isolated local testing.

Final Thoughts

Looking back, this plugin became much more than a tracking tool for me.

It was one of the first projects that pushed me deeper into:

maintainable plugin architecture
backend engineering
API driven systems
analytics workflows
production reliability

and it changed how I think about building software inside the WordPress ecosystem.

Open source projects like this are valuable because they force you to think beyond demos and isolated features.

You start thinking more about:

maintainability
compatibility
upgrades
developer handoff
long term usability
operational reliability

Those are the parts of engineering that become increasingly important as projects grow.

Building Maintainable WordPress Plugin and Theme Systems

Kunal Pareek — Sat, 16 May 2026 12:53:18 +0000

Most WordPress discussions online focus on quick solutions, page builders, or shipping features fast. But after working on real client projects, internal tooling, staffing systems, dashboards, and reusable architectures, I realized long term maintainability matters much more than short term speed.

A WordPress project may start simple, but complexity grows very quickly.

New plugins get added.
Custom hooks increase.
Business logic expands.
API integrations appear.
Frontend requirements evolve.

Without structure, projects slowly become difficult to debug, extend, and maintain.

Over the years, my approach to WordPress development changed completely. I moved from building isolated websites to thinking more about reusable systems, developer experience, scalability, and long term maintainability.

WordPress Projects Grow Faster Than Expected

Most projects begin with a small scope.

A theme.
A few plugins.
Some custom fields.
A contact form.

But real projects rarely stay that small.

Soon the system needs:

custom workflows
admin utilities
automation
external APIs
analytics dashboards
reusable frontend components
internal business tools
role based permissions

At that point, random snippets and tightly coupled logic start creating problems.

One issue I noticed early in my career was that many WordPress projects are built only for immediate delivery. Very little attention is given to how the system will evolve six months later.

That becomes expensive over time.

Maintainability Is a Feature

One thing remote engineering taught me is that maintainability is not optional.

Code should remain understandable long after it is written.

In many real projects, the original developer may not be available later. Another engineer should still be able to:

understand the architecture
debug problems safely
extend functionality
trace business logic
work confidently inside the system

without needing long explanations.

That is why I now prioritize:

predictable folder structures
reusable plugin architecture
isolated business logic
modular utilities
consistent naming conventions
internal documentation

Good architecture reduces friction for future development.

Plugins Should Have Clear Responsibilities

Earlier in my journey, I used to place too much functionality inside single plugins.

Over time I learned that focused plugins are easier to maintain.

For example:

analytics logic should remain isolated
API integrations should stay modular
admin utilities should not control frontend rendering
automation systems should remain independent

Smaller systems are easier to debug, reuse, and extend.

This becomes especially important when client requirements change repeatedly during development.

Reusability Saves Huge Amounts of Time

One thing I genuinely enjoy building now is reusable infrastructure.

Instead of rebuilding the same functionality for every project, I prefer creating:

reusable hooks
internal helper utilities
plugin starter systems
flexible admin panels
API wrapper layers
reusable frontend components

This improves consistency across projects and reduces repetitive work.

It also helps new developers onboard faster because the structure feels familiar.

Theme Development Should Stay Predictable

One major issue in older WordPress projects is mixing everything together.

Themes often contain:

business logic
API calls
frontend rendering
utility functions
admin workflows

inside the same files.

That structure becomes difficult to scale.

Now I try to separate concerns more carefully.

Business logic stays isolated.
Frontend rendering remains predictable.
Utilities stay reusable.
API integrations remain modular.

Even when using traditional WordPress themes, modern engineering practices improve maintainability significantly.

Internal Tooling Is Extremely Valuable

One thing I learned from production systems is that internal tools often create more long term value than public features.

Simple utilities can save teams hours every week.

For example:

workflow dashboards
reusable admin systems
automation helpers
deployment utilities
API monitoring tools
staffing management systems

may never appear publicly, but they improve operations constantly.

I enjoy building these systems because they simplify workflows and reduce developer friction directly.

Simplicity Matters More Than Clever Architecture

Modern development moves very fast.

Every few months there is a new framework, pattern, or architecture trend. But most long term projects still succeed because of fundamentals.

Things like:

readable code
clear communication
reusable systems
performance awareness
consistency
documentation

matter more than trying to make systems look overly advanced.

I prefer building software that remains understandable months later instead of systems that only look impressive during initial development.

Performance Is Part of Maintainability

As projects grow, performance problems usually appear slowly.

Too many plugins.
Heavy queries.
Duplicate requests.
Unnecessary dependencies.
Large frontend bundles.

Over time these issues create maintenance problems.

That is why I now pay much more attention to:

reducing dependencies
optimizing API usage
minimizing plugin conflicts
improving frontend performance
simplifying rendering logic
avoiding unnecessary complexity

Fast systems are usually easier to maintain too.

Documentation Is Engineering Work

One mindset that changed my workflow completely was treating documentation as part of development itself.

Good documentation explains:

why something exists
expected behavior
edge cases
business rules
API structures
integration limitations

This becomes especially important in WordPress environments where multiple systems interact together.

Without documentation, even small updates become risky later.

WordPress Is Still Extremely Powerful

Sometimes developers underestimate WordPress because they only associate it with simple websites or page builders.

But WordPress can still power:

internal business systems
scalable publishing platforms
custom workflows
SaaS dashboards
API driven applications
headless frontend systems

when engineered properly.

The challenge is rarely WordPress itself.

The challenge is architecture quality and maintainability.

Final Thoughts

My approach to WordPress development changed a lot after working on larger systems and remote engineering teams.

I still enjoy building plugins and themes, but now I think much more about:

maintainability
scalability
developer experience
documentation
reusable systems
long term clarity

Good engineering is not about making systems look complicated.

It is about building software that remains understandable, practical, scalable, and maintainable long after the first deployment.

Async-First Engineering Culture for Remote Teams

Kunal Pareek — Sat, 16 May 2026 12:36:02 +0000

Most discussions around remote engineering focus on meetings, productivity hacks, or tools. But after working with distributed teams on WordPress platforms, internal tooling, frontend dashboards, SaaS systems, and API integrations, I realized async work is really about clarity.

Good async teams do not depend on constant calls. They depend on understandable systems, clear communication, documentation, and code that another developer can work on without confusion months later.

I started my journey building WordPress websites and custom plugins. Over time, that evolved into building reusable systems, React applications, Next.js dashboards, backend APIs, and internal tools for real client workflows. Working remotely with globally distributed teams changed the way I think about engineering completely.

What Async First Actually Means

A lot of people think async work simply means working from home or avoiding meetings.

That is not really true.

Async first engineering means creating workflows where work can continue without needing everyone online at the same time.

In many teams, developers work across different time zones. Designers, frontend developers, backend engineers, project managers, and clients may all work on different schedules. If progress depends completely on live communication, projects slow down very quickly.

That is why async teams focus heavily on:

documentation
communication clarity
predictable workflows
maintainable systems
written discussions
proper context sharing

Async work is less about “less communication” and more about “better communication”.

Most Remote Work Happens Through Written Communication

One thing that surprised me while working remotely was how much engineering work happens through writing.

A normal day often includes:

Slack discussions
GitHub pull requests
issue comments
technical documentation
API explanations
bug reports
deployment notes
project planning updates

Sometimes a properly written message solves a problem faster than a meeting.

For example, sending:
“API issue fixed”

does not help much.

But explaining:

what was broken
why it happened
what changed
what files were affected
whether anything else may break

creates long term clarity for the team.

That small difference becomes extremely important in async environments.

Documentation Is Part of Engineering

Earlier in my career, I used to think documentation was optional.

But while working on larger WordPress systems, custom plugins, and internal tools, I realized undocumented systems become difficult to maintain very quickly.

In WordPress environments especially, multiple plugins, hooks, APIs, cron jobs, and custom logic often work together. Without documentation, even small changes become risky.

Now I try to document:

why something exists
expected behavior
edge cases
dependencies
API response structure
business logic decisions

Documentation is not separate from engineering.

It is part of engineering.

Good documentation reduces developer friction and helps future contributors understand the system faster.

Building Systems That Other Developers Can Understand

One thing I value a lot now is maintainability.

I enjoy building systems that feel predictable and understandable instead of overly complicated.

In many real world projects, the best solution is usually not the smartest looking architecture. It is the one the next developer can maintain confidently.

That developer might join the project months later and know nothing about the original implementation.

Good systems should help developers understand:

project structure
reusable components
API flow
naming conventions
business logic
deployment process

without requiring long explanations every time.

This became especially important while building:

staffing platforms
internal dashboards
WordPress utility systems
reusable frontend architectures
custom API integrations

Complexity grows naturally over time. Good engineering keeps that complexity manageable.

Simplicity Is More Valuable Than Over Engineering

Modern development changes very fast.

Every few months there is a new framework, architecture trend, or “best practice”. But most production systems still succeed because of fundamentals.

Things like:

readable code
consistent structure
performance awareness
proper debugging
reusable systems
communication clarity

matter more than trying to make everything look advanced.

I prefer building systems that remain understandable six months later instead of systems that look impressive only during initial development.

That mindset helped me a lot while working with:

React
Next.js
Vue.js
TypeScript
Node.js
PHP
WordPress
jQuery
MongoDB
MySQL

Every technology has tradeoffs. Understanding when to keep things simple is an important engineering skill.

Internal Tools Often Matter More Than Public Features

One interesting thing I learned while building internal tooling is that small utilities can save huge amounts of time for teams.

Sometimes a simple dashboard, reusable component system, or automation utility improves workflow more than adding new frontend features.

I genuinely enjoy building:

admin systems
workflow utilities
internal dashboards
reusable hooks
plugin tooling
automation scripts
API helper systems

because they improve developer experience directly.

Good internal tools reduce repetitive work and make teams faster without creating unnecessary complexity.

Async Work Requires Ownership

One major difference in remote environments is responsibility.

When nobody is physically sitting near you, engineers need to communicate clearly and manage their work properly.

That includes:

updating progress regularly
documenting blockers
writing understandable pull requests
testing changes properly
keeping communication transparent

Async work rewards ownership.

A developer who communicates clearly and keeps systems maintainable becomes extremely valuable in distributed teams.

My Personal Workflow

Over time, a few habits improved the way I work remotely:

writing detailed pull request descriptions
keeping commits focused
avoiding unnecessary dependencies
documenting API behavior properly
organizing reusable components early
reducing technical debt continuously
communicating blockers instead of silently debugging for hours

These are small habits, but together they improve team collaboration significantly.

Final Thoughts

Remote engineering is not only about working from a different location.

It changes how you think about systems, communication, collaboration, and long term maintainability.

For me, async first development created a much stronger focus on clarity and simplicity.

I still enjoy building WordPress systems, frontend applications, APIs, dashboards, and internal tooling, but now I think much more about how those systems will be understood and maintained by future developers.

That future developer might even be me six months later.