Why I Built nollejCraft: A CDO's Journey from Patchwork to Platform

The entire month of September 2025 is a blur. I'd just finished building a programming language during that 30 days. DAZL, a complete analytics environment with 30+ language steps for data management, statistical analysis, and business intelligence was working beautifully, and poised to help me with new client work that's on the horizon.

Behind the scenes, however, things are a bit uglier. My main site, HBGConsulting.com needs a facelift. And I have new capabilities to showcase. But I couldn't remember the wordpress password to update the blog. Again.

That's the cobbler's kids problem in a nutshell. While I was consulting with clients on data systems and strategic infrastructure, my own digital presence was held together with duct tape and good intentions. Like most small consulting shops, client work always takes priority over internal operations. Seems ironic now that I'm writing about it. And this needed fixed.

The Full Picture of Dysfunction

Let me paint the scene. HBG Consulting's web presence was a patchwork:

The blog: A three-year-old WordPress installation, disconnected from the rest of the site but "roughly forced to look integrated." Every time I wanted to publish an article, I'd reset my password. Not because I'm careless. I use unique passwords for every system and don't trust password managers as single-point attack surfaces. The real problem was deeper: it was too inconvenient to add content regularly, which meant my content marketing strategy existed mostly in theory.
The main site: Static HTML and CSS pages administered by logging into cPanel and editing PHP files directly. Professional enough, but inflexible and slow to update.
Landing pages and lead capture: Custom PHP code for every single form, every single campaign. Total control over workflow, yes. But also total technical debt. Each new lead magnet meant writing more custom integration code to my CRM.
Documentation crisis: With DAZL launched, I suddenly needed to document language specs, syntax, examples, reference materials, statistical procedures, data joins, cube operations—an entire ecosystem of capabilities. Traditional documents on a shared drive weren't going to cut it. I needed something like a dynamic wiki with cross-references, examples linked to concepts, and the ability to update rapidly as the language evolved.

Each problem was manageable on its own. Together, they revealed a deeper problem: I was running on infrastructure that couldn't scale, couldn't adapt, and couldn't provide any insight into what was actually working. And that's NOT what I do for my clients.

I could patch again. Or I could solve the root problem.

Design Principles Over Tools

Here's where I had to step back and leverage my fractional CDO thinking about my own business. Rather than evaluating CMS platforms or marketing automation suites, I took the time to document what I really needed, noting the constraints and taking core principles into account. I had to get all my requirements out of my head. Only then could I start shopping for a tool that meets my needs, or build something custom if the trade-off / balance became obvious.

One SQL table. That was the foundation.

Most CMS platforms are architectural beasts. They are complex, impressive, and ultimately inflexible. I needed a well-designed organizational model that did exactly what was supposed to do. One database table to store documents. Markdown for writing. HTML when needed. A handful of single-task utilities that work well together, rather than a large complex system:

the sql table that stores the pages and properties about each page
the CRUD utility to manage that table
a front controller that captures the URL parts and finds the matching page in the table
a dynamic top navigation bar that is built from the list of published documents in the table
a projectLib file that contains useful functions

Why this approach?

A few reasons that matter strategically:

Lightweight: One data table and 4 programs (less than 1000 lines of PHP code) is about as lightweight of a website and blog management system as one could possibly build. NOTE: As you'll see later in this article, a few more modules and data tables were added out of necessity, but strategically planned.
Maintainability: No plugin conflicts. No mysterious dependency hell. No vendor updates that break production on a Friday afternoon. I understand every component because I built each one to solve a specific problem.
Agility: New capabilities take days, not quarters. When I need a feature, I write a focused utility. Simple architecture enables fast iteration.
- Front-end login credentials? Repurposed from a recent client project.
- The forms manager? About 200 lines of code.
- The shortcode handler? A weekend project.
Transparency: No black-box SaaS platforms. No vendor lock-in. No licensing negotiations. Just clear code doing clear work on a shared hosting plan that costs $12 a month.

Insight: The design philosophy came from 40 years of building systems.

Keep components single-task focused

Use metadata to drive behavior

Make the customer experience frictionless by hiding complexity, not by dumbing things down

Building As A Discovery Process

I started with the documentation problem because it was urgent. DAZL needed specs, tutorials, examples, and reference material—all of it searchable, cross-linked, and easy to update.

Markdown made sense for authoring. HTML gave me formatting control. A single SQL table stored everything with metadata tags for categorization. Within a week, I had a working documentation system inside the DAZL Studio IDE. For my eyes only, but battle-tested with over 100 documents, a CRUD utility for data management, and a front-end file presenter. The DAZL 'wiki' was working perfectly, easy to maintain, easy to link related documents, beautifully rendered pages, easy to search and navigate.

Then came the pivot point.

I decided to expose the DAZL documentation publicly at nollejBase.com/dazlStudio/documentation . Once it was live and working in production for real users, real traffic, and real content I had my "aha" moment: A copy of this same system could replace the WordPress blog.

So I made a copy of the documentation tool and repurposed it. Instead of managing language specs, this version would manage web pages. Instead of private/internal visibility flags, I needed public, registered-user, paid-tier, and admin access levels. The adjustments took a focused few hours.

As I started migrating blog articles, I realized I could include HTML alongside markdown. That's when the second "aha" hit: This could manage the entire site, not just the blog. The entire site needs a facelift. I've added new capabilities, updated color scheme, etc.

But content management alone wasn't enough. I needed to collect survey responses and contact information. I needed forms, and lots of them, in different contexts, capturing different data. And I needed them embedded seamlessly into pages without writing custom code every single time.

Shortcodes were born.

The Concept: Place [ form id="subscribeToEmail" ] anywhere in a document, and a shortcode handler finds it, retrieves the form definition, renders it, and processes submissions.

A mini-program triggered by a few characters of markup

No custom code

No template changes

Just a clean, consistent pattern

The first version of the [ form ] <input ....> [ /form ] worked great, and proved the shortcode handler was a viable solution.

The next evolution to forms became obvious

I needed a forms management system to create, edit, and track forms and responses. Two tables. Done. Another focused utility in the record books.

Then a campaign manager was next. This generates UTM-tagged URLs for social media, email, and other channels, then integrates those parameters with page view logs to understand what drives traffic. Another one done. Two simple tables, straightforward logic.

The final step of making the campaign manager useful: adding one more table to track all pages visited, along with the UTM tags that might be in the URL. And with that table comes a couple more utility functions.

At this point, the first refactoring of the front controller was needed. I'd packed in new capabilities without re-organizing the overall structure of this one important program. Now I'm ready to add more modules if the need arises.

Most recently, I added a [ dazl ]...[ /dazl ] shortcode that passes embedded scripts to the DAZL interpreter and returns results in place. Any page on HBGConsulting.com can become an interactive analytics environment, a live dashboard, or a data-driven insight engine. Static content and dynamic analysis unified in the same platform.

Note: Realistically, I'm probably reserving the DAZL scripts for admin dashboard work

Lessons Learned So Far

Each capability emerged from a real need, not theoretical planning. And because the core architecture stayed simple with just one main page table and modular utilities, adding features didn't create bloat or fragility. It created composability. I can work on a new module without breaking anything else in the system. I'll be the only one using that module as site admin, until I decide if and when that module needs to be visible to other visitors. At that point I publish a public facing page the shows off the new capability. Otherwise page visitors have no idea what they cannot see, and the development of any tools in that state don't affect anyone else's experience on the site.

The Ironic Validation

Here's the kicker: I'm currently building a WordPress site for a client. They have internal expertise for long-term management, so WordPress makes sense for them. But the development process is proving my point better than any case study could.

Moving from my development environment to their production site is a challenge every single time. Plugin conflicts. Theme updates that break layouts. Opaque error messages. The platform that's supposed to make web management easy actually introduces friction at every step.

Meanwhile, nollejCraft deploys instantly. Updates propagate without drama. New capabilities integrate seamlessly because I control the entire stack. I'm living both worlds simultaneously, and the contrast is stark.

Strategic Implications: What This Architecture Enables

Let's move beyond "I built a thing" and talk about what this means strategically.

Unified data capture: Every page view, form submission, campaign click, and embedded analytics script becomes a data point. Not aggregated metrics from Google Analytics, but transactional records with full context. Who came from where, what they engaged with, what actions they took—all queryable, all analyzable.
Embedded intelligence: With DAZL scripts embedded directly into pages, the platform doesn't just display content—it processes data, generates insights, and visualizes outcomes in real time. The line between content and analytics disappears.
Campaign-to-outcome visibility: UTM parameters tie directly to initiatives. I can measure which campaigns drive traffic, which content converts, and what ROI each effort produces. Not guesses. Not proxies. Actual transactional data feeding dashboards that inform strategic decisions.
No vendor lock-in: I'm not beholden to enterprise licensing, update schedules, or deprecated features. If I need something, I build it. If something breaks, I fix it. Total control, total transparency.
Cost structure: Shared hosting. No enterprise CMS fees. No marketing automation subscriptions. No analytics platform upsells. The total infrastructure cost is less than most organizations spend on coffee.

The Real Strategic Advantage: Powerful systems don't require complex infrastructure. They require clear thinking about what problems you're actually solving.

Most organizations are drowning in tool complexity. They've got a CMS for content, a marketing automation platform for campaigns, an analytics suite for tracking, a CRM for leads, and a mess of integrations holding it all together with digital baling wire. Each tool introduces cost, maintenance burden, and opacity. And when something breaks—and it will—nobody fully understands the dependencies.

The alternative is to ask: What's the minimum viable architecture that solves the actual problem? For me, it was one table and a handful of focused utilities. The result handles more capability than platforms costing 100x more—and I can enhance it faster than they can push updates.

Your Infrastructure Tells a Story

So why does this matter to you?

Because your infrastructure decisions reveal your strategic options. If your systems are fragmented, your insights will be fragmented. If your tools are opaque, your decision-making will be reactive. If your platform is inflexible, your growth will be constrained.

The cobbler's kids problem isn't just about neglect. It's about misaligned priorities and patchwork thinking. I could have kept resetting passwords, writing custom landing page code, and wishing for better analytics. Instead, I stepped back and asked what a unified, transparent, agile system would look like—then built it.

That's fractional CDO thinking in practice: See the systemic problem. Design principles before tools. Build iteratively with clear constraints. Optimize for maintainability and insight, not feature count.

Three Questions That Reveal If You're Building on Patchwork

Here's a simple diagnostic. Ask yourself:

Can you trace a prospect's journey from first click to closed deal across all your systems? If the answer involves exporting CSV files, manually matching records, or guessing at attribution, you've got a visibility problem.
When you want to launch a new campaign or content initiative, how many tools do you touch? If it's more than two, you've got a fragmentation problem.
Do you understand what's actually driving business outcomes, or are you relying on aggregated metrics that obscure more than they reveal? If you're making strategic decisions based on bounce rates and time-on-page, you've got an insight problem.

If any of these resonate, your infrastructure is probably constraining growth in ways you haven't fully mapped.

Let's Assess Whether Your Systems Enable or Constrain Strategy

I built nollejCraft because I needed it. But the principles behind it—unified data capture, embedded analytics, modular architecture, transparent ownership—apply far beyond my specific use case.

Most organizations don't need to build their own CMS. But they do need someone thinking strategically about how content, campaigns, and analytics connect. Someone who can see the difference between elegant systems and elaborate complexity. Someone who optimizes for outcomes, not tool counts.

That's the fractional CDO conversation: Not "what platform should we buy?" but "what capabilities do we actually need, and what's the simplest architecture that delivers them?"

If you're wondering whether your current infrastructure is enabling strategic growth or just holding you back with expensive duct tape, let's talk. I offer a straightforward 30-minute infrastructure assessment—no sales pitch, just a clear-eyed look at whether your systems are aligned with your goals.

Because the cobbler's kids shouldn't go barefoot. And neither should your business strategy.

Ready to assess your infrastructure? Schedule a 30-minute conversation or reach out directly at [contact info]. Let's figure out if your systems are elegant or just elaborate.