Build Fast and Break Things

Episode Sponsor - Wix Studio

Wix Studio is the new web platform tailored to designers, developers and marketers who build websites for others or for large organizations. The magic of Wix Studio is its advanced design capabilities which makes website creation efficient and intuitive.

Check out Wix Studio today!

How to support the show

Patreon

Prices subject to change and are listed in USD

• Support the show from as little as ~$1/month
• Get a shoutout at the end of the episode (while supplies last) for just ~$3/month
• Help support the HTML All The Things Podcast: Click Here

Show Notes

Intro

• A lot of companies have issues where they start and stop building new features fast, instead focusing on processes and stability 

What does building fast mean?

• Establishing a tech stack that allows your team to iterate quickly
  • Dev environments and prod with easy rollback
  • Dev databases with branching and easy backup/restore
• Ideas should be able to go from concept to production in potentially days/weeks rather then many months of back-and-forth planning
  • Caveat of course being that some features are large enough that can take 6+ months even if moving super fast
  • More talking about typical small features that theoretically can be built out within 1-2 weeks but still require a bit of planning and design
• Let your customers tell you when your ideas suck as quickly as possible
  • Imagine spending 3 months ideating, designing and building a feature with a big team. Launching it and having the customers either hate not worse, just not use it
• This does not mean launching half baked or broken features
  • QA should still be part of the process when releasing anything
  • QA can start as you develop the feature, early QA can help catch miscommunications and edge-case bugs before you go to deep
• Building fast usually means keeping the team building as small as possible. That includes having less input from stakeholders. 
  • This requires a lot of trust in the PM/manager that is responsible for the feature and the engineers as their decisions will be built without to many checks and balances
• Less processes helps you build faster
  • Following strict agile/scrum workflows can actually drop velocity quite heavily as everyone team is more focused on closing tickets to pad their stats then actually owning and completing features

Why is it ok to break things?

• Most of the time when you’re first building a product, your user base will be quite small and making something perfect isn’t going to benefit the non-existent users
• Early adopters are typically ok with bugs as long as you give them the ability to contact you directly from the app and you respond very quickly to their feedback
  • Some of our most loyal users on the apps I’m building are ones that reported a issue in the first few weeks of launch and their issue was addressed within 24 hours
  • This is something backed up by larger startups like ping.gg by Theo
• A lot of the time, if you focus on perfection the feature you’re building, might not even be viable, so the extra weeks/months could be wasted
• Once a feature is proven to be wanted/usable more time can be invested into making it more robust and perfect
• Being responsive to users >>> building slow perfect products

When is it not ok to build fast?

• Authentication and user data collection and storage
  • There are to many instances of companies leaking data. If the feature you are building is collecting and storing user data, allow for extra time to audit, test, pen test and make damn sure you’ve done everything you can to prevent their data from leaking
  • You can shift this responsibility to 3rd party providers suing OAuth or 3rd party auth services like clerk and Supabase
• Building on top of established features in established software
  • If you’re building a feature for google search for example you want to make damn sure that anything you build doesn’t negatively impact users due to bugs/slowdowns
  • A side feature of an established product that does not effect the core functionality of the app does not need to follow the slow/safe build approach

Links

• Have I Been Pwned
  • Have I Been Pwned: Check if your email has been compromised in a data breach
• ‍Michael LaRocca
  • Author of the Self-Taught the X Generation blog, at selftaughttxg.com