Founder notes
Lessons learned from building products and services over the years, short essays on this site, not the technical blog.
For architecture and engineering posts, see technical writing.
A good MVP is not a smaller version of the dream product. It is the smallest version that can prove somebody cares.
Read noteThe best product ideas are usually not sexy. They come from repeated pain: lost follow-ups, messy spreadsheets, unclear processes, duplicated work, and decisions nobody can trace.
Read noteYou can polish the landing page, improve the UI, and add AI—but if the buyer does not recognize the problem immediately, you are still guessing.
Read noteSome ideas are products, some are consulting offers, and some are internal tools. Treating all of them like venture-scale software is how solo founders waste months.
Read noteThey need boring infrastructure, clear ownership, fewer moving parts, and enough discipline to avoid creating problems they cannot afford to maintain.
Read noteConsulting teaches where the pain is, how people buy, what language they use, and what they are willing to pay for. Productizing too early can hide those signals.
Read noteMost small businesses do not need enterprise software. They need software that removes friction without forcing them to become software operators.
Read noteThe hard part is not adding an LLM. The hard part is making the feature reliable, private, explainable, affordable, and useful after the first impressive demo.
Read noteYour price says who the product is for, what problem it solves, and how seriously the customer should take it. Bad pricing creates bad customers.
Read noteScaling too early is not preparation. Sometimes it is just expensive procrastination with better architecture diagrams.
Read noteAuth, permissions, billing, logs, backups, onboarding, support, limits, retries, and documentation are not secondary. They are the difference between a demo and a business.
Read noteThings will break. The question is not whether the system is perfect. The question is whether you can understand it, fix it, and keep moving without a team of specialists.
Read noteEvery queue, service, abstraction, integration, and dashboard feels reasonable when you add it. The cost appears later, usually when you are alone maintaining it.
Read noteThe moat is distribution, trust, taste, speed, domain understanding, and knowing which problems are worth solving. The stack only helps you get there.
Read noteMost dashboards show activity. Good dashboards create clarity. If nobody acts differently after seeing the data, it is probably decoration.
Read note