Software development doesn't have to be fast. Often times, slowness is the right approach to delivering quality. The modern world has seen a shift towards agile development practices, with its emphasis on speed, constant iteration, and fast feedback loops. However, a continuous focus on rapid development can lead to burnout and overlook the importance of pausing to reflect and realign.

In the new post-COVID norm, with days running together with endless video calls, time, for many, began to lose meaning. For those of us working from home, our online hours provided structure to otherwise shapeless swaths of minutes and days. That is, until those hours online began to blend together too, and the days, weeks, and months fused into a single blur. 

It's happened to me, and I'm sure multiple teammates and colleagues of mine would agree as well. At work, daily stand-ups began to feel scripted, each sprint indistinguishable from the last. My team planned and shipped new features at a rapid clip, but the work began to feel never-ending. This constant, iterative development is a hallmark of the agile process, the standard for software development today—but if you’re anything like me, the past couple of years have left you wondering whether it’s actually useful. Maybe, in our emphasis on incremental development, we’ve overlooked an essential element: the space to slow down.

Agile development involves building software incrementally, allowing teams to react swiftly to user feedback and adjust products as needed. This iterative process generates momentum, with each sprint moving the software closer to its ideal state. However, continuously adding small features can become monotonous and lead to burnout, especially for mature, feature-complete projects.

The waterfall method, although less nimble than agile, incorporated milestones as a way to delineate project phases and allocate time for reflection. While agile development has retrospectives, these meetings are often seen as procedural and unproductive, diminishing their effectiveness.

Introducing milestones into the agile process can provide teams with dedicated time to pause, reflect, and plan for the next phase of development. By implementing milestones after several sprints or at regular intervals, teams can break from the sprint cycle and refocus on the bigger picture.

By integrating milestones into agile development, teams can create room for introspection and holistic consideration of products and processes. This blend of agile practices with elements of the waterfall method can establish a steady, sustainable rhythm, promoting better software development and a healthier work-life balance.

As someone who has spent over a decade in the tech industry building SaaS applications, I've learned that incorporating "teams" or multi-tenant functionality from the very beginning is crucial. It's a lesson many developers overlook, leading to significant challenges and user frustration down the line.

You might think, "My app is simple and designed for individual users. Do I really need to consider teams right now?" The answer is a resounding yes. Even seemingly straightforward applications, like a bookmark manager, eventually encounter users who want to share access—be it with family members, colleagues, or assistants. Humans are inherently social creatures, and our software needs to reflect that reality.

The Importance of Modeling Human Relationships

When we create software, we're essentially modeling aspects of the real world. If we neglect the concept of human relationships, we introduce a disconnect between how people naturally interact and how they use our applications. This mismatch can lead to user frustration and limit the potential growth of your product.

By incorporating teams functionality from the outset, you align your application with users' expectations and needs. It also saves you from the complex and often painful process of retrofitting this capability later on—a task that can consume significant time and resources.

Choosing the Right Foundation: "Organization" as Your Top-Level Entity

A critical step in building multi-tenant functionality is deciding what to call your top-level entity—the container that represents a group of users and their shared resources. Common terms include "Account," "Team," "Company," "Tenant," and "Workspace." Each has its drawbacks. For example:

Account can be confusing, as users might associate it with their personal login credentials.

Team might not be ideal if you plan to support multiple teams within a larger entity.

Company is too narrow if your users aren't all businesses.

Tenant isn't user-friendly or commonly understood outside technical circles.

Workspace is flexible but might be better suited as a sub-division within a larger group.

I recommend using "Organization" as your top-level entity. It's a versatile term that encompasses various types of groups, whether they're businesses, non-profits, or informal collectives. This choice sets a solid foundation for your application's data model and helps avoid confusion as your product evolves.

Different applications handle user access in various ways. Some allow a single user account to access multiple organizations (like GitHub), while others require separate accounts for each organization (similar to some Google services). There's also the approach used by the Linear app, which combines elements of both models. It allows users to access multiple organizations from a single account while also supporting separate accounts when necessary.

For most SaaS startups, a flexible model similar to the one used by the Linear app is ideal. It provides the best of both worlds, accommodating both individual and organizational use cases without imposing unnecessary constraints on the user.

In a multi-tenant system, it's essential to ensure that each organization's data is securely isolated from others. Think of it like an apartment building: residents share common spaces but have private living areas with controlled access. Your application should allow for similar isolation and shared access, supporting both individual use and collaboration within and across organizations.

Most resources in your application should belong to an organization rather than to individual users. This structure simplifies data management and enhances security. It also makes it easier to implement features like assigning tasks or projects to specific team members within an organization.

A critical aspect of multi-tenant functionality is the user experience around switching between organizations. Users should be able to move from one organization to another without having to log out and log back in. This seamless transition enhances usability, especially for consultants, freelancers, or anyone who collaborates with multiple organizations.

Implementing this requires thoughtful session management and authentication design. By allowing concurrent user sessions across multiple organizations, you provide a smoother and more intuitive experience that can set your product apart from competitors.

When it comes to billing, tie your subscriptions and payments to the organization rather than individual users. This approach aligns with how businesses manage expenses and simplifies account management for your customers.

Similarly, distinguish between global user settings and organization-specific settings. Global settings might include personal preferences like display themes, while organization-specific settings could cover notification preferences or role-based permissions. This separation ensures that users have a consistent experience across different organizations while still accommodating the unique needs of each group.

Implementing organization-level analytics from the start is vital. It not only helps you understand how your product is used but also provides valuable insights to your customers. By tracking usage patterns, you can make data-driven decisions to enhance your application and demonstrate value to your clients.

Designing your system with scalability in mind will save you from costly refactoring efforts in the future. Consider supporting features like parent-child organization relationships or accommodating various organization types. This foresight positions your product to handle increased complexity as your user base grows.

Integrating "teams" functionality from day one isn't just a technical decision—it's a strategic move that positions your SaaS product for long-term success. It aligns your software with the collaborative nature of how people work today, enhances user satisfaction, and makes your product more adaptable to a variety of use cases.

By anticipating your users' needs and building a flexible, multi-tenant architecture from the outset, you'll save yourself significant headaches down the line. More importantly, you'll create a product that not only meets but exceeds user expectations, setting the stage for sustained growth and success in the competitive SaaS landscape.

Building Multi-Tenant SaaS: Why "Teams" Functionality Should Be Day One Priority

Well, we've already made it a third of the way through the year. I'm wrapping up my honeymoon as I type this, and taking a break from work has been a nice refresh. It allows me to catch up on books and articles I've saved for later, and take a step back for a bit to refresh my perspective.

Recently, my preferred platform for media consumption has become Substack. I've just been gobbling up some great content on there! It's inspired me to sit back down at the old virtual writing desk, and take a stab at sharing some of what I've learned and found interesting recently with others who may fall in my digital bubble. In this post, I feel like writing about games, artificial intelligence, and compliments.

Here is a set of learning resources that I've put together on artificial intelligence, that should be fairly easy to digest, even if you aren't super technical:

One Useful Thing - Ethan Mollick's Blog on Practical Applications of AI in Learning and Business

Schillace Laws - A set of rules for how to best work with large language models as a software developer, written by Sam Schillace, deputy CTO at Microsoft and creator of Google Docs.

Prompt Engineering Guide - A lovely little site that goes in depth on different prompt engineering techniques with helpful examples.

A16Z - Andreesen Horowitz is one of my favorite VC firms to follow. They have a lovely collection of thought leadership on AI.

GitHub's Blog - I have long been a fan of GitHub's blog and R&D arm, GitHub Next. They have some fantastic material.

AI Pollution and the Tragedy of the Commons

If you haven't noticed the endless barrage of AI-generated images and "thought leadership" content on LinkedIn by now, you are either 1) not in the tech industry or tangential to it or 2) have been living under a rock. One of the more cringe-inducing features on LinkedIn that has recently fallen victim to this is the short-form "Answer a question" feature (you can do better LinkedIn).

Now, it's impossible (although some say the inclusion of the word "delve," or the wrapping up of a blog post with "In conclusion," are telltale signs of using Chat-GPT) to know for sure if these responses are AI-generated or assisted. Either way, there's a lot more content like this floating around nowadays, because it's just so easy to create now with LLMs. What are getting ourselves into? Maybe we need to revisit introducing more "Dislike" actions, like Facebook considered almost a decade ago.

A lot of people think the rapid uptick in low-quality content generation enabled by generative AI will “kill” the internet or drastically change it. It probably will. What will we see next though? Humans are resilient and innovative, so I’m looking forward to the next version of it. Are humans capable of designing a platform that prevents the tragedy of the commons, which doesn’t rely on an economy of eyeballs and clicks? In 2004, Aaron Swartz wrote a blog post about information freedom. Can information be regulated? Is there a technical solution to this, or do we rely on a collective swing of society to have a conscious positive impact?

In 2014, Warren Berger claimed in his book “A More Beautiful Question” that posits that questions are now more powerful than answers, because questions lead to innovation, and information is now freely and widely accessible. His rationale, is that it is inevitable that human information would become stored in a database that we could all access.

The sheer amount of information humans rely on to take action now is far too great for any brain to hold. So for the last two or three decades, we've been heading towards a world in which we gain the vast amount of our information from databases. And now, more recently, a computer (e.g., Chat-GPT) tells us the best information collected from the best resources. While this can sound daunting to some, there there is a tremendous upside to this - reduced decision fatigue.

I love Lazarus Lake’s approach to game design. He is something of a celebrity in the ultra-running community. He cropped up on my radar recently, after reading Frank Lantz's wonderfully eloquent piece on him. You should read it. Also, Lazarus Lake spoke on a podcast recently that is equally worth consuming. What I'm so enamored with is how he's bending seriousness, but not disregarding it. Lake's games remind me of Thorsten Brinkmann in some ways, blending ceremony with the peculiar. Lantz articulates it far better than I can, with the following quote:

"When they aren’t trying to manipulate you, most modern games are desperately trying to please you, carefully designed to capture and hold your attention, constantly trying to explain and justify themselves, and sweatily working to amuse and entertain you. When your game is a product every sharp edge is a flaw, a leak, an opportunity for the precious attention you are harvesting to escape back into the ether. Lake’s games are also carefully designed, they are full of closely-considered details that fit together to make a coherent whole, but the problem they are trying to solve is an entirely different one. They are not bowing and scraping to accommodate your needs while secretly plotting to hypnotize you into a state of passive thrall. Their parts fit together like the plants, rocks, and mud of a Tennessee mountain, and, like that mountain, they will happily, indifferently, shrug you off. And yet, somehow, the resulting experience expresses a deep level of respect and compassion." -Frank Lantz

Take some of these rules from Lazarus Lake's infamous Barkley Marathon that is organized each year and notoriously difficult to register for:

The start time occurs between midnight and noon. However, racers are never told when the race will officially start. The only indication they receive for the start time is by Cantrell blowing a conch shell, which could come in the middle of the night, to signify that the race will start exactly one hour from that time.

Once the hour is up, runners line up at the yellow gate at a campground within Frozen Head State Park. When Cantrell lights a cigarette, that starts the race along with the clock.

The bib is very important in this race. It does not track the runner or splits; rather, each loop requires runners to make it to various points in the park. At those checkpoints are books that Cantrell has placed there. Your bib number is the page number you need to rip out of that book. Typically, nine to 11 books are placed in the woods, and if you are missing a page then you didn’t officially complete the loop.

I hope some day to design a game. It's... somewhere... on my bucket list. Not sure when I will, but when I do, I plan on drawing inspiration from Lazarus Lake.

The other day I ran into a long-time friend of mine whom I rarely see (the older sister of one of my close high school friends). She shared with me that the mix CDs that I burnt for some of my friends, including her sister, made a lasting impression on her musical preferences, and she was thankful for that. It was very kind of her to share that with me, and it made my day. I sometimes forget how powerful and energizing a sincere compliment can be in the receiver's life. If you're reading this, thanks for that A.H.!

Here are some things I've found enjoyable recently:

Book: "Scaling People: Tactics for Management and Company Building" -Claire Hughes Johnson

Song: "Agape" -Nicholas Britell (fun fact, he wrote the theme for Succession)

TV: Succession (I've recently jumped into it, and am loving it! It's one of those series I knew would be good, but held off on watching for a while)

I've recently gone down quite a rabbit hole with Frank Lantz and intend to read "The Beauty of Games" in full here shortly. I also plan to read "Gravity's Rainbow," because I'm a bit obsessed with Thomas Pynchon's concept of temporal bandwidth.

Some of my favorite takeaways from day 1 at Figma's Config 2023 Conference, which was jam-packed with some quality presentations from heavy-hitters in the tech and design communities.

The first day of Figma Config 2023 was jam-packed with talks from some heavy hitters in the design and tech communities. This is a recap of some of my favorite sessions of the day, related to the creator community and the characteristics of delightful software.

Day 1 of Figma's hybrid virtual/in-person conference, Config 2023, was practically seamless from a technical standpoint. There have been some real shit-shows over the past couple of years when it comes to virtual event productions. I know it's not an easy undertaking, so kudos to all involved in this year's production. Two talks that stood out were by Andrew Schmidt on delightful design and Amiad Masad on enabling new creators of software.

Andrew Schmidt, gave a delightful talk (pun intended) on the characteristics that embody good software, and how they're pre-requisites for creators to consider before pulling out their bag of overused tricks for novel/kitschy "delight" (think confetti, silly micro-interactions, and overly conversational UX copy). He proposed that delightful software should be tactile, inspiring, considerate, comfy, and empowering. At the end of his talk, he reiterated that when your software does characterize these different qualities, the icing on the cake is letting humanity shine through in your design. Just be careful not to get too "cute" with your product before accounting for those fundamental qualities.

Schmidt was one of the best conference presenters I have listened to in quite some time. Even if you're not that interested in the content, I highly recommend watching the video (skip to the halfway point to get to Schmidt's portion of the talk). His storytelling ability and presentation are top-notch.

Should designers c̶o̶d̶e̶ create software?

In another session, Amjad Masad, CEO of Replit, presented a thought-provoking talk on the evolving role of designers in the software industry. He proposed a shift in the question from "Should designers code?" to "Should designers write software?" This shift in perspective is significant. It suggests that designers should not merely be involved in the aesthetic and usability aspects of software but should also contribute to its creation and development. With the advent of AI-enabled platforms and tools, as well as a whole slew of low-code/no-code solutions available to consumers, I imagine the role of developers in the overall product development lifecycle will continue to diminish. The developer role will never go away entirely, but we will definitely see a stronger shift towards DesignOps over the next couple of years, with more focus on high fidelity prototypes and shorter development cycles.

Looking forward to tuning in for tomorrow's sessions. If you're interested in checking out the schedule, you can find everything on Figma's event page.

Figma Config 2023 Day 1 Recap: Delightful Design and Empowering New Creators

Jun 27, 2022

Embracing Slowness

The Agile Approach

The Power of Milestones

The Way Forward

Latest articles

Nov 15, 2024

Building Multi-Tenant SaaS: Why "Teams" Functionality Should Be Day One Priority

Apr 29, 2024

Ramblings on AI and Lazarus Lake

Jun 23, 2023

Figma Config 2023 Day 1 Recap: Delightful Design and Empowering New Creators