Real project stories without publishing the client’s private implementation.
Long-form notes about what a problem looked like at first, where the work became difficult, what changed, what I learned, and how I would approach the same class of problem now. Client-specific implementation details are generalized when they are not appropriate to publish.
Recent writing
Open a preview, or click a card to read the full article.
The cards give a little context without forcing the entire article onto the index.
NetSuite approvals
Refactoring an approval system without publishing the approval hierarchy
A routing redesign that exposed hidden assumptions and made me rethink how much decision-making should live in code.
One test transaction kept resolving to an unexpected approver even after the obvious routing configuration had changed. Another cleanup exposed code that assumed a supporting configuration record would always exist. The eventual fix was less about adding conditions and more about making the decision path explicit and resilient.
When the visible NetSuite error is not the real problem
Why I stopped treating wrong field values as field problems and started tracing the full execution path first.
NetSuite issues often present at the end of a chain: a value is wrong, an import rejects a reference, or Sandbox behaves differently from Production. The difficult part is identifying which layer actually owns the symptom.
The “simple CSV cleanup” that became a relationship rebuild
A migration where the real problem was not headers—it was environment-specific references, duplicates, and relationships.
What looked like a handful of import errors turned into reconciling destination records, correcting cross-environment references, rebuilding customer/contact relationships, and verifying the final NetSuite state rather than trusting the import results alone.
When “fix the PDF” is really a process-design problem
Advanced PDF/HTML, FreeMarker, SFTP, and payment/output work all taught the same lesson: design from the consumer backward.
A visually small print-template request can hide questions about source data, package-level information, downstream files, bank requirements, and what should be manual versus automated. The useful work starts before the template syntax.
Why good IT support starts with the environment, not the symptom
What multi-location support taught me about documentation, dependencies, endpoint problems, and solving the issue that will come back next week.
Supporting users across multiple locations made it obvious that the same visible symptom can come from identity, DNS, endpoint configuration, VoIP, permissions, or the local network. The most useful support work was often the part that made the next incident easier to diagnose.
Replacing a plugin pile with one maintainable account system
How an account-page project grew into registration, sessions, role protection, security flows, and a custom WordPress system.
The challenge was not building another login form. It was making all the account behavior feel like one product while still respecting WordPress authorization, session handling, administrative controls, and the realities of maintaining the site afterward.
Explain the engineering. Protect the implementation.
The useful part of a project story is the problem, the tradeoffs, the reasoning, the technologies involved, and what changed in my approach afterward. Publishing a client’s private mechanics adds very little value to that story.
01
Describe the problem clearly
Enough context to understand why the work mattered without exposing internal business structure.
02
Explain the reasoning
What I tried, what became difficult, what I changed, and why the final approach made more sense.
03
Keep private details private
No private code, credentials, exact approval hierarchies, record IDs, proprietary documents, account information, or sensitive configuration.
