Forem: Luke

From #96 to #12 on ProductHunt: What I Learned

Luke — Thu, 22 Jan 2026 14:44:31 +0000

Hi, I'm Luke. I'm a software developer and entrepreneur.

I've launched a handful of products in my life, the biggest ones being MyMobileMods, Biblify.ai, and now Doclific.

Each one of these projects I did entirely by myself. No graphic designers. No UI/UX designers. Nothing.

When I originally launched MyMobileMods, my first project, this was my ProductHunt listing. I essentially just added some horrible screenshots and a random video I made. I didn't explain the product particularly well. I asked all my family members and friends to make accounts and upvote it (big mistake). It did alright; maybe top 100, but was hidden early on and lost its rank because of the "spam" accounts (really just my friends and family) that upvoted it. The product itself was buggy and, honestly, kind of ugly. I should have taken more time to polish it before launching.

After that, I launched Biblify.ai: https://www.producthunt.com/products/biblify-ai. This product was objectively better than MyMobileMods. It was more polished and genuinely useful. However, I still put no effort into the images, only uploading a single screenshot/mockup of the application. It ended up getting a handful of upvotes, ranking #96 for the day.

Today, I launched Doclific: https://www.producthunt.com/products/doclific. Yes, it's still early in the day, but it looks pretty likely that I'll end up in at least the top 15 products for the day. Not bad. Here's what changed:

I focused on my images and content. I paid $30 to use Screen Studio on Mac (an amazing product btw). This allowed me to create amazing screen recordings and beautiful screenshots too. I learned how to use Figma and spent hours perfecting my images and screen recordings. From a technical perspective, these tasks seem unimportant, but I'm slowly discovering that if you're going to be a solopreneur, it's essential. You can't just focus on the parts you like. In fact, you should probably be spending extra time on the parts you don't like because you're probably worse at them.
I still sent the ProductHunt link to people, but I chose them more carefully. People already in the tech space or people were the best options. I avoided people not in that space and people that don't already have an account. It's not the worth the risk of potentially getting shadow banned or unranked.
I posted on LinkedIn. This was actually a decent help. As long as you have a decent post, LinkedIn will share it with randos, so I actually got some decent engagement from that. I also posted multiple times already.

If you have any other suggestions or just questions, I'd love to hear them.

Checksums: What They Are, Why They Matter, and Where They Belong in Your Release Pipeline

Luke — Wed, 14 Jan 2026 23:57:51 +0000

When you distribute software—especially binaries—you’re making an implicit promise: this file is exactly what I intended to ship. Checksums are how you keep that promise.

In this article we’ll go through what checksums are, why they matter, and how to add them to your own open source project. Let’s get started!

What is a checksum?

A checksum is a fixed-length value derived from a file’s contents using a cryptographic hash function. SHA256 is the gold standard, so unless you have a specific reason to use another algorithm, best to stick with SHA256. If even a single byte of the file changes, the checksum changes completely. After downloading the file, the checksum can be computed and compared against the advertised value. Thus, a checksum is basically a way of saying “yes, this program is what it claims to be.”

To summarize…

Checksums (in this context) can…

Detect corruption after downloading a file
Detect tampering after downloading a file
Provide confidence to end users

Checksums cannot…

Prove who created the file
Protect against malicious servers publishing a tampered with file and corresponding checksum

A note on package managers

You may be wondering if you’re currently as risk for any attacks or malware because of the 20,000 npm packages you installed within the past couple minutes. However, nearly all package managers have some sort of safety net that verifies the integrity of the download before installing. Binaries that are not distributed by a package manager (via GitHub releases and the like) don’t have that built in. Just something to keep in mind.

Adding checksums to your project

Adding checksums to your open source project is actually quite simple. Just make sure you put them in the right place or they won’t work.

Build artifacts
↓
Package artifacts (tar.gz, zip, binaries)
↓
Generate checksums
↓
Publish artifacts + checksums
↓
Create release

My current project, Doclific, uses a single file (checksums.txt) containing the checksums followed by two spaces, then the specific file.

a21bd2e10abbdb057e8acd91a331b5ff6e187e845031f22d0117927e276d6b4f  doclific-v0.1.1-darwin-amd64.tar.gz
a8c91ead81f402e380293f9a0fa6cf56cf380782dbfdff9bc604548bf14a35da  doclific-v0.1.1-darwin-arm64.tar.gz
499224f4d05f023c560978c6fff2bbb381b7425e742e0b5b3c4b54068d7f6dfb  doclific-v0.1.1-linux-amd64.tar.gz
1913c0669ec383133e8460a0be9df43e285a5ebc39928e62c86fcb6c9b486665  doclific-v0.1.1-linux-arm64.tar.gz

I generate the file in my release.sh file which runs every time I create a new release.

echo "🔐 Generating checksums"
cd "$DIST_DIR"
shasum -a 256 * > checksums.txt

Then when the user runs the command curl -fsSL https://raw.githubusercontent.com/muellerluke/doclific/main/scripts/install.sh | bash it will pull the install.sh script and run it. Inside the install script, it generates a checksum based upon the downloaded file and checks to make sure it matches that of the hosted checksum.txt file in the release.

info "Verifying checksum..."

# Determine command
if command -v sha256sum >/dev/null 2>&1; then
    CHECKSUM_CMD="sha256sum -c -"
elif command -v shasum >/dev/null 2>&1; then
    CHECKSUM_CMD="shasum -a 256 -c -"
else
    err "No SHA256 checksum tool found. Please install sha256sum or shasum."
fi

# Run checksum verification
grep "$ARCHIVE" "$CHECKSUM_FILE" | $CHECKSUM_CMD || err "Checksum verification failed"

Note: some OS version may or may not have shasum installed, so I first check to see if it is or use sha256 if it is not.

Closing thoughts

Again, if you're distributing software via a package manager, you generally don't have to worry about this. However, if you're distributing a binary outside of a package manager using curl or something else, then implementing checksums will provide an added layer of security and confidence for your end users.

Switching from TS to Go

Luke — Wed, 14 Jan 2026 19:07:14 +0000

I recently built my first open-source project. It's called "Doclific" and it was originally an NPM module that could be used in the CLI to start a notion-like documentation editor. It worked great and got over 2k downloads in the first month. However, I soon realized that by keeping it as an NPM package, I could potentially be alienating quite a few devs. Thus, I started the journey of transitioning the TypeScript and oRPC backend into Golang...

To begin, it took a little bit to figure out how I wanted to structure the project originally. I'm familiar with how to structure Node projects, but not as familiar with Go. There were definitely some nuances, but eventually I figured it out.

The actual server setup, routes, and controllers were fairly simple as well. Coming from TypeScript primarily, it was easy to translate.

The hard parts came from the shell scripts needed for creating the releases and install. I'm not much of a bash guy, so this was a pain.

One thing I became more familiar with was checksum verification. When the release script runs, it generates a hash for the built files.

# ----------------------------
# Generate checksums
# ----------------------------
echo "🔐 Generating checksums"
cd "$DIST_DIR"
shasum -a 256 * > checksums.txt
cd ..

After that, when a user installs it, it will verify that the checksum of the install matches that of the checksum in GitHub.

# -----------------------------
# Verify checksum
# -----------------------------
info "Verifying checksum..."

# Determine command
if command -v sha256sum >/dev/null 2>&1; then
    CHECKSUM_CMD="sha256sum -c -"
elif command -v shasum >/dev/null 2>&1; then
    CHECKSUM_CMD="shasum -a 256 -c -"
else
    err "No SHA256 checksum tool found. Please install sha256sum or shasum."
fi

# Run checksum verification
grep "$ARCHIVE" "$CHECKSUM_FILE" | $CHECKSUM_CMD || err "Checksum verification failed"

Previously, when a user wanted to download Doclific, they would have to use this command npm i -g doclific -- meaning they would have to have npm/node installed. Now, it can be installed with curl -fsSL https://raw.githubusercontent.com/muellerluke/doclific/main/scripts/install.sh | bash -- making it more accessible.

If you have any thoughts or suggestions, leave a comment!

STOP DOING KT SESSIONS

Luke — Tue, 06 Jan 2026 14:42:13 +0000

STOP IT. STOP IT NOW.

For The Uninitiated...

For those of you uninitiated, KT sessions are these long (sometimes 3+ hours) and painful live and recorded sessions where a certain person with a certain level of knowledge on a project goes through the entire project trying to explain things.

KT Sessions in Practice

In practice they're essentially useless. Nobody is actually paying attention. Nobody will go back and watch them in the future (unless forced to do so). Nobody wants to talk for that long. Given the fact that the person giving the KT session also didn't prepare for it, there's usually also a large amount of rambling and circular explanations. They're essentially useless.

However, with AI now, they are slightly less useless. Instead of listening for the 4+ hours to find the minute detail you're looking for, you can just search the AI-generated notes. However, this only solves that specific problem. Even if you find what you're looking for in the notes, you still probably don't know which files are being referenced or, even if you do know which files are being referenced, the files have almost definitely changed since the recording. Again, KT sessions suck.

The Solution (is there one?)

In my several years of software development, I haven't really found a good alternative. There are tools like Readme files, but nobody really wants to mess with those. They're just not pretty and not fun.

After thinking about this for quite some time, I built a new open source tool in the hopes of at least limiting the frequency and duration of these KT sessions. It's called "doclific" and is available as an NPM package. It's essentially a notion-like rich text editor where the docs live in your repo. You can easily reference snippets of code and the snippets update automatically if you make changes to the code.

My Blunder

After building what I thought was an awesome tool, I realized limiting or even getting rid of KT sessions is like trying to get the sun not to rise. It's impossible. They're simply a right of passage. Yes, they are horrible, but what better way to understand the new company you're starting for than to listen to the most boring person ever speak in a monotone voice for four hours talking about a codebase you don't even have access to. Here in lies the true genius of the profession we all love.

Documentation Sucks (I may have made it suck less)

Luke — Tue, 23 Dec 2025 01:54:17 +0000

The Story Behind It

Technical documentation sucks. We all know it. Yet, we all continue to use the same tools over and over again. I recently took a new position, and one of the tasks I have before I leave my current company is essentially documentation hell -- basically document all parts of every project you're on. It's a lot.

For this type of technical documentation, you generally have three options:

A long a painful video that no one will ever actually listen through fully.
Adding a bunch of readme's (boring and just as painful).
Using something like notion and copying over snippets.

I know there are other tools out there, but I haven't found many that really merge the code with the rich text well to create a visually appealing editor and reader. Naturally, I decided to create my own...

The Product

It didn't take long -- maybe 3-4 weeks total -- but I ended up creating a decent documentation solution. It's called "Doclific" and is available as an npm package right now. It's free, open source, and a relatively simple codebase to navigate through.

It's basically what it would look like if Git and Notion had a baby. It's a pretty editor with a hierarchy structure for notes. It has slash commands. It has direct snippet references (no more copying and pasting). It's AI-enabled, just add your provider, model, and key. Best of all, it lives in your codebase -- no additional expense or outside documentation to maintain.

My Favorite Features

My favorite feature by far is the code snippet element. You can easily add it with the slash command, then find the specific file you want to reference through the editor, select the lines, and it'll display it right every time. If you change the code in your codebase, it'll reflect the changes next time you load up your Doclific. Additionally, each snippet has an attached link. When readers click the link, it opens a new VS Code window with the file and the cursor on the specified line. It makes finding and navigating through files very easy.

The AI integration is an AMAZING feature IMO -- and something not offered by other products in the space. Prompt it to generate documentation on a specific workflow and the agent will find the relevant files, select the applicable lines, add descriptions, headers, etc, and add it all to your doc with the code snippets.

Thank You's

Huge thanks to the maintainers of Platejs. They have many amazing rich text editor components.

Closing Words

Let me know your thoughts on this tool. If you have any suggestions or issues, let me know!