Building a startup (in a pandemic)

This article is titled “building a startup”, but I’ve added “in a pandemic” in brackets based on the few weeks with COVID-19.

For the last decade, I worked in digital agencies as both a designer and a developer. I started out as a designer/developer and then I doubled down on development once I realized I was actually spending more time designing things in code and inside the browser; so that that’s what led to that change. However, for the last three months I’ve been building a startup called Figmatic full time, which builds premium Figma plugins that are designed to turn designers into superhumans.

First things’s first.

The first things to note from these first few months are all the cool things that come along with that:

1. No managers
2. No meetings
3. No “Agile”

Somewhat magically, just removing these three things has made work fun and productive once again, which has been really neat.

Let’s rewind 12 months.

Before I get too ahead of myself, I’m going to rewind by 12 months really briefly. Twelve months ago, I discovered “life after the red pill”. I co-founded and co-ran the DesignOps Melbourne meetup for the first year of its existence, after which I decided to leave and focus on other things; but there was certainly a void left there after I after I walked away. This opened me up to a 4-6 week period of shutting myself off from everybody, being very introspective and just thinking about what I wanted to do next. The question that I have come back to very often over the last 5-6 years is from a book called “Zero to One”, and the question is:

“What important truth do very few people agree with you on?”

I have a few answers to this question, but the one I’m going to touch on at the moment is that

“I believe that we’ve been living through design and development workflow stagnation for roughly the last 20 years”

The great (20+ year) stagnation.

I’ll give a little bit of context around my thinking on this and hopefully not go too deep with it, but I think you’ll start to see where I’m coming from at least, and by definition, you should probably disagree with me on this important truth that I believe.

First of all, it wouldn’t be a real article unless I quoted something from “The Fountainhead”:

“The the hardest thing to explain is the glaringly evident which everybody has decided not to see”

This is exactly the way my mind feels when I’m talking about this topic because it just seems like everyone’s got blinders on, and no one really wants to think about the hard questions, or really look at where we are now compared to where we’ve come from.

To start off from 20 years ago, this is a quote taken from an article written by John Allsop (the founder of Web Directions) called the “The Dao of Web Design”; which was published almost exactly 20 years ago to the day. John writes:

”… It is time to move on, to embrace the web as its own medium. It’s time to throw out the rituals of the printed page, and to engage the medium of the web and its own nature.”

John wrote this 20 years ago, and if you told me it was written last week, I would I would believe you and think that it’s a brand new article; and that just signals that we really haven’t got past this “print” idea.

Yet 10 years later (and 10 years ago; almost 10 years ago to the day), the famous “Responsive Web Design” article came out, where Ethan Marcotte wrote:

“This is our way forward. Rather than tailoring disconnected designs to each of an ever-increasing number of web devices, we can treat them as facets of the same experience.”

That was from 10 years ago.

“Tells” that things have gone wrong.

So, we had these quotes from twenty years ago and ten years ago, but today, 10 years since the “Responsive Web Design” article, we still use the term “responsive web design”, instead of it just becoming absorbed into the the term “web design”. To me, this makes it seem like we still talk about it as if it were both new and optional; neither of which are true.

Also, somewhat hypocritically, at the exact same time, we use these other terms for arbitrary fixed sizes (which aren’t responsive) like “desktop”, “tablet” and “mobile”. If you’ve looked in a design file within the last year, you’ve probably seen layers and frames named with these terms.

The language that we use around design and development is also very telling - we’ve got term like “handing off” designs, “slicing up” designs, “inspecting” designs and “bridging the gap” between design and development - and these are all kind of tells that that something is a little bit off.

If we keep going down the rabbit hole a little bit, you’ve got terms like “Design Thinking”, which in and of itself is fine, but these terms kind of distract us from the need to actually think about design at all.

Then you’ve got the sheer speed of new articles and tweets that we see published each day, which also fool us into believing the propaganda that things are “just moving so quickly that we can’t really even keep up with all the radical progress” or “it’s so hard to even keep up to date” and the idea that things are just progressing at this rapid rate that our heads can barely stay on straight.

Not having a go at this specific trend, but new UI trends like “Neomorphism” give the illusion that there is a new future on the horizon, simply by covering our dated present with a fresh coat of paint.

At this stage, many people still believe that a “design system” essentially just means a well organised Sketch file (which is by definition always outdated) containing pictures that attempts to emulate pieces of a website.

The reality is that our designs are made with tools that have no relationship at all to the medium that they’re actually being used in by real people.

With all that aside, perhaps the most telling fact demonstrating the complete breakdown of our design and development workflow is that every design portfolio that I looked at while I was at my last agency never included the links of the websites that they actually designed, and that means that something has really gone wrong. If nobody wants to show the URL of the the thing that they’ve actually designed then something has really gone wrong along the way. That’s sort of like a “tell” that we’ve really messed up.

The hijacking of the term “DesignOps”.

If you’ve ever attended a DesignOps Melbourne meetup before, you’ll know that the tagline and the mission of it is that “We believe that the distance between design and development should be zero”. With Figmatic, I take a slightly different direction on this, which I sum up by saying:

“I believe that anything that exists inside of a screen design tool is always more valuable outside of it.”

You could take the next step and and then say:

“Production code and data are actually the source of truth for your designs”

Never in history will a user of your website be looking inside of your Sketch file or your your Photoshop document; there’s just no relationship between the customer.

This is really what DesignOps was meant to be. The the term kind of got hijacked along the way, if you if you search for “what is DesignOps?” there’s a lot of propaganda out there how it’s more about “management” and overseeing design and development teams to make sure that the information flow and the “handoff” processes are all going according to plan. However, in the DesignOps future that that Ch’an and I originally defined this role as, that role description is irrelevant because that job is actually removed completely when the distance between design and development is zero; there is no longer anything to manage. So, that role would become non-existent in a true DesignOps future, and in fact, the commonly accepted definition is actually the opposite of what we defined it to be originally.

The tipping point.

I’m going to briefly touch on the tipping point for me personally. So, a few months after I finished co-running DesignOps, at work in my agency, I was working on a design system for the better part of a year for a big e-commerce website, and I had done the entire thing in code. I had built everything in code: all the low-level stuff, right up to the full views and states and everything.

I held on to this approach for that whole time, I pushed back against any attempts to derail it for many months. People were trying to start hijacking the ideas and all that sort of stuff, and I got to about a month before the project ended and for some reason we had to send the client static JPGs, and I said: “That’s ridiculous we’ve got this live link here, where they can look at it on any device and see the real thing.”

The response was “no… we just have to do it this way…” So, long story shor, one afternoon I spent four hours screenshotting every page in every state in Chrome and and put these JPGs into an InVision link to share with the client.

We went in there the next week to meet with them and present these designs, and they said: “Alright, these are looking really good, but we would love to get the Sketch files so we can ‘hand-off’ the designs to our developers in the Philippines and get them to build it”.

I said: “Oh, no, you don’t understand; yes, these are these are JPGs, but I actually took them as screenshots from the HTML that I’ve already built”. And the client just brushes it off and says “Yeah… it’s just that we need the Sketch files…”

So, at this point, I was like: “Oh my god.”, and it just turned into a big mess. Again, long story short: tragically, none of the HTML or code I spent the better part of a year working on was used. Thankfully, as part of my design system setup, I had already set up a script to generate Sketch files directly from the real codebase (HTML/CSS), so I rendered all the components out to sketch files and we ended up just sending them that.

This was really the tipping point for me, where I realized I had lost the DesignOps war in my own workplace.

Taking the leap.

You can probably tell by now that I believe it’s time to really start getting back to the future so the question that I asked myself was again from the book “Zero to One”:

“How can you achieve your 10 you plan in the next six months?”

I like these kinds of questions because they force you to reframe it in a completely different way than you would usually answer it.

What do I want to be doing? I want to be building design automation tools full-time, and be profitable doing it.

My answer to that question was: I really needed to put some skin in the game; quit my job and self on my own company. This was the only answer I could I could come up with to at least have a shot of getting to where I wanted to be.

In reality, that looks like going from a lead developer salary back down to zero.

I did a few things to kind of counterbalance this after I decided to do this:

• I gave four months notice at work, because I wanted to have a really smooth transition between me and my replacement and sort of leave the agency in a better place than I found it, but also to build up some more savings, so I saved up for those four months.

• I moved apartment to a less expensive one.

• I sold my car, because I realized I wouldn’t be leaving the house for the foreseeable future. Anyone who has been quarantined for COVID-19 for the last two weeks, I’ve been self quarantined for the last three months (of my own choice).

• I also sold my a lot of my childhood Nintendo 64 and Super Nintendo games, and my Nikes.

• Finally, just cut down expenses everywhere else.

Having a plan is better than no plan at all.

I’ve never started a company before, but I do know that having any plan is probably better than having no plan at all. Here’s a rough outline of what I kind of planned out, the five things I thought I was going to do:

1. Do not compete.
2. Charge from day one.
3. Ship fast and often.
4. Talk to customers.
5. Do things that don’t scale.

All this this advice is probably common, but I decided to actually do them.

Going from zero to one

Going from zero to one really just means that I’m not going to be building the tenth “Lorem ipsum generator” plugin or the fifth “Spellchecker” plugin; I only want to build things that currently don’t exist that would be valuable to exist in the future. I’ve built 5 plugins so far:

1. Favvy; which exports production-ready favicon packages for progressive web apps and websites from Figma.
2. TinyImage; which handles image compression for JPG, PNG, SVG, WebP, PDF and GIFs.
3. Bannerify; enables you to animate and export production-ready banners directly from Figma to HTML.
4. Pixelay; this lets you overlay your Figma designs on top of your real development build.
5. Crypto; provides secure password protection for sharing designs from Figma

Plans to make C.R.E.A.M

You can validate real value quickly by charging for products. It’s common advice to say “release everything for free” to build up “recognition” and you can always charge later, but I decided to do the opposite and charge from day one. Because I’m 100% bootstrapped and not venture backed, I don’t have really long periods to remain unprofitable an focus purely on “growth”. I’ve found that charging from the start is actually a great way of figuring out how valuable something I’m building really is.

Move fast and break things with stable infrastructure

The other thing I really wanted to do was not fall into the trap of just building things for months on end, hiding away in the corner not showing anybody anything, not knowing if anyone actually wants the thing I think is going solve a problem; I just get it out there while I’m still embarrassed with the product.

I’ve been building very, very quickly. The way I’ve been able to do that it’s by using components. I use them on a product level when I design my plugins and at a website level; it’s all component based. I ship code probably at least a couple times a day either to my website or to my plugins.

The somewhat weird thing is that despite building plugins for Figma, I actually don’t use Figma for designing my websites or plugins at all. I’ve never designed anything in Figma; I design everything in code. Everything design related that’s in my plugins or website is all based in code, it’s all with components, and it’s extremely quick. I’ve actually redesigned this website three times since December, and it took me a couple of hours each time to completely redesign it, because it’s fundamentally built to be very very adaptable.

That’s a “PROTIP” for anyone else: designing with code works, and not only does it work, but it’s actually faster than drawing pictures of websites inside different design tools. You also get the benefit of having real content build-in to the design process, which is such a big advantage over other methods.

Talking to customers

I’ve been talking to customers (existing and potential customers), and that’s been really great, because I get super good feedback, and and they actually help me develop new ideas, I can build relationships with them and I can go back to them to check in and and get a better idea of what’s broken at their company.

Do things that don’t scale.

I’ve just got five things in here that I’m doing which (most likely) don’t scale.

1. Extreme customer service and feature request turnarounds.

If someone messages me on chat or email, I’ll reply to them within a minute and they’ll usually have a feature request or a question. My reply to their feature request will be: “the feature request has been deployed”. Then I’ll get feedback like: “Whoa! Your team is so amazing!”, and then I’ll go back and forth on the answer of either telling them it’s just me in my kitchen, or leaving them to think that we have some sort of massive enterprise running down here.

2. Cold emailing and offering to pay people to talk with me.

The second thing would be manually cold emailing over a hundred agencies and offering them to pay them to talk with me. This doesn’t really scale over time, but upfront, it’s a good way to to actually talk to people who might want your product. I’ve actually met and talked to a bunch of people so far, and none of them have actually wanted me to them, because they usually learn a bunch just from chatting with me, too. It’s a win-win, and we’re respectful of each other’s time.

3. Manually posting everywhere.

Number three would be just manually posting, linking, and commenting everywhere that’s relevant online to blitzscale these initial product launches. and kind of get a little bit of a growth curve starting at the beginning and then and then building that up over time the other thing that doesn’t probably doesn’t scale is at the moment

4. Building 1-2 new plugins per month.

I’ve been averaging about one to two new plugins per month. Developing new plugins over time willprobably slow down because I’m going to be working on more complex products over time.

5. Working 10-12 hours per day (every day).

The last one would be working 10 to 12 hours a day every day on this business. That may or may not scale; we’ll see how the the mental breakdown situation goes later, but for now it’s going well.

Are there any advantages to building a startup right now?

To make this somewhat relevant to the title, I should answer the question: “are there actually any advantages to building a start-up during a pandemic and impending recession?”

I came up with a few:

1. There’s definitely less competition. Less people will be inclined to start new companies and old companies will not survive, so overall there is actually less competition.

2. In the case of COVID-19, there’ll be more remote work happening, which means an uptick in Figma usage, considering the options for collaborative design tools are very very slim (and Figma is by far the best one). This may or may not lead to more Figmatic plugin use.

3. In these times, less “waste” inside of companies will be tolerated, so businesses will be looking for ways to save time save, money and improve efficiencies inside the workplace. That’s what Figmatic plugins are all about.

4. On more of a personal note, an advantage would be that having a startup is just a great outlet for me to focus my attention. It’s been great to not get distracted by all the the news over the last few weeks. I just keep my daily work routine going and keep the blindness on with working on building Figma plugins.

To sum up, if you’re thinking “well you’re talking about all these futuristic things but at the moment you’re you’re not doing anything too crazy”; the reason for that is I have a list of things that I want to automate from my time working in digital agencies, so I have a list of those things which I’m about halfway through. I want to automate all those things first then focus on some other new tools that we need today.

(This article was adapted from a talk I gave at DesignOps Melbourne back on April 1st 2020 called Building a startup (in a pandemic))

Read as Markdown · Related resource index · Site index for AI agents