How I launched a product for designers without raising funding

I’m Matt, the founder of Lucid, the tool that makes it super easy for you to manage and share design systems. As a UX designer I love digital products and have always wanted to create something of my own, but because I’m not a developer I’ve never had the skills to actually build software and make it happen.

It’s been a wild ride getting Lucid out, and there’s been a ton of learnings along the way. This is the story of how I took it from idea to reality as a non-developer.

The idea

A couple of years ago I was working at digital agencies and startups and saw a recurring problem. Designers were creating style guides which were difficult to update, managed by one person, and the work of maintaining them would usually fall to the bottom of the priority list.

At the same time design systems were gaining traction. They incorporated style guide content, but also stuff that’s normally contained in component libraries. Material, Rizzo, Lightening and others were getting attention, and new design tools were enabling us to take a more systematic approach.

I thought there was an opportunity to help designers by giving them a really easy to use tool so they can create and publish their own design systems, without having to write any code. There were some products out there that kind of offered this, but they weren’t very appealing to designers.

Validation

I spoke to as many people as possible to learn more. I had to be focused and not talk about the idea, but instead to draw out conversations around the problem. My conversations were validating what I’d seen myself, but I wanted more proof.

I decided to do a ‘landing page test’ (inspired by ‘The mom test’ by Rob Fitzpatrick). It forced me to write the proposition and describe Lucid in a few words. It was a proper product page, with a sign up button at the bottom. When you ‘signed up’, it said ‘Lucid isn’t quite ready’ and asked for an email. I wasn’t looking for vanity metrics – I wanted evidence of real users.

I put an ad on Designer News for a day. It drove enough traffic to get 70 ‘sign ups’. For me, this felt like enough validation to continue.

Pulling together a team (or not)

A friend of mine (who happens to be a great designer) recognised the opportunity and wanted to help. Like most normal people, We were both busy with full time work, so this had to be done in our spare time. We agreed an equity split. I knew this was going to be a daunting journey and I didn’t want to go it alone.

By now I’d created wireframes mapping out Lucid’s main journeys. I set up meetings with developers I knew. Two agreed to come on board and build the product! I was pumped, things were looking good!

As the weeks went by I realised that despite the best intentions, people don’t have the time or energy to commit to side projects when they are working full time. The ‘developer friends as a team’ model just wasn’t working.

Funding the project

When you read start-up success stories, founders and investors always tell you to explore the ‘friends and family’ route first. I always found this unrealistic. My friends that have saved money are busy dealing with their own shit, like the general cost of living or trying to pull money together for a deposit, and my family as much as I love ‘em, just don’t have spare cash.

Undeterred, I decided there was only one thing for it, and that was to self fund as I earned. As a freelance UX designer I was able to earn a good day rate. So I put my money where my mouth is, and carved out a chunk of money from my freelance work each month. It meant making a lot of sacrifices, but it also meant I could move forwards.

Finding a remote partner

I Googled software development in Europe and narrowed it down to a few companies based on how they presented themselves. One stood out so I spoke to the guy behind it. He was helpful and professional. This was at the time when I was ready to do my ‘landing page test’. They built it quickly, it looked perfect and worked well. So I decided to continue to use them for the product.

I got a full stack dev, front end dev and project manager (all part time) within my monthly budget. Things were back on track, I had a team!

The long and bumpy road

The first month was great. The team had developed the sign up and registration journeys and the project list page. Then it stopped, and I wasn’t getting clear answers. The developer had chosen to build using a framework that he had no experience with. He was out of his depth, and was learning as he was going. It was a struggle.

Weeks turned into months, and while stuff was getting built, progress was agonisingly slow. At the same time, my co-founder had a great job offer – he couldn’t commit the time to Lucid anymore so we agreed that he’d step away.

These were tough times, I was sinking considerable money into the project every month, development was slow, the product was substandard and I had no partner. At the same time tools for creating design systems were popping up. On top of this, the team decided that they didn’t like working for their boss anymore and wanted to leave! This put me in a tough position, but I had no option other than to hire them directly. Mutiny!

I remained determined despite the adversity. The validation signals in the market were getting stronger, and I wouldn’t accept defeat! I knew there was an opportunity here and I’d developed a tenacious spirit that kept me going.

Getting somewhere…

I was contracting on FinTech projects to pay for my living costs and for the project, so my day job as a UX lead was full-on and high pressure. I carved out time for Lucid every morning before work, and in the evening. I was designing and specifying the the product as the team were building it.

Gradually it took shape. It was still taking longer than I wanted, but I wasn’t in a position to swap out the team, or hire more experienced developers. My goal was to get this beta out, to see if there was still an appetite for it.

We all read about lean approaches where you can bash out MVPs in days or weeks to validate a product idea – but this requires up-front money, and highly skilled people-power. The fact is, I had to keep moving forwards with the extremely limited time and resources that I had available.

One of the things I learned on this journey was to only take advice from people who have done it themselves, after all they could empathise with my position and give meaningful guidance.

Launching the beta

After 18 months of development (rather than the 6 I originally anticipated) we were finally ready. Lucid was a basic beta, it allowed users to create design systems containing colours, typefaces, text styles, icons, logos, images, writing guidelines, design principles, components, examples and do’s and dont’s.

Tough decisions were made, the Sketch plugin and ‘team projects’ feature were cut.

I signed up for ProductHunt’s ‘Ship’ which gives you the ability to create a ‘coming soon’ page before you launch. I set my launch date, and Lucid appeared on ProductHunt. I waited with baited breath for a response. In the first hour I got 30 followers, and the sign ups started creeping in. 100, 200, 300 – by the end of the day I had over 400 followers and 300 people had signed up.

People were commenting via Intercom – ‘Great product’ ‘Where’s the Sketch plugin?’ ‘How do I customise the landing page?’ I had users! And they were asking questions. This was the beginning I’d been waiting for. It took so long, but here I was.

I reached out to Marvel, they invited me to their office where we had a great chat about integrating via their API. This was awesome!

Current status

In the last couple of months I’ve let the dust settle. After launching the beta we’d built up tech debt and the full stack developer wasn’t getting anywhere with fixing the issues. I finally decided to let him go. I found another remote developer, this time using much more due diligence. They turned out to be more experienced, and are working through the tech debt and ironing out the bugs. I now have a stable remote team that I’m happy with.

As expected, a lot of people are curious – they sign up, look around, and leave. There are a small number of engaged users who are adding content and using the tool to solve the problem I’d originally identified.

They’re asking questions, reporting issues, and asking for features. Lucid isn’t perfect, there are some key features missing like Sketch integration, and the ability to integrate with coding tools.

But what I do have is something with a heartbeat – some real signs of potential.

What now?

I’m now in a position to raise seed funding to accelerate the next stage of development so we can integrate with Sketch and Github to create an end to end design-ops experience. I’ve a beta product that’s live, and a small number of active and engaged users. With the right additional resources, I’m ready to move fast.

I’m a realist – the verdict is still out on whether Lucid will be a success. For me it’s been about validation at every possible point. The reason I wanted to share my journey is to show people that it is possible to bring a product to market if you have the drive, determination and patience.

Learnings

I’m not in a position to give advice on how to run or grow a startup. And my story is not necessarily the right way to do things. But in terms of getting an initial beta out of the door, and based on personal experience, these are the things I’d share:

Self-funding is an option. I appreciate that this depends on the amount you’re able to earn, so it won’t work for everyone. If you can’t afford it yourself, club together with a like minded co-founder.

Find a technical co-founder. I couldn’t, which has made things extremely hard.

Engage with your users, listen to their questions, and respond quickly with personal and helpful answers (Intercom is awesome for this).

Find time by working when you’re most productive. For me it’s mornings. On my 40 minute daily commute I chat with the team on Slack, answer any questions, focus on my product backlog and keep the development moving. Any big stuff I do on weekends.

Be patient. Making software is hard. Unless you’ve got tons of money, it’s not going to happen overnight.

Don’t try to build a team of people who have full time jobs. Something’s got to give, and people really struggle to find the time.

Don’t waste time if things aren’t working out. In hindsight I should have pulled out when development was going slow, and found someone else.

Don’t listen to people who’ve never done it. Everyone’s got an opinion, only listen to the ones that matter.

Don’t shroud your idea in secrecy or NDA’s. Do you honestly think someone will take your idea, build it and execute in exactly the way that you can?

Design and prototyping for everyone

Thousands of individuals and teams use Marvel to design and prototype ideas.

Matt is a product manager and UX designer based in London. Over the last 15 years, he's helped startups, digital agencies, and large brands define, design and launch digital products that affect positive change. He's an advocate of design systems and design-ops, having created and launched Lucid with the goal of streamlining the way digital product teams work. -
Twitter: @mathummm
Email: [email protected]

Good Stuff

Related Posts

Digital products have come a long way and so many teams are more agile than ever before. With continuous delivery, quick turnarounds and back-to-back release dates, running into production bugs every now and then is natural. At Marvel we, the support team, have developed a fool proof bug reporting method to help you squash those bugs in double time. 🐛🔨… Read More ￫

We’re excited to launch the first in a series of Workshop Kits, that will help you run your own hands-on sessions using popular design methodologies, together with Marvel! Thousands of companies and educational institutions around the world use Marvel in workshops every year. It’s massively inspiring to see the likes of Laboratoria, Design Museum and initiatives like Design Club lead… Read More ￫

Prototyping is not only a stage of the design process, it’s heavily involved in the developer handoff process as well. When a design is ready to go into development, developers often receive pages of spec documents outlining how the design should look, feel and function. This has been a major pain point for many large organisations and design teams, and… Read More ￫