What would I do differently with hindsight?

I've started to think more about whether I'd build another application some day, and that got me thinking about mistakes and choices that I'd handle differently now.

advertisement

Email verification directly on Google Sheets

What would I do differently?

So much has changed in my 10 years since starting Sifter. My personal life has changed significantly, and technology has evolved just as much. I’ve done my best to keep up with the changing ecosystem, and after more than ten years of SaaS experience, I’d like to think I could make much better decisions this time around.

So, if I started bootstrapping a new SaaS application tomorrow, what would it look like? What things worked and would be the same, and what things were mistakes that I’d approach differently this time around?

These changes in my thinking are the result of several events. First and foremost, with Sifter, I went through the due diligence process twice with two separate buyers and saw countless things I wish I had handled differently over the years. Second, for the last three years, I’ve been working at a slightly larger SaaS company that has multiple products. Third, I’ve been able to observe Sifter from the outside and see the decisions a different team makes. Finally, losing my leg and recovering put quite a few things in perspective.

Before we dive into all of this, I wouldn’t advise this formula for everyone. With my own personal experience, these are the the things that I envision enabling me to be happier and more satisfied with my work and enable me to build a much better product.

No ambitions.

This one might sound weird, but one of the most significant over-arching mistakes with Sifter was my expectations. Sifter was successful. I enjoyed writing code and shipping updates. However, it fell short of what I had hoped it would achieve by about half. That focus on revenue distracted me from enjoying my work as much and led to me spending time trying to grow the business instead of just enjoying my work. That’s not say that I’d neglect revenue or shun growth, but I’d try to consciously reduce its importance.

Shorter, more focused weeks.

At Wildbit, we do 4-day/32-hour work weeks, and it changes a lot. With an extra day to deal with personal things every week, there’s fewer distractions at work. It’s also interesting how with fewer hours, one tends to just focus better. I’d want to experiment with 5-day/30-hour weeks, though. I think five 6-hour days could be more productive than four 8-hour days.

A more consistent schedule.

With Sifter, I ended up working incredibly flexible hours. I usually worked 7 days per week, but it was never a slog. I’d simply work fewer hours during the week and end up doing another 4-6 hours over the course of the weekend. In hindsight, I would have liked to create a more consistent schedule where an hour or two of work couldn’t creep into personal time outside of work.

Focus on building over operations.

With Sifter, I got carried away focusing on operational things like revenue and growth. I let too much of the business steal my attention and tried to focus on analytics and numbers as if they would reveal some magic growth opportunity I had overlooked. It felt like work, but it distracted me from the work I enjoyed. That made it much less sustainable because it sapped energy and morale. In hindsight, writing Ruby, Rails, and front-end code was my bliss, and I think it’s worth designing the business to support that work.

More help.

Even while there were others contributing to Sifter’s codebase, I was the one on the hook for managing downtime and support. In my head at the time, Sifter had to grow so that it could afford a second full-time person and I could have help. I should have focused less on revenue enabling that situation and more on creative ways to support it so I didn’t feel like I was on call 24x7. That could mean more contractors or a business partner. It could mean simply documenting more so that others could help. Whatever I did, it would mean reducing how critical I was for everything. This is also just a healthier way to run a business.

Reduce manual intervention.

Sifter relied way too much on me doing manual work. Most of that work was invisible to me until going through due diligence. Sifter didn’t need a whole lot of attention from day-to-day, but I was the only person who had all of the knowledge to perform most of those tasks. During due diligence, as I documented those tasks, it was clear just how many tiny little tasks teamed up to chew into my days. This time around, I’d invest a lot more time in documenting processes and progressively automating them so I’d be more free to do the deep work necessary to build and ship a product.

Build it for myself.

Sifter was something I wanted when consulting, but as soon as I was full-time on Sifter, I wasn’t consulting any longer. As a result, Sifter struggled with an identity crisis of building what I personally needed as a product developer versus the original vision of making bug and issue tracking more accessible to small agencies. In hindsight, that conflict led me to watering down features or building features that I wasn’t excited about. Unfortunately, I didn’t recognize the problem until I was selling Sifter. If I build something again, it’s more important that it’s around something near-and-dear to my heart. That’s not to say that you need to be passionate about your idea, but for me, I’ve found that it’s better if I’m more personally invested in a tool that I’m working on.

Quit following “best practices.”

Like with many first-time founders, I assumed that everyone else knew what they were doing, and whatever practices they were following and writing about were simply the right practices for a SaaS business. Analytics. Marketing. Growth. I don’t want to build an operational system to grow a business and then spend no time on the product. I want to design a company to build the product and serve customers. That’s not to say that there shouldn’t be some type of marketing that will need to be done, but I’d rather find ways where marketing is a by-product of the software rather than a separate activity. Checking analytics and numbers eventually becomes relevant for a business, but it’s a spectrum. I want to check the numbers to make sure the business is healthy, but I don’t want to be in a situation where I’m spending days analyzing or optimizing.

No traffic analytics.

Traffic analytics can be helpful, but for me, it felt more like vanity metrics and a distraction than meaningfully useful. It’s also a layer removed from success. You can get more traffic without growing the business. In all of my time with Sifter, I can’t tell you a time that knowledge about traffic meaningfully influenced my decision-making. Of course, there’s the added bonus that getting rid of JavaScript analytics libraries benefits the performance of a site too. Add in the privacy factor, and it just feels like there’s not enough value to justify it. The only drawback I’ve been able to come up with is that Google Analytics played a significant role during due diligence when selling Sifter. So, if you’re ever planning on selling an online business, a buyer would likely want some sort of traffic analytics. My thinking is that if I ever needed them for a good reason, I could add them in.

Email instead of social media.

I’m not 100% on this yet, but I’m leaning towards completely shunning social media if I build a new product. Instead, I’d focus on building a higher quality email list. There’s the big benefit of being a more direct line to customers and being less prone to the whims of the social media companies, but more than anything, I feel like a newsletter is a better way to communicate. Sure we’d have a blog and changelog, but longer-form, more thoughtful communication feels like the way to go. These days, sharing on social media feels more like a distraction than anything truly useful to the business. It also has the unfortunate side effect of fragmenting your support channels. You need more tools and attention to monitor different channels, and it all turns into a distraction. If there was huge customer demand to have a presence on Twitter or some other platform, I might reconsider, but my gut tells me that social media is more of a distraction for a small business than a benefit.

No forced email sequences or bots.

These days, it seems everyone has adopted invasive and unending email sequences, bots, and other assorted popups with zero consideration for the experience. On the surface, they often mean well, but it’s become too invasive for me. Unsubscribing is often horrendous or impossible, and too often the implementation and execution feel like “best practice zombies” than anything useful. For me, it’s communication channel fatigue. Everything should be optional and very much opt-in rather than force-in. This may not be the best thing for growth, but it feels like the best thing for customers—not to mention that I won’t be spending hours upon hours optimizing a variety of communication channels. That also means fewer tools to deal with and less analytics to monitor.

More talking to customers.

It’s difficult to find time to talk to customers. With Sifter, I assumed that answering 3-5 support emails every day meant that I was talking to customers plenty, but I was so wrong. Getting on the phone or a video call with people is critical. It’s energizing, and the serendipity of the topics that come up leads to endless inspiration. I’m fairly confident I’d even put a toll-free number on the site to let people call me directly. I would, however, take steps to ensure that people were only calling during business hours.

Less opinionated.

With Sifter, my main goal was to ruthlessly simplify bug and issue tracking and avoid the endless decision-making and configuration that most tools in the space require. As a result, I made way too many unilateral decisions that were counter-productive for a lot of customers and potential customers. In hindsight, I could have implemented quite a few solutions that would have put some control in customers’ hands with very little risk to the overall experience. Based on that experience, I’d be quicker to find ways to give customers a few more options and a little more flexibility. Throwing every option into an overwhelming preferences screen still isn’t the way to go, but finding ways to provide a few options is a good thing.

No (or very minimal) marketing site.

This is another fairly extreme one, but I’m confident that I’d take steps to avoid building a marketing site for an application. Or at least, the goal would be to maintain an incredibly minimal marketing site. I’d like to build a tool that you can just start using right away. You just use it without registering, then, after trying it out, you decide whether you want to register. If it’s not for you, it just cleans up after you. If you like what you see, then you create an account, and it saves everything for you. This would enable me to spend less time on the glossy brochure site and more time helping people dive right in and use the software. The application should have to earn your trust before you’re required to hand over any personal data. This may be one of those things that sounds great in theory but ends up with significant challenges in practice, but it’s a goal I think is worth pursuing.

More open.

This one would be a big change, but I’d like to approach building the application with an eye towards opportunity for open-sourcing more of it. Hopefully, but removing some of the afore-mentioned distractions, I would be more able to stay heads down writing code, and, in turn, be able to share more of that code when it could be useful to others. I’d also like to share revenue and that sort of thing so far as it doesn’t become a distraction.

Encryption at rest. (I think.)

While I’d need to research this one a bit more, I think I’d lean towards encrypting most, if not all, of the data at rest. This is one of those things that would likely depend a little on the type of application and the sensitivity of the data, but it simply feels like the right thing to do. This is a big item on my education list to make sure I fully understand which parts of building an application may be significantly more difficult or less performant.

Reduce dependencies and moving parts.

A plugin here. An app there. Another app over there. Modern web application development makes it easy to drop in way too many additional tools. The result is often a barely understood mishmash of tools. Many of them overlap in awkward ways such that you only use a fraction of one tool because you have another tool handling a similar part. The result is often counter-productive. If I did it all over again, I’d actively try to use as few tools as possible, and I’d have much higher expectations of integrations and playing-nice-with-other-tools. Using fewer tools isn’t about using tools that do more things, but about constantly questioning whether a tool is helping me ship code and serve customers or whether it’s just creating extra overhead.

Build something outside of tech.

This one may be easier said than done. Working in tech, it’s difficult to steer ideas away from technology. I could see myself going either way on this one, but I’m actively trying to focus my thoughts and efforts on ideas that don’t serve developers. There’s no shortage of developer tools out there, and I’m confident they’ll continue to proliferate. On the other hand, ideas to help amputees, non-profits, or even increase the accessibility of technology feel like they’re underserved.

Focus even more on accessibility and approachability.

Finally, one thing that’s been important since Sifter was a focus on accessibility and approachability. I mean “accessibility” in every sense of the word. Accessible to people with disabilities. Financially accessible. Cognitively accessible. Accessible on lower-end devices. With Sifter, I wanted to make bug tracking more accessible to small teams by removing confusion. Whatever I do next, I’d like to further improve my knowledge and take steps to make it even more accessible.