What is it that I do?

Someone I’ve known for quite a long time asked, “Ok… but what is it that you do?” I paused, opened my mouth, paused again, and then had one of those “aha” moments, because it had been quite a while, if ever, since someone asked me to describe what I actually do, rather than listing project teasers and technical skills.

So, here’s what I do on a typical web development journey from start to finish—though of course there are different roads and can be permutations of routes along the way.

I listen to the client. I’ve been doing this since I was a programmer analyst at age 20. It just came naturally to me, which is why I was being paid to do it while still working on my degree. It didn’t occur to me then that listening was a specialized skill. I listen closely as the client describes their business goals or challenges, rarely interrupting because I don’t want to disrupt their train of thought or break their concentration and momentum. Explaining important needs to someone from the “outside world” can be challenging for clients, so uninterrupted listening is crucial. To an observer, it might seem I’m not engaged beyond eye contact, but trust me—all cylinders are firing. I take notes, ask for clarifications, read back parts in my own words to verify my understanding, and probe further where needed. By the end, I have a clear narrative that becomes the basis for high-level specifications.

I’ll leave out the multiple feedback iterations with the client. You can safely assume they happen. When people see or hear their ideas reflected in a different form, they’ll often adjust details—sometimes subtly, sometimes dramatically—put a finer point on things, or simply change their minds. Like a ship correcting course, adjustments are better made sooner than later.

The next steps depend on whether I’m part of a team or flying solo. Ideally, a fully staffed project would include information architects, UX experts, content strategists, graphic designers, and others. But since I’m describing what I can do personally, I’ll continue as if I’m flying solo.

By now, I understand the site’s goals, who it’s intended for (personas), and the ideal user experience. This is when I sit back with a pencil in my mouth (eraser end), close my eyes, and imagine users having the best possible interaction. Eventually, I translate this daydream into sketches, which later become low-fidelity wireframes.

Before sharing the wireframes, I activate my Drupal architect’s brain, which until then, I’ve kept safely occupied in the back room playing five-card stud. Now I’m examining each element on the page in terms of “Where will this content come from?”, “How will it get there?”, “What’s needed to accomplish this?”, and “Is there a better way?” ‘Better’ meaning less complex, less costly, or lower technical risk. I revise the wireframes as needed. With this step complete, I have the beginnings of a draft architecture ready for review.

I’m not a graphic designer—never played on tv—my left brain stubbornly refuses to cooperate on that front. But after 20 years of building websites, I produce designs good enough that a professional designer can easily polish, provided there’s a budget for it. Next, I transform low-fi wireframes into high-fi ones. It probably defies convention, but when working alone, I prefer to make initial assumptions about palette and typography and then get feedback. I’ve tried having these discussions earlier, but they can be endless, like the eye doctor repeatedly asking, “Which one is better: 1, or 2? 1, or 2...?” Hard to know when your eyes are glazing over.

Eventually, all systems are locked, and it’s time for architectural planning.

Drupal can be quite complex. Working backward from the finished web page, the architecture might involve many possible configurations of content and functionality. The key is keeping it simple, maintainable, performant, as future-proof as possible, and in line with Drupal best practices (PHP, MySQL, CSS, etc.). In short, work smarter, not harder.

If you’re familiar at all with Drupal, you’ll recognize I’ve greatly simplified this description. At the end of this step, I produce a detailed architectural specification, which then informs a site-building specification.

I’ve always liked comparing website creation to building a house. At this point, I have the architect’s blueprints ready to hand off to the architectural draftsman to decide on materials and construction methods. In Drupal, this is typically the role of the technical lead, who lays out details for site builders and developers. Since I’m still flying solo, I’m wearing one hat with interchangeable Velcro role patches.

Site-building activities loop back to our initial discussions and wireframes. Decisions at this stage hinge upon architectural guidelines: content structure, filtering methods, access permissions, data security, external integrations, moderation workflows—the whole shebang. The site builder translates these answers into practical implementation.

But wait…

Is this site the rebirth of another? Does it involve content migration? If so, migrations need to be carefully designed, scripted, tested, and executed. Depending on complexity, migrations can sometimes take longer than the rest of the project combined.

Once the core site-building tasks are complete, development begins. Even when working alone, I create detailed ‘tickets’ or tasks. I prefer having distinct subtasks clearly defined, making tracking easier for both me and the client, useful for billing, project management, and future reference. Development typically involves creating custom Drupal modules, views, webforms, Twig templates, CSS, and JavaScript—the depths of the right-brain. Honestly, working solo in this area is increasingly challenging due to demands for technologies like React, Angular, Tailwind, PostCSS, and others.

Flying solo does have one drawback: there’s nobody to perform code reviews. They say only a fool represents himself in court, and I’d add the same applies to code reviews and testing. Thus, I rely heavily on tools for linting (checking for semantical errors) and that verify coding standards are being followed to keep myself honest.

Integrations, such as SSO, Salesforce, and data feeds, plus webform creation and testing, and implementing content moderation workflows happen at this stage, blurring the lines between site-building and development.

Finally come client QA, pre-launch, and launch phases. These vary significantly depending on where the site is hosted. I’ve launched sites on Pantheon, Acquia, Linode, and others, each with unique procedures and quirks. Certain features like search functionality or SSO integration might only be configured and activated during this stage.

I’ve skipped some steps such as performance analysis, SEO, and accessibility testing. Although not my primary expertise, I’m familiar enough to address these areas effectively.

I hope this clarifies exactly what I do. And if you’re looking for someone who can wear all these hats (with or without Velcro), please reach out—I’m currently open to new opportunities!