About the publisher

Michael Young Harrison

Founder and Publisher — HARRISON SAAS PUBLISHING LLC, Gastonia, North Carolina.

Why this company exists

I got tired of software that needed a committee to change a button.

I've spent years building internal tools for teams that were paying enterprise prices for products they used maybe fifteen percent of. The pattern was always the same: something small and useful gets acquired, gets a platform strategy, and six months later you can't find the export button.

So in May 2026 I started publishing under my own name and my own LLC. Every product here is something I would use myself. If it isn't, I don't ship it.

The address is real. The phone number rings my desk. When you send a support request, you're emailing the person who wrote the line of code that's giving you trouble. That's not a marketing angle — it's just how a company of one works.

$ whoami michael.harrison $ cat philosophy.txt small > bloated documented > clever answered > queued

Background

What I actually know how to do

Languages

TypeScript, Python, Go, SQL

Most of the day-to-day is TypeScript and Python. Go shows up when something needs to be fast and boring. SQL is where the real thinking happens.

Frameworks & Platforms

Node, Postgres, Docker, Linux

Postgres for anything with structure. Docker for shipping. Linux servers I configure myself, because managed platforms eventually send you a bill you didn't agree to.

Front end

Accessible HTML, CSS, vanilla JS

Not every interface needs a framework. Half the reason software feels slow is that people reach for one when a form would do.

The unglamorous parts

Docs, migrations, support, backups

Writing the code is maybe forty percent of the job. The other sixty is the work nobody demos: documentation, database migrations, answering email, and making sure last night's backup actually ran.

How I work

The methodology, if you want to call it that

Five steps, in order, every time. It's not complicated — it's just followed consistently.

  • Find a real problem Usually one I've hit myself, or a customer has described in enough detail that I can feel it.
  • Design the smallest useful tool Scope gets cut on purpose. If a feature doesn't earn its place, it doesn't get built.
  • Build and document it Documentation gets written alongside the code, not after. It's part of shipping, not a follow-up task.
  • Ship and support it Every product launches with a real support channel that reaches me directly.
  • Iterate on what people actually ask for Feedback comes from the people using the thing, not from a roadmap meeting.

The honest case for one person

Why a solo publisher is a feature, not a limitation

No committee decisions

When three customers ask for the same thing and it makes sense, it goes in. No product manager has to justify it to a director.

No feature bloat

Every feature is code I have to maintain, document, and support alone. That's a very effective filter.

Direct accountability

There's no tier of support to escalate to. If something is broken, it's mine to fix. That tends to make you care about getting it right.

Faster fixes

Bug report to shipped fix, often in the same day. There's no handoff, no triage meeting, no ticket sitting in a backlog.

Based in Gastonia

Rooted in the Charlotte metro, serving customers anywhere

The LLC is registered at 119 Ann ST in Gastonia, North Carolina — about twenty miles west of Charlotte. It's not a Delaware shell and it's not a coworking address with a mail-forwarding service. It's where the work happens.

Customers come from across the US and, increasingly, from overseas. Remote support works fine for software. But when someone wants to know where their vendor actually is, the answer here is a real place with a real phone number.