1. MailChimp
2. Calendly
3. LeaseQuery

MailChimp is one of the very few tech unicorns that hasn’t raised a penny from venture capitalists. Back in 2019 they generated over $700M in revenue and they are still private, bootstrapped and profitable to this day.

Calendly used very little resources in their early days to reach profitability and instead of going after investors right after their early traction, they decided to double down on customers which eventually led them to skipping their Seed round AND Series A round to go straight to a Series B round raising $350M at a $3B valuation. They just hit $85M in revenue with 20M customers.

“Our profitable, unique, product-led growth model has led to Calendly becoming the most used, most integrated, most loved scheduling platforms for individuals and large enterprises alike” – Tope Awotona, Founder/CEO

LeaseQuery became one of the fastest-growing technology companies in the US that was profitable, bootstrapped, had 500+ customers, and was largely staffed with 100+ employees back in 2019. Fast forward to today, similar to Calendly, their extreme focus on customers early led them to skip their Pre-seed round and Seed round to raise a $40M Series A round led by Goldman Sachs.

“The answer to any VC question is paying customers.” – @GeorgeSomeone, Founder or @LeaseQuery pic.twitter.com/ZoBlTkCuNd

— Square One Startup School (@SquareOneSchool) May 24, 2021

CUSTOMERS = CONTROL

Each of the companies listed above control their own destiny and equity all due to the fact they are/were laser focused on their customers. By focusing on generating Revenue in the early stages your company becomes more valuable because you are bypassing the “figure it out” or “product-market-fit” stage since you have a growing rate of repeat PAYING customers which allows you to use that traction as leverage to negotiate the founder-friendly terms you want with VC’s when it’s time to scale up and raise capital, IF that’s the route you want to take.

WHAT IF YOU’RE PRE-REVENUE?

This is why we built Square One Startup School, a 10-week virtual pre-accelerator, to help pre-revenue founders around the world take control of their startup destiny by helping them gain their first paying customers to unlock more scalable opportunities.

The two things pre-seed investors look for are sales and sign-ups and over the course of 10-weeks we help you hit the necessary milestones needed to get you to the next level in your startup journey.

So if you are founder who is pre-revenue or pre-seed apply to our upcoming cohort HERE.

The post Customer Focused Startups Always Win 💸 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.