An Unexpected Journey
Building software means building a software enterprise
My name is Andy, and I am an engineer.
I’ve recently become infatuated with the idea of building in public, inspired by cursory glances and skimming the writings of Pieter Levels (@levelsio) and Arvid Kahl. Both men practice building in public.
I have an unfair advantage and a liability:
My unfair advantage? Levels and others started their build-in-public journey as unknowns. I experienced the same unknown-ness 20 years ago, but was blessed to join a talented team of authors for my first book project, and then blessed again when that book sold as well as it did. These days I enjoy 20+ years’ experience working with SSIS, over a dozen books with my name on the cover, MVP history, a standing audience, and a popular (in SSIS, ADF, and Fabric Data Factory circles, at least) blog. The audience-building half of the playbook, the part that gets attention because it’s the most dramatic, is the half I’ve already lived.
My liability? Levels and I both spent years building exactly the thing I tend to neglect in my copy out of modesty.
I'd never write those two previous paragraphs about myself.
After reading a draft of this article, Claude wrote them and told me to quit being modest.
So, fine.
If you know me at all, you know I’m not comfortable sharing stuff like the paragraphs above. Exhibit A is a blog post titled Andy Frickin’ Leonard.
Onward.
Building DILM Suite
A funny thing happened on the way to building DILM Suite software.
Kent Bradshaw and I also had to build a software company named DILM Suite.
This meant more than registering a domain and standing up an online shop. It meant building the tools to manage a software enterprise.
AI - specifically Claude Code, ChatGPT, and Grok - helped us build several support applications. Today I share more about Helm and include a glimpse at DILM Release Manager.
Helm
The screenshot above is a peek behind the curtain at DILM Suite. The careful observer will note redactions. I can hear some of you thinking:
“So, while ‘building-in-public’ you are not going to be fully transparent, then, Andy?”
No.
Helm is an internal project Kent and I use to keep track of on-going projects at DILM Suite. We designed Helm using Claude Code. You can see Helm references the project named Helm in the category DILM-Internal. It’s right there in the screenshot. How meta.
Helm is a force multiplier and time-saver. It’s the first application I open each day when I fire up my Dev VM.
From Helm, I right-click a project and click “Launch Claude Code” from a context menu (not pictured). This morning, I right-clicked one of the redacted projects and clicked “Launch Claude Code” because that particular project is my main focus these days.
After Claude Code opens on my VM, I let it run through it’s auto-update routine. This usually takes 30-90 seconds. Then, I close the terminal, right-click a project in Helm (again), and then click “Launch Claude Code” (again). Most mornings, I see a different Claude Code version number. This morning, Claude Code looks like this:
Two clicks open Claude Code for me, so it’s easier to just shut down the terminal and start another one - at least for a fresh terminal post-morning-update. I still use /clear to manage context when collaborating with Claude Code. Firing a /clear command is different from restarting the session from scratch.
Preserving my context
At the end of each day, I prompt Claude Code to update MEMORY.md, CLAUDE.md, and other related files in preparation for restarting the next session and answering the question, “Where were we?”
If I stop at a spot where Claude Code was suggesting a next step, I capture that next step and add it to Next Notes in the Project Detail:
Other apps exist
“Paranoia is an engineering virtue.” - Andy Leonard, circa ~2005
I can hear some of you thinking, “Why not use other productivity apps for this, Andy?” That’s a fair question. If you will permit me, I’d like to ask you a couple questions:
Where do those apps store the information about my internal projects and plans?
How secure is their storage?
(Bonus question): How many months (years?) from now will I get a letter in the mail informing me of the data breach that occurred last month?
For goodness’ sake, people, I do data for a living!
I’ve lived a while now.
And I’ve been developing software for over half a century.
Helm data lives in a SQLite instance on the Dev VM.
I have maybe 4 hours to date invested in building and maintaining Helm.
I estimate Helm has saved me multiples of that 4 hour investment.
Speaking of other apps…
If you look through the list of unredacted projects, you’ll see other projects we use internally to manage the software business.
The most comprehensive application is DILM Suite Release Manager. DRM does what it says: It facilitates our build process from soup to nuts. While I won’t share all the steps DRM performs for us, I will share one powerful statistic: Kent or I can build and release the full stack of DILM Suite applications - including components (NotificationAdmin, DILMLicense) shared across most of the “surface” applications (SSIS Catalog Compare, SSIS Framework) - in less than 30 minutes.
This process starts with git identifying which component projects have been updated since the previous release and ends with automated setup files deployed to the website.
DRM makes DILM Suite practitioners of CI/CD. On steroids.
"I've lived a while now." Up there with "The ocean has some depth to it." 😀