Suggestions
Brian Casel
Founder at ZipMessage
Brian Casel is a seasoned entrepreneur and the founder of ZipMessage, a platform designed for asynchronous communication through video, audio, and text messages. This tool is particularly popular among professional coaches, consultants, and remote teams, facilitating seamless client interactions and project management. In March 2023, Casel announced a rebranding of ZipMessage to Clarityflow, reflecting a strategic shift to better serve the coaching industry by enhancing user experience and functionality tailored to coaches and their clients.12
Professional Background
Casel has a robust background in software product design and development. He has founded several successful businesses, including:
- ProcessKit: A SaaS product focused on creating repeatable business processes, which he sold in January 2022.
- Audience Ops: A content marketing service for B2B companies that he exited in September 2021.
- Restaurant Engine: A website solution for the restaurant industry that he sold in 2015.
His career began as a web designer, where he provided consulting services before transitioning into product development.134
Contributions and Influence
In addition to his entrepreneurial ventures, Casel is active in the podcasting community. He hosts shows like Bootstrapped Web and Open Threadds, where he discusses insights from his experiences in software and design.13 His approach often emphasizes building in public, sharing progress and lessons learned from his various projects.
Overall, Brian Casel has established himself as a significant player in the SaaS landscape, leveraging his expertise to create tools that enhance communication and operational efficiency for businesses.
Highlights
When architecting a new web app, I try to stick to our V1 scope and avoid overbuilding things before we need them.
Examples:
- Building features "just in case" users ask for them later.
- Over-engineering features for scalability that won't be a concern for years.
- Laying groundwork for features we might build later.
...With one exception:
Separating Users from Accounts.
If you ever need to allow users to belong to organizations, and/or organizations having many users who use a single account in your web app, then you'll need to have the Users and Accounts databases separated, along with the ability to associate users with Accounts.
Your V1 scope might not call for this! So it's easy enough to only spin up a Users table, in the name of "stick to the scope!".
But later on, if you ever need to build account settings, multiple users (invites), or multi-account switching, this will be a very complicated (read: expensive and time consuming!) refactoring.
It's not much extra work to simply create both a Users and Accounts table from day one, along with a simple association. You can even wait on building the interfaces for user invites and account switching.
Some best practices have exceptions :)
