Naming a developer tool: why lowercase won

Naming a product feels trivial until you notice it touches everything: your domain, your npm package, your import statements, your legal filings, your social handles, and every conversation anyone will ever have about the thing. We spent more time on it than we’d like to admit, most of it saying candidate names out loud in fake sentences like “just check the smplkit dashboard” to see which ones survived.

Here’s where we landed and why.

The platform name: smplkit

All lowercase. No camelCase, no PascalCase, no hyphens. Just smplkit.

Look at the register developers actually live in: terraform, kubernetes, docker, redis, nginx, sqlite, fastapi. Lowercase is the default for tools that get typed in terminals, imported in code, and referenced in docs. SmplKit or SMPLKIT would work fine in a marketing headline and feel wrong in a pip install command, and the pip install is where the name will spend its life.

The missing vowels are deliberate too. “Simple Kit” is descriptive and forgettable; smplkit is compact and distinctive, the same trick that made Flickr and Tumblr stick. You process it as a shape, not a sentence.

Product names: the Smpl prefix

Products are the Smpl prefix plus one capitalized noun: Smpl Config, Smpl Flags, Smpl Jobs, Smpl Logging. See “Smpl” followed by a noun, and you know it’s ours — a pattern that scales to any number of products without collisions. And when nobody knows who you are yet, family naming is free brand reinforcement: every mention of Smpl Config is also a mention of Smpl.

One word per product, and the word is what it does. Config, not Configuration Manager. Flags, not Feature Flag Service. This is a vaccine against the enterprise-naming disease where products accrete four-word names that everyone privately shortens anyway.

Inside the developer console we drop the prefix entirely — the sidebar just says Config, Flags, Logging, because once you’re inside smplkit the brand context is established. The full names are for the outside world.

What we rejected

PascalCase (SmplKit) went first, for the terminal reasons above. Then a round of independent product names, every product its own unrelated brand, the way AWS does DynamoDB and Lambda. That works when you’re AWS; when you’re a startup, it means marketing a handful of unknown names instead of one. Last to go were the abstract names — the Vex-Prion-Axiom genre — which are fashionable and force you to explain what the product does in every sentence that contains it. “Smpl Config” answers the question before it’s asked; a developer who has never heard of us can guess what it does from the name alone.

Naming principles for developer tools

If you’re naming your own:

Optimize for the terminal, not the boardroom. The name will appear in import statements and CLI commands orders of magnitude more often than in a slide deck. Lowercase, no spaces, no special characters.

Be self-documenting when possible. Every minute a developer spends decoding your name is a minute they’re not evaluating your product.

One word per product. If it doesn’t fit in one noun, the scope might be too broad.

Consistency over creativity for families. A pattern that works for three products will work for thirty.

The name you’ll live with

Naming decisions feel reversible and aren’t. The name ends up in package registries, domain records, customer configurations, Stack Overflow answers, and other people’s codebases — renaming after you have users is technically possible and practically agonizing. So write the candidate into every context it will live in: a pip install, an import, a headline, a Slack message, a support email. If it looks wrong anywhere, keep iterating.

We’re happy with smplkit. It works everywhere we’ve typed it.