How I Work | Paulo H. Alkmin

I build systems that survive contact with reality. Here's what that looks like in practice.

I've been doing this for 25 years. Long enough to have strong opinions about what makes projects succeed and what makes them quietly fall apart three months after delivery. Most of the problems I get hired to solve aren't technical — they're the result of someone building something without thinking about who maintains it next.

My work sits at an unusual intersection: deep WordPress/WooCommerce platform knowledge, production AI systems (RAG, LLM integration, automation pipelines), and the kind of infrastructure experience that comes from running servers since before "the cloud" was a marketing term. I don't specialize in one of those things. I specialize in what happens when they need to work together.

How an Engagement Typically Goes

1. Audit & Diagnosis Before I write any code, I need to understand what's actually broken — not what someone thinks is broken. This means access to the codebase, server logs, and an honest conversation about what's been tried before. Most of the time, the real problem is two layers deeper than the reported symptom.

2. Architecture & Scope I define what we're building, what we're explicitly not building, and what "done" looks like. No sliding scope. If the scope needs to change, we have that conversation before I start writing code, not after.

3. Build I build the thing. I write the integrations, handle the error states, and test against the edge cases that only show up when real payment data or real customer queries hit the system. I work in focused blocks, not in Slack threads.

4. Document Everything I build gets documented — not as an afterthought, but as part of the deliverable. Architecture decision records, integration guides, operational runbooks. If I get hit by a bus, someone else can maintain it. That's the standard.

5. Handoff & Support I hand over a working system with documentation that doesn't require me to be on call forever. If you need ongoing support, we can structure that. But the goal is always a system that works without me.

What I Need From You

I do my best work under specific conditions, and I'm upfront about them:

A decision-maker who responds. I don't need daily standups, but when I surface a decision that blocks progress, I need an answer — not a committee meeting next Thursday.
System access from day one. I can't diagnose what I can't see. Codebase, staging environment, server access, API credentials — the sooner I have these, the sooner I'm productive.
Clear scope. "Make it better" is not a scope. "Fix the subscription billing failures and document the payment gateway architecture" is a scope. If the scope isn't clear yet, I can help define it — but that's a separate phase, not a free discovery call.
Trust in async work. I'm remote-first, based in São Paulo (UTC-3). I communicate through structured updates, not constant presence. You'll know what I'm working on and when it'll be ready. You won't see me typing in Slack all day, and that's by design.

Where I Create the Most Impact

Systems with architectural debt — platforms that work but are held together by workarounds, undocumented integrations, and code nobody wants to touch.
WordPress platforms that need AI integration — not chatbot demos, but production systems: RAG-based customer service, automated content pipelines, LLM-powered tooling that runs on real traffic.
Automation for teams that need it but can't justify a full-time hire — N8N workflows, API integrations, reporting pipelines that replace the manual process someone's been doing every Monday for two years.
Regulated or compliance-sensitive environments — I've built for Canadian health regulations and CBD compliance. I understand that "move fast and break things" doesn't apply when there are legal consequences.
Teams that need documentation, not just code — if your last developer left and took all the context with them, I'm the person who makes sure that doesn't happen again.

What I Don't Do

I'm specific about this because it saves us both time:

I'm not a no-code tool operator. I use N8N and similar tools as implementation layers, not as the architecture itself. If you need someone to click through a Zapier UI, I'm not the right fit.
I don't do open-ended retainers without defined deliverables. Every engagement has a scope, a timeline, and a definition of done. If you need someone on permanent standby "just in case," that's a different kind of hire.
I don't thrive in heavy-meeting cultures. A weekly sync and async updates work. Daily standups, sprint ceremonies, and three Slack channels per feature do not — at least not for the kind of deep work I do.
I won't pretend your current architecture is fine if it isn't. If I see problems during the audit, I'll tell you. You're paying for honest assessment, not reassurance.

The Short Version

I take broken or complex systems, make them stable and documented, and hand them back in a state where you don't need me anymore. If you do need me again, it's for the next problem — not because the last one fell apart.

That's how I work.