Interview with module developer Maxim Semenov

31 July 2026 by Ryan Cramer   0 Comments

How Maxim built more than 50 ProcessWire modules in a year, around a full-time job as a FedEx Ground driver.

If you've been following ProcessWire in recent months, no doubt you've come across modules by Maxim Semenov. Also known as Maximus in the forums, he has quickly become one of ProcessWire's most prolific module developers, with 50+ modules added to our directory within just the last year (two within the last day). These are exceptional-quality modules that solve real needs.

By comparison, it has taken me 16 years to create 74 modules in the directory. I'd also like to give a shoutout to our most prolific module developer of all time: Robin S. with 80 modules, as of July 2026.

While developing all of these modules, Maxim was also working as a full-time FedEx Ground driver. How does one create so many modules of such quality, at such a rapid pace - and while delivering FedEx packages through most of it? How does one even come up with that many ideas for modules that answer so many needs?

A lot has changed over the last couple of years as AI has increasingly integrated into ProcessWire development, and web development in general. Maxim seems to have fully transitioned to this new world, where AI is integral to the process and enables developers to build better and faster than before. His module contributions to the ProcessWire community are a very visible and inspiring representation of that new paradigm. I was genuinely curious how Maxim works and what we could learn from him, and this interview is the result. —Ryan

Part of Maxim's process for responding to these interview questions involved writing a narrative. I asked him if he would mind posting it on his site and letting us link to it for more information in various parts of this interview, which you'll see linked in this style of text.

For anyone who doesn't know you yet: what's your background, and how did ProcessWire end up as part of your work?

If someone has only recently discovered my work through ProcessWire modules, it may look as though I appeared out of nowhere. The journey actually began more than twenty years ago.

I started experimenting with websites around 2004. A friend asked whether I could build a site for his hot-tub business. I did not really know how, but I opened Dreamweaver and started learning. The site was never finished, yet the question changed the direction of my life.

My first mentor was Roman Rassokhin. He saw potential in me before I knew what to do with it and helped me understand that web development could be a profession, not only a hobby. I went on to build dozens of commercial sites, especially for hotels and health resorts around Kislovodsk and the Caucasian Mineral Waters region in southern Russia. Most of that work used a CMS called SantaFox. I was not its developer; it was simply the system on which I learned to turn business requirements into working websites.

In 2016 I won the Green Card lottery on my second attempt and moved to the United States. I had to start over, and my path moved through warehouse work, Uber, Amazon Flex, FedEx Ground, product design, and several ambitious projects of my own. I never stopped building, even when building software was not my full-time job.

The largest of those projects was Altapost, a parcel-forwarding platform that grew from a friend asking me to buy American brands and ship them to Russia. I worked on it from 2017, paid a developer to build the earlier platform, and invested more than $70,000 of my own money. It never officially launched. I had designed something too large for one person to carry, but the experience taught me how to think about logistics, billing, warehouses, customs, customer accounts, and software as a system rather than a collection of screens. I am now rebuilding its core on a modern Laravel and Filament stack with AI assistance, but that work is still in progress.

ProcessWire entered the story in January 2024 while I was looking for a better foundation for LQRS, a liquor discovery project. What began as one website soon produced reusable solutions for search, SEO, comments, analytics, privacy, commerce, AI, and other needs. Those solutions became modules. I did not plan to become a module developer. I was trying to build one product, and an ecosystem grew around it.

More: Introduction

What were you using before ProcessWire, and what made you switch?

For many years I worked with SantaFox. It gave me the freedom to build very different websites for hotels, resorts, and other businesses without treating every project as the same collection of pages. Later, when I no longer had the budget to keep paying programmers for my own products, I moved more deeply into product and interface design. Sketch became my main tool. Figma was appearing at the time, but its interface never felt natural to me.

Tailwind CSS brought me back toward frontend development. I enjoyed the directness of composing an interface and working with states and variants in the markup. From there I started looking again for a system that would let me control the whole product.

I first tried to build LQRS on OpenCart. I paid one programmer to import initial data and another to collect it. Eventually I had to ask myself an uncomfortable question: after spending most of my life building websites, why was I still paying other people to shape a product whose structure I understood?

I did not want another system that made me fight predefined assumptions. ProcessWire gave me a small vocabulary - fields, templates, pages, hooks - that I could combine around the actual problem. It felt less like switching to a new CMS and more like finding a clearer way to model software.

That freedom was familiar from my SantaFox years, but ProcessWire gave it to me through a much cleaner and more extensible architecture. It adapted to the project instead of forcing the project to adapt to it.

More: SantaFox & Altapost

Your forum profile says you joined in January 2024, but that can't be the whole story… When did you actually start using ProcessWire, and what was the first thing you built with it?

The forum date is accurate. I really did begin using ProcessWire around January 2024. The depth came from bringing almost twenty years of earlier web, design, and product experience into a new system.

I found ProcessWire by accident. I had been looking at Kirby and studying the portfolio of Swiss designer Gilbert Nigg. At the bottom of the site I noticed a small ProcessWire logo and clicked it out of curiosity.

That evening I installed a ProcessWire demo profile. It was a site about skyscrapers. I opened a bottle of Innis & Gunn, used ChatGPT 3.5 as a guide, and began replacing the demo with a liquor catalogue. I changed the content model, added products and filters, and tried to understand how fields, templates, pages, and page references worked together.

I remember watching the sunrise with my head almost hurting from the new way of thinking. The first project was LQRS.uk, an early version of the larger LQRS idea. That version still exists in almost the same form, which makes it a useful record of the night everything started.

My first forum question was also very ordinary: I needed better spacing around vertical product images. That is how most of my work begins - not with a grand plan, but with one concrete problem.

ProcessWire did not just introduce me to another CMS. It reminded me why I had enjoyed building websites in the first place.

You've mentioned that most of your modules begin as solutions to real problems in your own projects. Can you describe an example of such a project, and how it evolved?

The project is LQRS. The name is a shortened form of “Liquors.” I removed the vowels because I liked the compact shape, and because meaningful four-letter .com domains have become difficult to find. I probably spend more time naming projects than most developers would consider reasonable. To me, the name is the beginning of the story.

LQRS began as an online liquor store. The more I worked on it, the clearer it became that I was interested in something broader than a catalogue with a shopping cart.

I wanted a place where someone could discover a bottle, understand the producer and region, compare products, read or write reviews, explore cocktails, and move naturally between whisky, wine, beer, distilleries, breweries, and related stories. The data model and community mattered as much as commerce.

That ambition is what led me to look beyond OpenCart and eventually discover ProcessWire. The first ProcessWire prototype was intentionally small, but it gave me control of the structure.

As I built it, I kept finding missing pieces. I wanted richer conversations and reviews, so Vox began. I needed a broader SEO system, which led to Ichiban. I needed analytics, privacy tools, newsletters, security, commerce, and AI integration. Each need created another reusable piece.

The public site is still a work in progress. LQRS has changed direction more than once, and many of its components became useful outside the original product before the product itself was finished. I no longer see that as wasted motion. It taught me product architecture and created tools other people can use now.

LQRS is still one product, but it is also the place where most of my ProcessWire ecosystem learned to work together.

More: LQRS: One Product, Many Modules

Since you run the LQRS site, I have to ask: any favorite drinks?

I am probably more interested in discovering tastes than collecting expensive bottles. Moving to the United States introduced me to many products, foods, and local traditions I had not experienced before. I enjoy that kind of exploration.

The drink I associate most with ProcessWire is Innis & Gunn beer. I had a bottle beside me on the night I discovered ProcessWire and rebuilt the skyscraper demo into the first LQRS catalogue. Now that taste is attached to fields, templates, filters, and sunrise.

I also enjoy cocktails because they combine ingredients, cultures, and stories. Perhaps that is another version of the same curiosity. So the honest answer is: no strict loyalty, but a good memory can make one bottle more important than an expensive label.

How much of your module roadmap is “I needed this” versus “I think the community could use this”?

Most of my roadmap is still “I needed this.” I do not keep a list of random module ideas. I keep building products. When a missing piece appears more than once, I ask whether it can become a small finished product of its own.

Only after solving the problem for myself do I ask the second question: could this help another ProcessWire developer? If the answer is yes, I separate the project-specific assumptions, improve the interface, test installation and removal, write documentation, and prepare a public release.

This is why the modules cover many categories but still feel connected to me. They are not a collection assembled for quantity. They are the toolbox that emerged while I was trying to build LQRS and other products properly.

Where does an idea for a new module usually start for you?

Usually with irritation.

I am working on a real project and notice that a task is awkward, repetitive, incomplete, or solved at the wrong level. Sometimes the idea appears at the computer. Often it appears while I am walking, driving between places, or doing something unrelated. During the day I write it down on my phone so I do not lose it. The longer design conversation happens later, when I can give it proper attention.

The first question is not “Can I code this?” With current tools, almost anything can be prototyped. The useful questions are: who is this for, what exact problem does it solve, what should it not do, how should it behave inside ProcessWire, and what would make it feel native rather than attached from the outside?

Some ideas disappear during that conversation. That is a good result. Code that should never have been written is the easiest code to maintain.

If the idea survives, I write a specification and think about the public API, data model, lifecycle, permissions, failure cases, and interface before implementation. By the time I open the editor, much of the important work has already happened.

More: How Ideas Become Modules

What does an actual first prompt look like when you're sketching a new module idea? How much of that stage is you shaping the idea versus the AI writing code?

A typical opening prompt is very simple:

Let's build an online voting module for ProcessWire. 
First, let's discuss what functionality it should have…

That is the kind of prompt I dictate on my phone when an idea appears. The first conversation is not really about code. We discuss what the module should do, who would use it, how it should behave, what its interface might look like, and which ideas are useful enough to keep. Sometimes the AI proposes a feature; sometimes I reshape or reject it and add my own.

I am shaping the idea throughout that conversation. AI is useful because it can hold many threads at once, expose assumptions, and ask about an edge case I have missed. It can also help turn associative, unstructured thoughts into a specification another developer or agent can follow.

At that stage I do not measure progress in lines of code. A strong project brief, architecture, and acceptance criteria are the output. Implementation comes later, currently mostly in ChatGPT Codex. The model may write much of the initial code, but the direction, constraints, review, and final judgment remain mine.

AI shortened the distance between an idea and a working prototype. It did not remove the need to know what should be built.

More: AI as a Design Partner

Once an idea is scaffolded, what does your review and testing process look like before it's ready to install and use?

The generated scaffold is the beginning, not the result.

I review the architecture and code in Codex, then install the module into a clean local ProcessWire site under MAMP Pro. I prefer an isolated environment where I am free to break things. I install and uninstall repeatedly, change configurations, leave required values empty, use unexpected inputs, test permissions, and look for assumptions that only work on my machine.

Then I test the interface like a product designer. I click the wrong controls. I look at empty, loading, error, and success states. I check spacing, typography, alignment, hierarchy, and whether the module feels like ProcessWire. I sometimes joke that my eyes work like a scanner: if an element is a few pixels off, I usually notice it.

I also review security boundaries, hooks, cleanup behavior, upgrades, and compatibility with a realistic project. For larger modules, the specification and tests evolve together with the implementation. A feature that works but cannot be explained clearly is often not finished.

Documentation is part of the release. I write the README, examples, screenshots, and increasingly AGENTS.md and API.md. AGENTS.md gives an AI agent a compact explanation of what the module does, when to use it, and where deeper information lives. API.md contains the exact technical surface.

People see a release and assume the module was built quickly. They do not see the review, discarded versions, and weeks of waiting before I decide the first impression is good enough.

Your release pace is pretty wild - how are you able to build modules so rapidly while keeping the quality high?

The first answer is that the public timeline can be misleading. In 2026, Mercato had been in development since March and OIDC since April. KeyHelp was the unusual case: a focused experiment that reached a working prototype in less than twenty-four hours. Releasing three projects close together did not mean all three were created that day or that every part skipped the normal review process.

The second answer is discipline. Until late July 2026, I was working full-time as a FedEx Ground driver. My route could involve furniture, generators, exercise equipment, and other oversized deliveries, not only small boxes. On the heaviest days I sometimes wondered how the Egyptians built the pyramids when moving one piece of furniture out of a truck could be difficult enough.

The routes were very different from one another. Some passed through businesses and neighborhoods around West Chester, Downingtown, and Thorndale; others continued into the countryside around Honey Brook and Glenmoore, where I delivered to Amish families and shared the road with horse-drawn buggies.

Working as a FedEx Ground driver taught me endurance, patience, consistency, and how to focus on the next stop instead of being overwhelmed by the whole route.

After finishing a route near Exton, I often stopped at Whole Foods, bought dinner, opened my laptop, and worked while rush-hour traffic cleared. Ideas collected during the day became specifications and code in the evening. A second laptop stayed at home so that my main workspace was always ready.

AI helped me use limited time more effectively, but speed did not come from asking it to “make a module.” It came from carrying twenty years of design and product experience into a structured process: problem, questions, architecture, specification, implementation, review, testing, documentation.

I also use a release calendar because many modules wait for weeks or months. I think about them quickly and release them slowly. If something does not feel complete, I would rather wait. Bugs can be fixed, but a first impression only happens once.

More: Building Between Deliveries, The Weather Doesn't Care, Lessons Learned

Which AI model or tool is your daily driver right now, and has that changed much over the past year?

It has changed several times, and I expect it to change again.

ChatGPT 3.5 was part of my first ProcessWire night. Later, Claude became the place where many module ideas were shaped through long conversations, questions, architecture, and specifications. Today I do much more implementation, debugging, review, and iterative work in ChatGPT Codex.

I do not expect one model to be best at everything. One may be better at exploring a vague product idea, another at working through an existing repository, and another at reviewing a difficult change. I think of them less as a single daily driver and more as tools with different roles.

Do some models noticeably handle ProcessWire's API/hook conventions better than others?

For ProcessWire specifically, good context matters more than the model name. Without documentation, a model can invent hooks, assume WordPress conventions, misunderstand lifecycle methods, or produce code that looks plausible but does not belong in ProcessWire. With a clear specification, examples, repository instructions, AGENTS.md, and an accurate API reference, several models can do good work.

The model is temporary. Architecture, documentation, and review are the durable parts of the workflow.

Do you use the Codex TUI or the ChatGPT desktop app?

I prefer the Codex app (now ChatGPT desktop app). I like having the conversation, repositories, visual context, browser control, and remote work together.

Do you also use any non-OpenAI / non-Anthropic models?

Yes. I use OpenRouter to test and compare models. For lighter everyday tasks I currently like a fast Gemini Flash model, while Codex remains my primary tool for repository implementation.

More: AI as a Design Partner

Can you describe how AI computer use is part of your development workflow?

I use computer use several times a week, and often daily when I am working on an interface. Before browser control, I would open the site myself, take a screenshot, describe what was wrong, wait for a correction, and repeat. Now I can ask Codex to open the local site in Chrome, install the module, walk through its settings, submit forms, check desktop, tablet, and mobile layouts, and report what looks wrong. Chrome has become an extra pair of eyes, though not a perfect one: if it misses a small area, I still point to it with a focused screenshot.

One useful example came from testing Ichiban on a real site. I asked Codex to work through the module's recommendations and bring the audit result to 100 percent. That pass exposed an application state that could become stuck, so the visual walkthrough found a real module bug rather than only confirming that the page loaded. Keeping every stage in Git matters: if I dislike a visual change or something breaks, I can point to an earlier commit and return to a known state.

I use supervised autonomy rather than giving it unrestricted control of my computer. I keep locked use disabled, so a task cannot continue after the screen locks. I am comfortable letting a bounded, reversible task run locally and checking the result later, but I supervise production deployments, destructive file operations, publishing or sending messages, purchases, credentials, and system permissions. I also log into the ProcessWire admin myself. That small interruption is a useful safety boundary.

The most unusual experiment was a music project that moved between Chrome, MIDI and lyric files, voice tools, and GarageBand. It revealed a clear limitation: we have taught AI to see through a browser, but in this experiment it still felt deaf. It could produce something technically valid that sounded wrong, and I still had to be the listener.

My general rule is to use code or the CLI when a result can be produced and verified deterministically, and computer use when the result exists in an application interface or must be inspected the way a person experiences it. Usually the best workflow uses both. Automated and agent-driven testing can find a great deal, but I still repeat the important path myself before treating it as finished.

What would you suggest for ProcessWire users who are looking to integrate more computer use into their development process?

For a first experiment, I would suggest a deliberately small local loop: change a module, ask Codex [or Claude Desktop] to install it in a clean local site, walk through the configuration and one representative form, and report anything inconsistent. Do not publish anything in that first pass. It is low-risk, easy to supervise, and quickly shows where computer use fits into everyday development.

The broader lesson for me is that there is no universal recipe. Every task asks for a slightly different combination of code, tools, visual interaction, supervision, and human judgment. You discover the useful workflow by trying it, seeing where it fails, and adjusting the boundaries. Curiosity is important here: it opens doors that you would never find by waiting for someone else to define the perfect process.

I do not see this as simply replacing a person. The real advantage appears when a person who understands architecture, design, and the desired outcome learns how to direct and supervise these tools. That person can explore more ideas, repeat more tests, and move much further with the same amount of time. As AI becomes part of ordinary work, I think the growing divide may be less between people and AI than between people who learn how to work with it and people who never get the opportunity to do so.

You're building something you call Olivia, an ‘AI solution architect’ for ProcessWire. What does that actually mean, and what does it do?

The phrase sounds grander than the current reality. Olivia is experimental and in active development, and I have not presented it publicly as a finished module, so I want to describe the goal rather than promise that every part already works. The direction I am exploring is practical: an AI solution architect should help someone think before it builds.

Most website generators move directly from a prompt to output. Real projects usually begin differently. A manager or consultant asks who the users are, what the business is trying to accomplish, which content must be managed, which workflows and permissions exist, what can fail, and what might be needed later.

So Olivia starts with a short description of a site or feature, then offers an interview. From that conversation it creates a structured project brief and a proposed ProcessWire architecture: templates, fields, relationships, roles, workflows, and suitable installed modules. The user should see and approve a preview before anything important changes.

Day to day, that means designing the interview flow, planning format, module discovery, safety boundaries, confirmation points, and rollback manifest. The final act of writing or configuring code is only one step.

The important idea is that Olivia should not invent every capability from scratch. It should understand the modules that are actually installed. I have been adding AGENTS.md, API.md, README, and deeper documentation so an agent can learn what each module does, when to use it, how to configure it, and where the safety boundaries are.

Several modules form the supporting architecture. Squad handles AI providers. Atlas explores memory, RAG, and embeddings. Context helps an agent understand a project. Mercato can provide commerce capabilities, OIDC authentication and SSO, and KeyHelp hosting or provisioning workflows. Olivia's role is to understand the goal and coordinate the right pieces.

I want the system to recommend useful improvements without pretending it knows everything. It should be able to say, “Have you considered this relationship?” or “An installed module already solves that problem,” and explain why. The goal is practical assistance, not magic.

The simplest metaphor I have found is this: the modules are the bricks; Olivia is the instruction manual. The person still decides what should be built and confirms important actions.

I do not know yet whether I will achieve everything I have in mind. That uncertainty is part of why the project interests me. After years of designing websites, products, and business systems, I want to see whether AI can become an architectural partner rather than only a code generator.

More: Why I'm Building Olivia, Conversation Before Configuration

Maxim published Olivia on GitHub the day this interview was published.

If someone reading this could install only four of your modules today, which would you point them to?

I would choose according to the project rather than claim that these modules fit everyone, but here are the four that I chose:

Vox

Vox is the first because attracting someone to a website is only half of the problem; the harder part is giving them a reason to return. Vox adds community discussions, reviews, questions and answers, voting, replies, and block comments to ProcessWire pages. It grew from wanting LQRS to become a place where people participate rather than only browse a catalogue.

WireWall

Modern public websites receive a great deal of automated and unwanted traffic. WireWall is a traffic firewall with VPN, proxy, and Tor detection, rate limiting, and a JavaScript challenge. It is more technical than Vox, but it protects the rest of the application and reduces traffic that should never reach it.

Ichiban

Ichiban means “number one” in Japanese. It is a comprehensive SEO module covering metadata, Open Graph, structured data, audits, redirects, revisions, and reports. Before designing it, I studied SEO plugins and modules across WordPress, Kirby, Drupal, and other systems. I wanted one coherent ProcessWire tool rather than many disconnected pieces.

Mercato

Mercato is a ProcessWire-native commerce toolkit and comes from a much older ambition: I have wanted to build a flexible online store engine since working with OpenCart and seeing how difficult its templates, data model, and payment integrations were to customize.

These modules represent the basic needs of a serious public website: participation, protection, and discoverability. Mercato adds the commercial layer.

Gear check: Android or iOS? What phone are you typing on (or talking to) when a module idea strikes?

iOS. I use an iPhone.

My first iPhone was a 4S that friends brought me from the United States before I moved here, so there is a little history behind that choice. The exact current model is less important to my workflow than having a reliable place to capture an idea immediately.

I often use dictation because speaking is faster than typing and lets me preserve more context. A rough thought on the phone may later become a set of questions, then a specification, and finally a repository. The phone is not where I finish modules. It is where I stop them from disappearing.

And what does your actual hardware and software setup look like beyond the phone - computer, editor, terminal?

My setup is simpler than the number of projects might suggest.

For years my main computer was an Intel MacBook Pro with an i9 processor. One morning I accidentally left it at home before work. I could not afford to lose the day, so I went to an Apple Store and bought a MacBook Air M2, fully expecting to return it during Apple's return period. I never did. It was lighter, silent, and lasted all day. That accidental purchase changed how easily I could continue working away from home.

I have since upgraded to a 15-inch MacBook Air M5 with more memory and storage. Most of my work happens in web applications, editors, local PHP environments, and AI tools rather than video or heavy graphics processing, so the Air gives me the power I need without carrying a workstation.

My editor is Nova by Panic. I have tried Visual Studio Code more than once, but Nova feels focused, fast, and comfortable. I spend enough time in an editor that enjoying the environment matters.

MAMP Pro runs my local PHP and ProcessWire sites.

I use Git, command-line tools, and Codex for repository work, but I do not maintain an elaborate terminal theme or setup. I care more about repeatable commands and clear repository instructions than decoration.

Firefox is now my primary browser. Returning to it was difficult because my last strong memory was Firefox 3.5 and its old memory problems. Vertical tabs, Split View, the AI sidebar, and excellent developer tools changed my mind. Safari is useful for testing. Chrome has become my AI browser, where extensions and browser automation can operate without taking over my everyday workspace.

Do you usually work directly off your MacBook Air or with external monitor, keyboard, mouse, etc.?

At home I use the 15-inch MacBook Air M5 with an ASUS ProArt PA248QV display, plus an external keyboard and mouse. Away from home I work directly on the MacBook.

Any favorite pieces of hardware you consider essential?

My favorite is the old wired Logitech M100 mouse. I have used the same basic Logitech shape through most of my career, and my wrist refuses to accept almost anything else. I also like the HP 970 keyboard because it is heavy, quiet, and backlit.

More: The Tools I Enjoy Using

Outside of modules, work, and AI, what do you do to unplug?

I am not especially good at unplugging. When I first recorded this answer, I talked instead about the need to keep building and leave something useful behind. That accidental answer was still revealing, but there are quieter parts of my life too.

When I do step away, I like nature, botanical gardens, quiet places, driving to places I have not seen, walking through cities, looking at architecture, and photographing details that other people might pass without noticing. Montreal and Quebec City stayed with me because of the mix of North American and French character. Charleston is another favorite for its streets, houses, palms, and horse-drawn carriages. I would also like to spend more time in the United Kingdom; so many towns around Philadelphia and the East Coast carry British names that it feels strangely familiar before I have even gone.

Music helps. Coming from the Caucasus, I enjoy the drums and wind instruments of Lezginka, and I also like Serbian music and its rhythm.

Sometimes unplugging is simply being somewhere quiet and observing people. During delivery work, children would run to the window and wave when they saw the FedEx truck. I would wave or sound the horn, and sometimes they jumped with happiness. Small moments like that could reset an entire day.

More: Small Moments

Is there anyone in the ProcessWire world - or otherwise - you'd want to give a shoutout to?

First, thank you, Ryan, for creating a platform whose architecture was ahead of its time and still gives developers unusual freedom. ProcessWire can begin as a one-page site and grow into a business site, catalogue, store, marketplace, API, or a larger application ecosystem without forcing all of those projects into one predetermined structure.

I would also like to thank Peter Knight. While I was developing modules, I sometimes felt a friendly competitive energy that made me work faster and think more ambitiously. Competition can produce better ideas, but Peter also represents something more important: testing each other's work on real sites reveals problems that the original developer may never see.

Thank you to Teppo for the discipline of writing ProcessWire Weekly, week after week, for more than a decade. Describing the work of the community consistently is difficult and time-consuming, especially when it began long before today's AI tools. That kind of patience and commitment deserves recognition.

Thank you to Adrian for his help testing and improving modules. Automated browser tests are useful, but human testing on a real project remains more valuable. It is how a module moves from something that works for its author to something other people can trust.

Outside ProcessWire, Roman Rassokhin was my early mentor and the person who helped me see web development as a real profession. That belief changed my life.

I am grateful to the whole ProcessWire community. The forum feels approachable because people are usually trying to solve a problem together. I have learned by asking questions, reading other developers' modules, receiving corrections, and seeing how experienced people explain their decisions.

Open source is a conversation. Publishing a module is my way of saying, “I solved this problem; perhaps it can help you too.” That conversation only exists because other people were willing to share first.

More: Open Source & Community, The ProcessWire Community, Why I Keep Sharing

Where should readers go to find and follow your work?

• Main website and professional background: smnv.org
• Public code and module repositories: github.com/mxmsmnv
• ProcessWire module directory profile: /modules/author/maxim-semenov
• Product and interface design portfolio: design.smnv.org
• LQRS (an evolving product rather than a finished showcase): lqrs.com

More: Looking Forward, Final Thoughts, Still Curious

A big thanks to Maxim for agreeing to do this interview and sharing his background and process with us — and for all the great modules he creates for the ProcessWire community. I hope that you found this interview as enlightening as I did.

Personally, I would love to interview others in the ProcessWire community to learn more about their background and development process with ProcessWire. If you'd like to see more interviews like this in the ProcessWire blog, please let me know.

Post a comment