The typical startup journey looks like this… come up with an idea, build a product, launch to the public, and wait for your customers to come to you.

This formula has worked for some but not for many. Usually, there is a large spike of interest on launch day   and then a large drop-off the next day leaving founders disappointed.  

The Best Companies, Start Marketing Early

Pre-Launch Marketing is a strategy that allows you to raise product awareness, gain product feedback, and build anticipation around your product before the official launch date. 

The ultimate goal is to build a loyal community of customers before you launch so that when it is time to launch they’ll be ready to buy your product and spread the word.

Here are a few success pre-launch startup stories: 

• Robinhood gained almost 1 million users prior to its launch, all thanks to their pre-launch waiting list strategy
• Monzo generated almost 5 million users before the banking app was released
• Clubhouse built a waitlist of 10 million people before their product was officially released to the public

How To Run a Successful Pre-Launch Campaign?

The most cost-effective way to implement your pre-launch marketing strategy is to build an email waitlist using a method called Lead Generation which includes the following tactics: 

1. Building a Landing Page 
2. Attracting the right audience to your landing page by marketing on the right channels
3. Collecting email addresses and as much information about your email subscribers as possible 
4. Setting up email marketing campaigns that consistently sends personalized email messages to your waitlist that are educational, informative, and exclusive

The Importance Of a Waitlist

A robust waitlist will increase your chances of getting your first paying customers and will allow you to build a relationship with your early adopters to make them feel like they are a part of an exclusive community. Having a loyal community means you’ll have advocates telling others about your product and repeat customers.

Setting Up Your Pre-Launch Campaign

If you don’t know exactly where to start when it comes to your pre-launch marketing strategy, no worries, we got you! We created an online course specifically for you called The Day 100 List led by (Me!) Square One Startup School’s Managing Director, Justin McLeod. 

I’ll walk you step-by-step on how to build your waitlist to its first 100 subscribers from scratch in the quickest & most cost-efficient way possible by using no-code landing pages, automated email sequences, and highly-targeted marketing campaigns.

CLICK HERE TO ENROLL TODAY! 

The post How to Grow a Pre-Launch Waitlist for Your Startup appeared first on Square One.

Any time we make a change to a CSS file, we need to carefully consider the global environment in which our styles will sit. No other front end technology requires so much discipline just to keep the code at a minimum level of maintainability. But it doesn’t have to be this way. It’s time to leave the era of global style sheets behind.

It’s time for local CSS.

In other languages, it’s accepted that modifying the global environment is something to be done rarely, if ever.

In the JavaScript community, thanks to tools like Browserify, Webpack and JSPM, it’s now expected that our code will consist of small modules, each encapsulating their explicit dependencies, exporting a minimal API.

Yet, somehow, CSS still seems to be getting a free pass.

Many of us — myself included, until recently — have been working with CSS so long that we don’t see the lack of local scope as a problem that we can solve without significant help from browser vendors. Even then, we’d still need to wait for the majority of our users to be using a browser with proper Shadow DOM support.

We’ve worked around the issues of global scope with a series of naming conventions like OOCSS, SMACSS, BEM and SUIT, each providing a way for us to avoid naming collisions and emulate sane scoping rules.

We no longer need to add lengthy prefixes to all of our selectors to simulate scoping. More components could define their own foo and bar identifiers which — unlike the traditional global selector model—wouldn’t produce any naming collisions.

import styles from './MyComponent.css';
import React, { Component } from 'react';
export default class MyComponent extends Component {
 render() {
    return (
      <div>
        <div className={styles.foo}>Foo</div>
        <div className={styles.bar}>Bar</div>
      </div>
    );
  }

The benefits of global CSS — style re-use between components via utility classes, etc. — are still achievable with this model. The key difference is that, just like when we work in other technologies, we need to explicitly import the classes that we depend on. Our code can’t make many, if any, assumptions about the global environment.

Writing maintainable CSS is now encouraged, not by careful adherence to a naming convention, but by style encapsulation during development.

Once you’ve tried working with local CSS, there’s really no going back. Experiencing true local scope in our style sheets — in a way that works across all browsers— is not something to be easily ignored.

Introducing local scope has had a significant ripple effect on how we approach our CSS. Naming conventions, patterns of re-use, and the potential extraction of styles into separate packages are all directly affected by this shift, and we’re only at the beginning of this new era of local CSS.

process.env.NODE_ENV === 'development' ?
    '[name]__[local]___[hash:base64:5]' :
    '[hash:base64:5]'
)

Understanding the ramifications of this shift is something that we’re still working through. With your valuable input and experimentation, I’m hoping that this is a conversation we can have together as a larger community.

Note: Automatically optimising style re-use between components would be an amazing step forward, but it definitely requires help from people a lot smarter than me.

The post Getting Your First Customer appeared first on Square One.