From a business problem to a product people use
Product engineering is deciding what the software should do, and just as often what it should not do yet.
Principles I write down first
OrderRestro began with a short list of non-negotiables: offline-first, granular permissions everywhere, server-authoritative money, modular domains. A written principle gives me something to refuse a shortcut against six months later.
Separate products for separate domains
NodeDR POS and OrderRestro share lessons but not a schema, because restaurant operations and retail billing are different problems. Forcing one model to serve both would have weakened both.
Honest scope
My changelogs and roadmaps say what is shipped and what is not built. Rechvix's changelog records known gaps and a newly disclosed vulnerability in a third-party library that I had not yet fixed. I would rather the record be accurate than flattering.
Distribution is part of the product
Installers for Windows and Debian, Microsoft Store listings, CasaOS apps, a one-command Docker install, a quick-start script and written manuals are all part of the product, because software that cannot be installed has no users.
Building in the open
Most of my products are AGPL-3.0 open source. Publishing the code and the architecture decisions keeps me honest, and it lets other developers check my reasoning.