According to freeCodeCamp’s 2018 New Coder Survey, 40.3% of participants want to build a business of their own, either as a freelancer or as an entrepreneur.

If you are in that 40.3%, then this article is for you. If you are in the remaining 59.7%, you might still benefit from it. Give it a try.

This is not a “dummies’ guide to strategy and design” or a “strategy and design 101” article. This article is written specifically for developer folks. Not just software developers but also no-code developers. (Shout out to my ODNC1 fellows who encouraged me to write this piece.)

Table of Contents and How to Use this Guide

This is a long article. Actually, this is not an article – this is a guide. So, it's better to read the prologue and give the guide a quick scan. Then start applying the methods rather than reading the whole text and trying to internalize it.

You can only internalize this guide by applying it.

Getting Started

1. What is Strategy?
2. The Main Components of a Business Strategy
3. Strategy, the Scientific Mindset, and Software Development

A Rough Guide to Strategy and Design for Developers

1. How to Define Your Purpose
2. How to Develop Strategic Hypotheses
3. How to Test Strategic Hypotheses
4. How to Design Your Product
5. Conclusion

The Structure of the Guide

This guide is structured to make the actions you should take very clear. So, in every section, you will be given a little bit of context and then action items.

It is essential that you read the context in full before taking action so that you can see the part the action plays in the bigger picture.

Getting Started

I know that strategy and design can sound, well, fluffy. I know that because I have been there.

I am an engineer. I love physics and mathematics. I love breaking challenges down into their parts and overcoming them one by one using logic. I love to work with hyper-realists who think rationally. I love viewing processes as functions that take certain inputs and spit out certain outputs. I love all of that and more.

However, I am also a strategist and a designer. I know that not everything has natural reasons to be so.

Sometimes they are purely based on choice. I know that people are irrational, though still predictable. I know that people value social and emotional benefits as much as functional benefits, if not more.

So, I know that bringing together strategy, design, and engineering mindsets dramatically increases our chances to achieve whatever goals we have. I witness that day in and day out thanks to my job at ATÖLYE as its Ventures Director.

But if you don't believe me, I hope you will believe in the data. This might be one of the saddest statistics you might ever see (!):

Top 20 Reasons Startups Fail - CB Insights

CB Insights’ findings are chilling. 42% of startups failing simply because they are not needed.

Imagine this: You quit your job, and maybe risked your reputation. You raised funding from your friends, family, and investors. You started living on a very low budget. You worked tirelessly, 12 hours a day if not more… and after a year you realize there is no need for what you have been grinding and hustling for all that time. Isn’t that chilling?

Strategy and design help you minimize the chances of failing. How? Good strategy and design focus us on building lasting businesses based on customer needs and/or wants and competitive advantages. Also, they inherently mean testing hypotheses and iterating constantly.

They are great tools to find our way out of complexity… but let’s leave praising strategy and design aside and get practical. We will start by agreeing on a definition because the meaning of strategy is highly variable.

What is Strategy?

Strategy is one of those concepts that everybody understands when they hear it but no two people understand the same thing.

Very generically put, strategy is a high level plan to achieve pre-determined goals. However, in a business context it has a more specific definition. Here is how I would describe it:

Strategy is a set of hypotheses that describe a set of integrated key choices, key actions and a progress measurement framework for achieving business objectives.

We develop strategies because we believe achieving objectives will help us realize our purpose.

The Main Components of a Business Strategy

Below are the most relevant main components for a startup founder at the beginning of their journey.

If we were to consider an established company rather than an early stage startup, we'd have to think about competitive advantages, core capabilities, management systems and – depending on the type of business – a few more specific components.

The key thing to remember is that however many components there might be, they all have to be integrated with the main components listed below.

The purpose for doing business

What drives you to do business? What impact and value do you want to create? What do you want to get in return? How is it measured (directly or indirectly)?

I list this first because it is the basis, ideally, upon which all your decisions will be made. When you are in doubt or things are too difficult to figure out or mutually exclusive options are similarly attractive – you will come back to the basis and seek guidance.

Market definition

Who are the customers, users, competitors, regulators, and other main actors who take part in the value exchange you want to create?

Market definition and Value proposition are extremely intertwined. That is why I list them one after the other. Without a sharp, even discriminating, (as in consciously choosing not to compete in certain markets and thus choosing not to serve certain customers) definition of a market, we cannot define meaningful value propositions.

Say that you are developing an analytics product. If you are focused on mobile applications then you are "discriminating" against web applications and your value propositions will be shaped with this choice.

Value proposition

Your value proposition is what you have to offer to your customers (and, if you are thinking more ecosystemically, to all the actors you have in a give-take relationship) in exchange for the value you ask from them.

For example, customers pay you money, users might provide you with data, partners might help you reach customers, government supposedly ensures a fair market, and so on.

Value propositions are not the same as products, features, or services. An easy way to distinguish value propositions is to answer the question, "How will our customers benefit from using our product?" (And, again, you can extend this question to all the key actors in your market by asking "How will this key actor benefit from being part of the value equation I'm creating?")

As this question implies, it is not the product itself that your customer is after. It is the benefits that your customers are hoping to get out of using your product.

Meaningful Differentiation

Why will anyone choose your product over all the alternative products or ways to get the benefits they seek? What makes you a better fit for them?

How do you create that fit? How are you doing that differently from your competitors? How long can you hold on to this difference?

What can you do to keep the competition away? How might you make the competition irrelevant to your customers?

As Jobs to Be Done (JTBD) theory explains, jobs (the things people are trying to get done using products) do not change. The products keep changing but jobs stay more or less the same.

Take commuting, for instance. The way we commute has been in a constant evolution that brought autonomous electric cars to our lives. However, the job of getting from one point to another has been with us from the very beginning.

With every step in this evolution, more and more nuances are addressed. However, at the heart of it the job is still the same.

So, the differentiation lies not in inventing new jobs but in finding new and meaningful ways to help with getting those jobs done.

Price is just one way to differentiate. Features, benefits, the overall experience, the nuances you choose to address – there are countless ways to differentiate.

However, meaningful and lasting differentiation is hard. It's hard because copying is easier than ever. It's hard because developing software (unless it's something super advanced) is getting easier and easier. Good design is more accessible than ever.

So, we need more than design and technology to sustain a meaningful differentiation. More on this in the design section.

Strategy, the Scientific Mindset, and Software Development

Strategy is about developing hypotheses from a mixture of deductive and inductive reasoning and then measuring progress against objectives.

It requires us to break things (markets, value propositions, differentiation, and so on) down to their parts (customers, buyers, users, partners, regulators, products, services, experience, branding), understand them individually, and then melt them together to create a coherent whole (a business).

It's extremely analytical and holistic at the same time. I find these aspects of strategy very similar to the scientific mindset.

This similarity also reminds me of the role of a software architect. They are tasked with a similar challenge. The level of uncertainty and complexity, though very different in their nature, are similar.

They both have some level of information available to them to make decisions but never the full picture. They both need to develop hypotheses and test them before fully committing to a particular approach.

Crucially, they both are aware that there is no one way to achieve the objectives, which means they are making choices. So, they want all the other things that will be built on top of their strategy/architecture to be coherent with their key choices.

And this similarity makes me question why so many engineers and developers distance themselves from strategy. Probably because of the way we talk about strategy and position it in companies, but also in education. That's very sad and needs to change.

A Rough Guide to Strategy and Design for Developers

Definitions are important. They help us develop our own language and communicate. Now that we have our language in place, let's get into execution.

The guide below is rough by design. It's rough because I don't want to put too much emphasis on the guide itself.

It's rough because you are a developer trying to get something off the ground. Not a strategist or design manager in a company setting.

It's rough because it aims to hit the sweet spot which helps you get 80% of the results with 20% of the effort.

And it's rough because this is my first attempt to customize it for developers and I want to test this hypotheses before fully committing to it. So meta, isn't it? :)

How to Define Your Purpose

Start from within

What are you hoping to achieve for yourself? A side business? A learning project? The business of your life?

Describe a day in your life assuming everything went great and you have succeeded. What does a usual day look like?

Continue with others

Again, imagine everything went great and you have succeeded. What impact did you create on your customers', users' and partners' lives with that success? How did things change for them?

Action: Summarize and posterize. Try to boil everything down into a paragraph that describe a future state for you and your customers. Rewrite and rewrite it again.

Pay attention to every word you use and make sure that the paragraph sits comfortably with you. Then print it out and keep it visible in your working environment.

How to Develop Strategic Hypotheses

Start with customers

Wanting to serve as many people as possible is great. However, it is very difficult to create a product that will serve a majority of a big market from the first day.

There are many reasons that will prevent your target customers from changing their way of getting the job done: Switching costs, human resistance to change, even inertia can be considered a reason.

So, if change is so difficult, what should we do? We start with a super niche group of people who are most open to change. So, naturally, that's a very small part of the potential market. That's how it's meant to be.

Thinking in terms of Blue Ocean Strategy is very useful for identifying people who are most open to change. Ask yourself:

• Who are most dissatisfied with current solutions? Why?
• Who needs a solution but isn't finding any of the options are good enough? Why?
• Who is disregarded by current market leaders? Why?
• What are some common attributes of these people?
• Do I know anyone who fits to this description?
• Where can I find more people like them?

Then go talk to them. This article has ALL the things you need to know about the Jobs to Be Done approach.

Action: If you want something a little simpler for customer interviews, use this article about the idea of "Push and Pull" to clarify who your customers are and what they need.

Identify your value propositions

We value practical benefits. We expect products to provide practical benefits first. For sure.

However, especially in software, practical benefits are not enough to meaningfully differentiate ourselves. They are easy to copy. “This is the way the tech industry works”. So, what can we do about it?

Luckily, people are social and emotional beings. So, we can add social and emotional benefits to the mix and provide more value as well as making it more difficult to be copied.

Social and emotional benefits are the things that make people say "yeah, it's similar but not the same...".

Think about a product you really like. Not just how it works but the feeling of using that product. Then compare it with an alternative that gets the same practical (functional as it is called in the theory) job done. See how you feel about it.

So, how do we know what social and emotional value to provide? First, it comes from your interviews. You need to pay attention to things beyond functionality.

Second, it comes from your choices. Yes, your choices. There will be lots of options for providing social and emotional benefits. You need to choose ones that will sit well with your purpose.

Action: Use Bain's Elements of Value to identify your options. They have a B2B version, too.

Define your position

Now, you will make things crystal clear by defining where you stand. You'll do that by defining polarities.

Polarities help because that's essentially how we tell things apart. Think of the role of contrast in our ability to see. Similarly, we need a clear contrast for things we do and don't do. This will help us clarify our scope and also crystallize our value propositions for the super niche group of people we are targeting.

Action: Use the More About Less About technique to define your position.

How to Test Strategic Hypotheses

Testing, contrary to what you might expect, is more of an art than science. Yes, it is at the heart of scientific method, but designing tests requires imagination rather than analysis. Analysis only comes after you conduct the test.

Let's look at a very high level overview of the test process:

1. Decide what to test and what results count as success. In other words what numbers and/or feedback would show that your hypotheses are valid.
2. Devise a test from which you can trust the results and can execute as cheaply and quickly as possible. This is where you need more imagination and divergence (expanding options without judging them) rather than analysis.
3. Run a few dry-runs to mitigate failure due to simple mistakes. Learn from dry-runs and iterate.
4. Run the test and closely monitor the results to learn from them.
5. Analyse the results and decide the next steps according to your learnings.

Testing is extremely tactical and context-dependent. That is what makes testing more of an art than science for me.

That's why, instead of following a strict process, I believe that you'd be better off getting inspired by the following articles and finding your own way of testing. Much like an artist would do.

Actions:

• Learn about the concept of Riskiest Assumption Testing (RAT).
• Identify your riskiest assumptions. (p.s. I don't agree with the notion of MVP in this article. I strongly suggest you disregard it. I wrote about how I like to think of MVPs here.) Assuming you are at the very early stages of your endeavor, it's more likely that your riskiest assumptions will be about the problems, needs, and wants of your customers and how your product can help them.
• Choose the type of MVP from this list that would be the most suitable for testing your riskiest assumptions. Build a rough version of that MVP. Do dry runs and then launch the test.

How to Design Your Product

Now that you've developed strategic hypotheses and tested them, it is time for you to build things, right? Wrong. Not so fast.

One of the biggest blind spots I see in developer-led startups (software, low-code, no-code) is Design. Design with a capital D.

What do I mean by "Design with a capital D"? Often, the design work in the software industry is reduced to how things look and feel. Sometimes, people go beyond that and add the simplicity element to the mix. Making things easy as well as beautiful.

But that's not all there is to designing products. There is more. Much more.

How much more? Well, so much more that I wrote the article below to describe my personal principles for product design and management. I don't think you need to read it or create your own principles, because I assume that your aim is to start your own business. Not to become a product designer or manager.

However, I'd highly recommend reading the Design and Brand Strategy sections of that article if you are curious about what I mean by "Design with a capital D".

Let's leave the philosophical discussions aside and get practical. Below is an overview of the process I recommend for designing your product. I have summarized the philosophy behind this process in the article above:

Unless we have to invent something new, we are much better off using patterns, heuristics and principles without forgetting to adjust them to the problem at hand. This way, we’ll give people (both users and business owners) what they want: Familiar Done Differently.

Consider your customers' context

Start with considering your customers' immediate context when they use your product.

What's happening? What happened before? What will happen after? What are they trying to get done? How do they feel in that situation? In short: Don't focus on the "why". Focus on the "when".

Think about related products

Consider the other products they use to get things done in relation to your product, as well as competitors' products.

How do those products work? How do they talk about themselves? Any common patterns in their design, branding?

If your product plays well with related products and if it is familiar to your customers, then it's more likely they will adopt your product.

List out your product's features and choose the most important ones

It's important to list the features your product will have and then choose yourself a few North Stars.

You'll "steal like an artist" from these North Stars.

Say that your product has a question and answer feature. Quora would be a good North Star as they are all about Q&A's and have been around successfully for many years.

You can also choose North Stars for your branding, look, and feel. The key is viewing them as a solid starting point rather than things to imitate.

Dig deeper into your North Stars.

If you've chosen a North Star for a specific feature, then use it several times. Try to break it. Take notes on how you'd do something differently and why. Do that for all your North Stars.

Start your design with a user flow, not with a wireframe or any visual technique. One of the biggest mistakes you can make is to start designing the user interface (like screens). As I like to say, “Remember, we are not designing things. We are designing behaviours.” So, we must start with actions rather than interfaces.

Break your product down into features

You will need to create user flows for each feature, but how do you break your product into features?

Luckily, Ryan Singer has given a demonstration of how he uses the shorthand for UI and how he breaks things down into their parts. Watch the entire video.

Use Ryan Singer's shorthand for UI to design user flows.

This will save you hours if not days. You may have ideas for the interface while doing the user flow. Just scribble them somewhere and take a note but never focus on them until you are done with the user flow.

Test your user flows

Once you have a rough first version, test your user flow(s) with a few potential users.

Simply, first give them a quick walk through. Then ask them to critique it by thinking out loud.

You may ask them questions to kick start the conversation: "What did you like about this? What would you change? Why? How would you change it? What is this flow missing?" and similar other questions.

Improve your user flow(s) accordingly.

To design the interface (how things will look) go back to your North Stars. But before that you need to establish an overall look and feel through choosing colors and fonts.

First, choose a font pair from this list. Try to make it familiar to your customers but also try to choose a pair that gives the feeling you want your users to have while using your product.

Next, choose a color palette. Try to choose a palette gives the feeling you want your users to have while using your product – but also try to make it different from your competitors.

Action: Use this article to choose your main colors. Then use this website to create a color palette based on your main colors.

Design your interface in detail

Now, you are ready to design the interface in detail. This is where stealing like an artist will come into play, again. Since, you've already made color and font choices, you can focus on the layout.

Go back to your North Stars and base your interface design on their existing designs. Don't change things unless you have clear reason for changing them. Check out tools like Mobbin for further inspiration.

Remember – design doesn't end with the interface. An extremely crucial and very much overlooked element of Design is the copywriting. So much depends on the language.

It's a great contributor to usability if it's clear enough. It gives your design a deeper character if you can strike a chord. It allows you to test things faster, easier, and cheaper. It's extremely important. I highly recommend investing serious time in it.

Action: Read the basics of microcopy, first. Then continue with writing your copy based on these rules.

Go back to strategy

In the endless iteration spiral we call building a startup, at this step of the Design process, I suggest you take a step back and go back to your strategy.

Specifically, go back to your Purpose and Positioning and see whether what you are building actually fits them. Of course, you don't have to and shouldn't wait until this step. However, make sure you take a critical view of everything and see if you are still after the thing you set out to achieve.

It is fine if there are changes. It would be useless if there were not any changes after so much testing and learning.

However, if the very essence of your purpose and positioning is changing then it's a strong sign that you need to rethink things thoroughly. Otherwise, you might find yourself constantly and mindlessly "pivoting" toward whichever direction might seem interesting at any given time.

This will derail you from the long-term vision that you need to strive for. If you don't have such a vision (which doesn't need to be groundbreaking or world changing) then it'll be very difficult to persist through the challenges in the short-term.

Conclusion

Like any other guide, this guide is incomplete, too. Trying to provide a complete guide is almost an oxymoron in itself.

The purpose of this guide, very similar to an architecture or a model, is to provide enough guidance so that it captures the essence of the reality in the simplest way possible.

It is up to you, the entrepreneurs, to figure things out where this guide falls short and creates uncertainty. That, coincidentally, is the ultimate skill entrepreneurs need to have: Figuring things out under extreme uncertainty.

So, I hope this guide will help you with removing some of the uncertainty you are dealing with and accelerate your journey for achieving your purpose.

Let me know what you think and how I might improve this guide. It's an early prototype of something bigger I'm working on. So meta, I know.

In 2012, a young Czech DJ hobbyist was frustrated with the knobs and faders on his music controllers, so went looking for ways to improve them. That’s when he came across 3D printing, and one of the fastest-growing 3D printing companies in the world was born.

Today, I’m going to show you exactly how Prusa3D became one of the fastest-growing hardware manufacturers in Europe. Then you can take inspiration from their exact strategy to grow a hardware company and create a community of contributors who will help you develop and promote your project with close to no resources.

Some background on Prusa

Josef Prusa, Prusa Research’s founder, is a superstar in the 3D printers industry.

You might have already heard about him but if you haven’t…

• Prusa Research was founded as a one-man startup in 2012 by Josef Prusa.
• His goal with Prusa Research was to create a kind of Thermomix, Europe's favourite all-in-one, easy-to-use kitchen appliance, for 3D printing. He wanted to make a 3D printer that was easy enough that anyone could use it, with guidance on steps and materials.
• In 2018 Prusa Research became the fastest-growing tech company in Central Europe (Deloitte Fast 50 2018) after growing 17,118% between 2014 and 2018
• Prusa Research has grown from humble beginnings to selling 100,000 printers, employing over 410 employees, and setting up a factory in Prague with 9 floors and a hackerspace on the ground floor
• The company brought the Maker Faire to Prague for the first time
• Prusa’s website has over one million unique visitors per month, its YouTube Channel has more than 144,000 subscribers, and its forum has over 143,000 members

Josef Prusa was lucky, but also did a lot of things well that we can all learn from.

How? Let’s dive in.

How to solve a problem of your own, give back, and build trust in growing communities

Before the roller coaster started, Josef enrolled in an economics degree to make his parents proud. This resulted in a lot of spare time, so he and his brother began DJing and building their music controllers.

Josef (above), rocking his DJ skills. Little did he know how his life was about to change.

He was looking to make his own knobs and faders, but found the search into it too long and challenging. He then found the RepRap project and Mendel 3D printer.

As you may know, RepRap is a community project started by Doctor Adrian Bowyer at the University of Bath and it kickstarted the desktop 3D printing craze.

The basic idea is that a 3D printer can print as many parts as possible for another 3D printer and as a result, decreases its cost.

But when Josef was building his Mendel Printer, he was finding it too complex. It required many different screw sizes, there were no slots for nuts, and very few parts were push-to-fit.

So he improved the Mendel by making a simpler version; the Simplified Mendel [sic], and shared the designs on GitHub with the rest of the RepRap community.

The community caught up with his simplified model and started using it over the original, and that’s when people started noticing him.

Takeaways:

• If you’re a student, have spare time, and/or have no dependents, enjoy this time to experiment and try new things. What are you curious about building?
• Identify and solve a problem of your own. What tools are you using? What’s currently frustrating you about them?
• Fix or simplify what’s not working. If you don’t know how, what skills would help you? Learn those.
• Share your solution in a community that’s active and that has the same problem. You’ll benefit from exposure and feedback to make your solutions better. This way you’ll start building trust among a like-minded audience and you’ll be in touch with what people want.

How to create your first prototype

When Josef was trying to solve his problem, printers were still missing one key component to have the ABS plastic print successful: a heated bed. Without it, prints warped and deformed away from the bed.

To tackle this problem, he came up with a rudimentary prototype (shown above) which consisted of a resistance wire stuck between two sheets of acrylic. It didn’t last very long.

Without letting the setbacks defeat him, he went on to create a second version. This one used a tile instead of acrylics, which was an improvement. But still, it only reached about 90 degrees Celsius, which wasn’t enough either.

After nearly six months of persistent work, the PCB Heatbed MK1 (above) was complete. It was the first real product he created.

This new heatbed could reach 110ºC, more than enough for ABS and other high-temperature plastics.

But many parts of the heatbed were either too expensive or difficult to get, so he redid many on his own.

He soon started receiving requests to print his Prusa Mendel’s parts. He also organized a few local build events, where everybody could build their own parts.

There was so much demand that it was time for Josef to officially start Prusa 3D with his brother Michal.

What’s interesting is that he didn’t start with the company name, the logo, and so on – rather, he started with a problem he had himself, and then he shared publicly, both his problem and his solutions, with others.

By sharing what he was doing with others, people who had the same problem could order his solution. And there were many people who shared his problem, which translated into many orders.

It’s also important to appreciate the persistence and patience it takes to continue iterating for six months in order to create a product that works and one that people want to use.

Josef and his brother began selling their first parts without an e-shop and instead sold them through email and a phone number on a webpage. They also hadn’t perfectly optimized their packaging yet. In the beginning, they packed their heatbeds in a pizza box and shipped them off to their clients.

Josef and Michal didn’t let the lack of a perfect tech solution get in their way. They simply found a way that was good enough to get their idea out the door and then made it better as they went along.

They were also proactive in creating awareness and trust with their audience. In the early days, they kickstarted the community by organizing presentations and going to events to educate people about the possibilities of this new 3D printing idea.

Josef also embodied honesty in his sales. If people came to him but were looking for something he didn’t sell or was a poor fit, he just told them which technology they should use instead.

This earned him a community of loyal users who trusted him and regularly came back to share prints and hacks on the new Prusa Printer's online hub. Whenever Prusa was criticized in their Youtube comment section, a flock of fans spoke up in their defense.

Takeaways:

• Start simple before having everything figured out.
• Let go of perfectionism or trying to look like established companies. What is good enough for the stage you’re at to satisfy the needs of the people you can serve? If it’s packaging your products in a pizza box instead of providing a delightful unboxing experience, so be it. If it’s not having an e-shop but just an email and a phone number on a simple website, so be it.
• Focus on creating a solution that solves the problem for good. It might take some time, but if it hasn’t been solved yet, there’s a good chance it’s because it’s hard to solve. Being persistent and patient requires you to commit and invest at the beginning, but once you get through the other side of the problem, you’ll have something people will flock to. It took Josef Prusa six months before he found a proper solution for his heatbed.
• Be radically honest and defend the best interests of your customers. If there is someone else who can serve them better, redirect them there. This builds trust, as people will remember how you treated them with respect.

Should you do everything yourself, or delegate certain tasks?

When we start something and it gets some traction, or even if we just anticipate the traction it can get, thinking about everything that we have to deal with can become overwhelming.

There might be barcode visualization, trademark registration, label design, building walls, building websites, accounting, invoicing, digging drains, dealing with bankers, installing equipment, video-editing, dealing with customer support, and more.

Most of the time we’re not even remotely competent at more than one or two of those things.

So this is the time when we hit a fork in the road. Do we hire or outsource to delegate, or do we do it ourselves?

Prusa’s beginnings are an interesting example of how to go through this period and build for the long term. Below, Josef explains how they went about preparing to scale:

“We never had resellers so we were always in direct contact with the customers in the community and this proved very important for us because you have instant feedback from the people.

If you are just a manufacturer and somebody else is doing the selling for you, you don’t always get all the information back.

In the beginning, it was much tougher for us to do it this way because we not only needed to learn how to make the printers at scale but we also needed to learn how to run a big webshop and how to do the customer support for all these people. It was more difficult but now it’s paying off that we have this direct contact and know how to run every part of the business on our own.”

It wasn’t until October 2013, three years after finishing the initial prototype, that they hired their first employee, Hanka.

How do you get the cash flow to hire people? Well, you sell in advance and produce after. In the beginning, Prusa always had a two week lead time for customers to get a printer.

As they continued to grow, they also hired a Foxconn engineer to deal with quality and a couple more software engineers to lead the engineering team.

They could have spent months or years trying to raise funding through VC or Kickstarter in order to hire people, outsource production and grow much faster.

But they decided instead to invest in the slower and more demanding path of figuring it out on their own, and keeping contact with the customers and their needs. This path has proven to be a much better strategy in the long run.

In 2014, Prusa Research had a revenue of 149.000€, which then grew to 70 million €, employing over 250 employees in 2019 just by bootstrapping the business.

If you aim to change the system, you need to be able to exist independently of it.

Takeaways:

• Embrace DIY and learn to do the critical parts of the business yourself. What skills do you need to learn? Where can you learn them?
• Once you can no longer do it yourself, understand what needs to be done, and when you have enough cash flow, hire people to do the work with you.

What Prusa stands for

Prusa has exploded because it does a few things very well by always putting their customers' needs first without compromising their values or their price. This in turn helps them build a strong virtuous cycle for their development.

Prusa has a long-term vision

Josef knows what he wants Prusa to become. He wants his printers to be able to print any object with any material and through guided steps, much like a Thermomix for 3D printing. And he wants the least tech-savvy person to be able to operate it.

Having this clarity helps him and everyone in the company align their efforts towards a common goal.

They have amazing customer support

The company also keeps investing in the way it cares for its customers.

They go to great lengths to test every single part of their printers to ensure quality but even that isn’t enough to cover everything – so that’s why they have support.

Almost 20% of their employees work in customer support. They have 12,000 live chats per month in nine languages and deal with over 11,000 emails each month.

Prusa provides high quality products

Investing in making the designs of their 3D printers more functional, simple, and of high quality allows them to avoid competing with the nicer-looking but more expensive 3D printers.

They make an affordable printer

This means that they are not too expensive for everyday consumers, and not too cheap for companies.

They’ve also made their 3D printer upgradable because it saves money for their customers and it builds their clients’ autonomy by helping them learn about the construction of the printer’s hardware.

All Prusa's work is open source

Prusa’s clients are “normal Joes” as Josef describes them, and most don’t care much about open source. But the company does.

Those who care about open source provide valuable contributions that can be added back into the products. Some people will make improvements, some will fill in new code, and all of it helps make the printers better.

The open-source approach is also good for users. Those who want to do modifications find it much simpler because they have the original sources for the printer parts, the firmware, and the electronics.

Josef even has a tattoo of the OHSWA logo to keep himself accountable and honest to the open source vision.

Source: 3D printing Industry

Open source makes it easy for the idea to spread and upskill people who can find new use cases to increase the company’s pace of innovation, and it makes it more affordable to its clients.

They partner with distributors and support their clients even though it decreases their margins

Another counterintuitive thing Prusa does for its clients is that it supports the customers serviced by other distributors.

Many companies would forfeit this channel because it demands high margins and the distributors don’t do support. But they do these distribution partnerships anyway to make it easier for the people they serve to discover and access their printers.

And even if they make no extra money through these channels, they still give them the same level of support as those who buy from their website.

Why? Because caring for their customers is what makes it safe for them to then recommend Prusa to their friends and family, driving more business by word of mouth.

Takeaways:

• What is the long term vision of what you’re doing? What happens as you keep developing your organization? What results are you helping people achieve?
• How can you invest in better supporting your customers?
• What parts of your project can you give away for people to build and learn with you?
• What partnerships can you build to distribute your project in places where people need it?

How Prusa Builds and Invests in the Community

We’ve already spoken a lot about how much they invest in customer support, but Prusa also invests heavily in their community.

This does two things: it builds proof of what their product does in the world, and it helps scale even further what their customer support service can do.

To gather their community they do a few things.

The first thing Prusa does is offer two options to customers: They can either buy printers as kits or assembled. 80% of clients buy the printers in kits. Besides saving time in production, this allows the clients to learn how to build their printers and understand how they work.

This approach is raising a generation of makers who can create and fix instead of throw away, building a lot of goodwill for the Prusa brand.

To keep in touch with the community, in the early days Josef Prusa tried to go to as many shows as possible so that he could talk to fans face to face and hear about the awesome projects that could come to life with the help of their printers. He went to Maker Faires and to DIY or 3D-printing events.

Now that the company has grown so much, he can’t go to as many events. But before the pandemic started, there was a team of three to ten people traveling around the world two to four times a month. And they were also organizing their Maker Faire in the Czech Republic.

Takeaways:

• Where are your community members hanging out? What blogs or magazines do they read? What podcasts do they listen to? What events do they go to? What youtube channels do they watch? What newsletters do they subscribe to? Who do they follow on Twitter, Facebook, or Linkedin? What forums or groups do they participate in?
• What resources do they need to get started that you can facilitate? How can you give them the tools to create what you do?
• How can you invite users to participate in the development of your product? Can you open your files and designs for them? How can you invite them to give back and showcase their work or the skills they’re building thanks to you? Where could you use this as proof that your product works?

How to Engage the Community

Many people understand the value of giving free stuff away online to attract a crowd. But I feel that many entrepreneurs haven’t embraced the opportunity and the value of connecting the people in their community with each other.

This is a very powerful idea that can go a long way in building trust and reciprocity with your brand and in getting the community members to spread the word and interact with stories of what you do.

One more powerful thing that Prusa is doing is figuring out how to connect the isolated Maker tribe, and at scale.

Once they gather their community by giving away their designs and connecting with them at events, the next challenge is getting these people to engage. And Prusa does a remarkable job at that.

They’ve created a series of resources that make it easy for people to learn the skills and tools they need to become active members of the community.

In their online hub, they share resources for learning and practice, such as a library of 3D printing models with files, and free guides on how to start 3D printing.

Once people are on their website to grab these resources, they can connect with each other locally or online through a map or in the forums to reach out for support or to go for a beer.

As a quick overview, Prusa provides the resources needed to learn the tools and the skills required to set up and hack a 3D printer. There are manuals, such as a free ebook to teach the basics of 3D printing, assembly instructions in video and ebook form, troubleshooting guides, and of course the downloadable drivers and firmware.

Once people have what they need to learn the basics, they can jump into the Forum to talk about their printer model, stay up to date with General Announcements and releases, find those community members in the Hall of Fame, and discuss the software.

Takeaways:

• What resources does your audience need to develop the skills required to use your product and to participate in the community in order to help each other?
• Once they trust you, how can you connect them to find support among their peers? What exchanges can you facilitate or what spaces can you create for them to gather and talk about their questions?

In Summary

Prusa’s approach helped them grow over 17,000% without a sales team, only through word of mouth.

It helps that they serve the fast-growing 3D printing market, but still.

Prusa has become a big player and a beloved brand in their industry, proving that you don’t need a huge marketing team or budget to get similar results. You just need a smart and intentional plan.

Here are the key takeaways you can borrow, modify, and adapt for your own business based on Prusa’s real-life marketing tactics:

Takeaway #1: Build a skill to solve a problem of your own

What tool are you using that is not working as you wish it did? Learn the skills to fix or simplify what’s not working.

Takeaway #2: Share your solution in public

Once you create your first working solution, share it with communities who already use these tools and have the same problem as you do.

This builds trust, reciprocity, and if people want to buy your solution or they have other problems you can build on, they can tell you.

Takeaway #3: If it’s your first time, be patient

When we first start, we don’t have all the skills we need to find a solution to a problem. Be patient and persistent and embrace failure and rejection. It’s by getting into action that you’ll figure out what’s not working or missing, and what needs adjusting.

Takeaway #4: Start simple, even if you don’t have everything figured out

Let go of perfectionism or trying to look like an established company. What is good enough at the stage you’re at to satisfy the needs of the people you can serve? What is good enough for now to solve other people's problems, build your product, and ship it?

Takeaway #5: Learn to do everything yourself and become autonomous

Don’t delegate too soon. If your goal is to change the system, you’ll have to learn to be autonomous early on and stay in close contact with your customers.

When the time comes to delegate, you’ll know what needs to be done and hire the right people for it.

Takeaway #6: Be radically honest and defend the interests of your customers

If there is a competitor who can serve them better, redirect them there. It will build trust as people will remember how you treated them with respect.

Takeaway #7: Be clear on what you stand for

What is the long term vision of your project? If money and growth is a means to an end, what is that end meant to achieve? What can you do to accelerate or scale this?

For Prusa, it was investing in outstanding customer support and sharing their work in open source to create both a delightful experience and to involve outside experts in their innovation.

Takeaway #8: Find and gather your community

Go meet your community where they hang out to stay in touch with their needs and to connect with them. What forums or groups do they participate in? What events do they go to?

Once you’ve found them, create spaces for them to gather and connect. Josef Prusa started by participating in the RepRap forums and by going to Maker events. Later on, they started organizing their Maker Faire in the Czech Republic.

Takeaway #9: Engage the community

Give them the resources and tools they need to get started. Then invite them to participate in the development of your product by opening your designs.

For those who contribute, you can showcase their work and skills to show your gratitude, and use these contributions also as proof that your product and community work.

Thanks for reading. Inspiration for this article came from The Road to 100,000 Original Prusa 3D printers. You can watch it here:

In this article I will share the story of how I became CTO of a software as a service (SaaS) company. It all started about 3 years ago when I was going to hackathons for fun.

At the end of the article you can find some tips and advice I would give to aspiring entrepreneurs as well as some reading recommendations.

It was – and still – is a wild ride!

Our company team (we now have 8 more employees!)

Although I have a good knowledge of entrepreneurship, don't just take my advice at face value. Learn from books, from other entrepreneurs, and from your environment in order to triangulate how best to act in a given situation.

My First Hackathon – Which I Lost

It might sound off, but I had no interest whatsoever in entrepreneurship or business 3 years ago. I was more of a researcher in spirit than an entrepreneur.

From studying memory at the molecular level, to helping schizophrenic patients learn better, or predicting consciousness recovery in patients with traumatic brain injuries, my mind was deeply focused on the frontiers of science.

However, I had a deep passion for programming and for finding ways of building tools that didn't exist before.

Like the time I built a brain computer interface that was compatible with a Transcranial Direct Current Stimulation electroencephalographic headset (that is, it stimulates the brain by giving shocks and lets you control a kind of ping pong game). I just love to build stuff.

Cutting edge graphic from my brain computer interface

So three years ago, my brother wanted to find a new job as a software developer. We figured out that we could attend hackathons to help him get noticed by recruiters.

It was my first hackathon so I was pretty excited to spend two days building something. Our team was composed of myself, my brother, his friend, and one more member (who didn't do a lot, but was still there).

It was two days of heavy coding, and at the end we came up with a pretty cool algorithm to pattern match people with jobs given some characteristics.

On top of that, I met nice people that, like me, love to build stuff. We ended up among the finalists and came in fourth during the final presentation.

Here I am trying to figure out why the clustering is not working

What I learned From My First Hackathon

It was a bit of a bummer not to win, but I realized something important then: except for the participants, no one really cared what I coded during these two days.

It was mostly the presentation of what we wanted to build that mattered. We should have spent a bit more time making a very compelling PowerPoint instead of focusing on the development of an algorithm!

It was a fun learning experience, but my brother didn't get a job out of it – so we were back at square 1.

My Second Hackathon – in Which We Won a Special Prize

I was ready to take a small break from hackathons for a while. However, my brother decided to sign us up anyway. So his friend and I to go to another hackathon right after the first one. I would have refused as I had other stuff to do, but he had already paid the sign up fees.

This hackathon was a bit bigger than the previous one and there were still a bunch of recruiters there. We figure that this could be our second shot at getting him a job.

The theme of this hackathon was open data and environment. So we were in a good position to make something cool with my background in machine learning.

A lot more people where present at HackQC which was nice!

Knowing that the presentation was everything, we decided to be a bit more strategic with this hackathon. We combed all the different prizes we could win and selected the one with seemingly the least competition. The project would deal with the prediction of combined sewage overflow.

We then split up our team of four (another friend of my brother's joined in) so that half of us were working on the coding and the other half on the presentation.

The name of our team was “Égout Quebec” which translates to Sewage Quebec (branding wasn’t our strength). Here is the excerpt from our competition log on DevPost in French:

ÉGOUT QUEBEC permet de prédire le débordement des égouts et d’en avertir les amateurs d’activités aquatiques. Ainsi les personnes désirant aller faire des activités aquatiques pourrons éviter les zones polluées par les déversements d’eau usée. De plus, des conseils seront dispensés aux gens des différents quartier, de façon à réduire les risques de débordement.

ÉGOUT QUEBEC utilise une technologie basée sur une intelligence artificielle. Celle-ci peut déterminer lorsque les égouts déborderont. Ses analyses et calculs sont basés sur des données disponibles sur le site de donnée Québec. Finalement, les différentes villes auront avantage à utiliser ÉGOUT QUEBEC.

Grâce aux prédictions et aux analyses de la plateforme, il sera possible de concentrer les ressources de la ville aux endroits les plus problématique.

All this basically translates to “we found a way to solve the problem using a random forest + a bunch of data”.

We actually ended up winning a $1000 prize, which was huge at that time! We even got a nice glass trophy in the shape of a water droplet. It was less challenging than the previous hackathon because we had a better plan for what we needed to do.

Here we are at the podium (still technically fourth place though).

What I learned From My Second Hackathon

This hackathon made me realize that presentation was indeed important. But I also discovered that focusing on problems that people don't find interesting is a good way of increasing your chance of coming out on top!

Winning felt good and I was ready to take my share of the $1000 prize and call it a day...

My Third (and Last) Hackathon – Which We Kinda Lost Again

However, the $1000 prize came with an automatic fast-track to the semi-final of yet another hackathon! This one had higher stakes with a $25,000 prize.

We met up at a coffee shop to figure out if we wanted to split up the money or to use it in order to take our project to the next level.

After looking at the other participants' projects and the rules of the competition, we decided that we actually had a good shot to at least get to the finals. This would unlock some more funding which we could use at will and would give us a nice trip in the summer to a lake in Ontario.

This hackathon wasn't like the others in the sense that it ran for the whole year. It was more of a take-home hackathon, which was great for me since I didn't have to do that insane two-day time crunch routine over a weekend.

We changed our name to EGC Labs and managed to get a website together to advertise our sewer overflow prediction solution (which was working surprisingly well). We then went to the semi-finals competition in Ontario, and to our amazement we moved on to the final!

Here we are as finalists! I didn't go all the way to Ontario for the semi-finals, though.

This was great! We had a very good shot at winning more than a small stipend, and maybe starting a business out of this thing. To help us bootstrap ourselves, Aquahacking generously gave us $2000 and École de technologie supérieure (ÉTS) gave us $1000 for travel expanses.

However, we still didn't have any customers for our solution, which was a bit problematic.

We tried to contact a bunch of cities in Quebec in order to see if they would be interested in our sewage overflow application. We had some pretty advanced discussions with a few cities, however their process was so slow that we got very near to the finals without any concrete validation.

The final was a 5 minute presentation in front of a big audience with some investors present.

Things got a bit more tricky when we got closer and closer to the presentation date. The rest of my team started to become less and less responsive. I ended up not being able to reach my brother's friend who had joined at the HackQC competition.

This quickly followed by my brother losing all interest in the competition and focusing on other stuff. We were left with myself and my brother's other friend (Félix) who joined in the very beginning.

He was also starting to slip out of the picture because nothing seemed to be moving forward, as I was the only one left coding. I wasn't very interested in that project either, however one thing I hate is half-backed projects (even more when they are public).

Our faces were plastered everywhere

I felt that it would have been a waste to stop so close to a conclusion. So I took it upon myself to jump start the project by coding the app's user interface, getting some branding going, and creating our business cards for the event.

As things started to pick up Félix started to become more and more involved (which was a blessing because he was the one pitching!).

We were still finalizing the PowerPoint the night before the presentation in the hotel room. After all this hard work we had something pretty solid (by my standards at the time, anyway). We've ended up winning fourth place in the competition:

Us receiving the 4th place trophy (again) with no money whatsoever associated with it haha

We went from a team of 4 to 2 people and were able to get that far. However, it was exhausting since I had to do so many different things that were not in my core zone of competency.

What I learned From My Last Hackathon

I learned two very important lessons during that adventure:

• Having motivated teammates is the most important asset in any endeavor. If we had everyone pulling their weight we would have had more chance to win!
• For a startup, having clients is the ultimate measure of success. We did everything right, except making sure that we had paying customers. In the end this is what kept us at 4th place.

We won a big $0 in that part of the competition, and once again I thought that was it. I had coded some cool Flask applications, went to the final of a big hackathon, and learned some valuable lessons. Until I realized...

How I Learned About Entrepreneurship at An Incubator

Being part of the finalists of Aquahacking automatically gets you a spot in one of the provincial incubators for startups, which happened to be Centech for us in Québec.

I didn't really know what an incubator was (except in a biological sense), so I wasn't particularly excited. We had to make a pitch for our "startup" to the incubator panels even though we had a reserved spot. I let Félix do it without me, as I had other stuff to focus on.

Centech is inside an old planetarium so it has that funky circular shape. It's a pretty cool place.

At first I didn't go too often to the entrepreneurial classes and I was starting to think that this whole hackathon-thing was becoming a huge time-sink. However, I stuck to it because Félix was very motivated by the whole experience.

So I decided to give it a serious shot. I started attending the entrepreneurial classes (which were amazing), I did the homework, and I tried really hard to make our sewage company work.

Lots of entrepreneurs in our 2018 cohort, try to find me!

Frankly speaking, it was amazing. It was genuinely fun to try and make something novel. And being mentored by people that had built incredible products that helped millions of people was incredible.

The class that I was in was also very motivating, as we had people from all backgrounds and oddly enough most of them were graduate students, like I was!

I really got the bug for entrepreneurship. It was like doing research, except I could directly see the results of my experiments in a matter of days. It was like combining the pleasure of discovery I had while doing an experiment with the freedom of programming for a side project.

However, after reading the books and learning the material, I realized that we'd done everything upside-down for our budding startup. We had built the technology before even validating that there was a sustainable business out of it (silly us!).

We were ready for our very first pivot, which in entrepreneurial jargon means tweaking your business in a significant way in order to not crash and burn.

How We Made Our First Pivot After Learning that Our Startup Idea Was Doomed

Our combined sewage overflow predictor was working great. However, no one was willing to spend money on it.

We were targeting cities in order for them to be able to proactively do something about the overflow of raw sewage into their rivers (which, by the way, is a worse and more frequent problem than you think). But these cities had such a long cycle to sell to that we would never be able to grow this business.

One thing that we realized during this project was that the majority of the data that was available for the competitions were in a very bad shape. It took us many hours of cleaning and we had to develop some very custom toolsets in order to make the cleaning efficient.

We had also talked to a few of the judges at Aquahacking and what they were most interested in was the portion of our business that related to data cleaning.

So that was it! We would become a data cleaning company. For about three weeks we were frenetically searching for customers, making plans on how to make this type of business work, and coding outlier detection algorithms.

This would have been us inside the datasets for the rest of our lives: Photo by [Unsplash](https://unsplash.com/@mkjr?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit">mkjr / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

However, after meeting with our mentors at Centech, we realized that what we were building was a service company. Almost no data is similar, especially when it comes from different sources.

The amount of domain expertise we would have to gain in order to be efficient in one industry would not necessarily transfer easily to another industry. There was a lot of manual work involved in this and all our ideas for making it more automated were failing.

Now, there is nothing wrong with making a service company. It's a great type of company if you are very interested in your industry. But we did some amount of introspection and we realized that we weren't really passionate about data cleaning.

We were passionate about automating work and improving efficiency through technology. Building a data cleaning company where most of the work would be manual and not very efficient wasn't very exciting for us.

We were ready to make our second pivot, which would be our largest so far.

How We Made Our Second Pivot

During the Centech program we had met two other entrepreneurs that had a problem that was complementary to ours. They had a lot of validation from potential clients whose problem could be solved by technology. However, they didn't have the technical skills to make the technology required to power their business.

I had helped them out a couple of times in order to get them started with building their web application since I'd already done something similar for EGC Labs.

Helping out other entrepreneurs without expecting something in return is very common in this type of environment. The more I helped them, the more we realized that we could get way more done if we were a team of 4 instead of two teams of 2.

We went for lunch to discuss what a potential "merger" of our two ideas would look like. After discussing for a week, we decided to ditch the EGC Labs project completely, as it had the smallest chance of success. Instead we would join forces with their idea, which was called GRAD4.

That was the second pivot for Félix and me. It meant completely dropping a project that was leading nowhere and joining another one that we were much more excited about.

Félix pitching our new company instead of the data cleaning one

During the next weeks, we were absolutely crushing it. We did everything right. We officially incorporated our company. We made a few plans as to what the actual application would need in terms of functionality so it would deliver value to our potential customers. However, we didn't wait for me to complete it to start selling it!

The other two co-founders were already on the road talking to people who'd showed interested. They were gathering checks for a 1 year subscription to our platform, which didn't exist yet. The $500 yearly subscription would start when we launched the product and we were very upfront that we were in the process of building it.

Getting people interested in your project is one thing, but getting paying customers before building a SaaS app is the holy grail of business validation. By doing so we were able to get about 15 checks that would help finance the development of the product.

We also won a $1500 elevator pitch competition around the same time because Félix was very focused on practicing his pitch.

All of these small wins compounded during the program and we ended winning a $15,000 prize at the end of the incubator called the Unicorn prize.

This was great, but more importantly we secured a spot in the next stage of the incubator which was the Propulsion program. This would secure us an office and some additional perks that would help our company succeed.

Cozy office in the basement of Centech. It was nice, but there was lots of noise because of pipes. You can see a wild cofounder working through the night.

What I Learned From My First Startup Incubator

During that part of our young company's adventure I learned a few important lessons:

• Clinging onto an idea because it was yours even though all analysis tells you it's a bad one is usually a bad idea.
• A larger founding team is more productive than a smaller one. It also allows for cheaper labor as no one is getting paid at the start.
• Asking customers to pay for an in-progress idea is not as difficult as you may think. If the pain is big enough for the customers, they are usually very supportive of having someone fix that mess. Even if the probability of success is low.
• The technology part of the business is not that important.

We Have Money, Now What?

We now had gathered a fair amount of money and we had multiple options in front of us:

• Either we keep the money and pay ourselves.
• We keep the money and don't use it in case we fail to make the app and we need to reimburse people.
• We use the money to hire people to speed up the development.

The first idea was wasteful, and it would decrease the probability that our company would succeed. The second option would just let our funds sit idle. So we decided to go for the third option.

How We Scaled Our Startup Past the Founding Team

During that summer of 2019, we made our first two official hires to help me with the development of the platform. They were software engineering interns from the ÉTS (École de Technologie Supérieure). One intern would be focused on the backend side while the other would be focused on the frontend side.

Our product was a simple CRUD application that would allow buyers who needed metal parts manufactured and suppliers of metal parts to find each other.

It was basically a sort of marketplace where buyers would create what is called a request for quote and the suppliers would create a quote to say how much they could build the part for. Pretty simple!

The technology we choose to use was the following:

• Django + Django REST API for the backend.
• React + Redux for the frontend.
• Bootstrap for the styling.
• Heroku to host both applications.
• GitHub for remote source control.

This was our setup at first. Credit: https://blog.usejournal.com/react-on-django-getting-started-f30de8d23504

Choosing the technology was up to me as the CTO, and I honestly decided to go with what I thought would be better in the long run. I was already familiar with Flask, however I knew a bit of Django too. Seeing that a lot of the functionalities I needed were already pre-built into apps made me lean toward it.

I chose React on the frontend side because I had played around with it 6 months prior and found that it was such an easier way to build applications than the traditional way I was used to.

However, in retrospect I think I would have greatly simplified the stack. I would have only used Flask for the following reasons:

• I was more familiar with Flask than with Django.
• We didn't need to have a separate frontend, as the application we needed to build was very simple. Simple templates would have been enough for a first proof of concept.

Just this would have been more than enough

However, we went with this tech and we learned a great deal in the process.

What I Learned During My First Months as CTO

One lesson I learned from this first foray into making an application customers would actually use is that overthinking scalability is oftentimes useless.

Working with what you are already comfortable with and delivering something as soon as possible is much more useful as you learn more rapidly. This is actually what is most important in a startup.

The more learning you can do (about the business, what customers want, how to talk to them) the more probable it is that the next thing you try will work.

After a few iterations, we were finally ready to launch our closed beta with the customers that had already paid for our service.

How We Did Our First Product Launch (Closed Beta)

We were able to make the first version of the application at the end of the summer of 2019 and launched it for our users (1 month later than we promised). It wasn't pretty and it was barely working.

We had to babysit our users throughout the whole process and the buyer section of the application wasn't usable. We had to do the work manually for all our buyers while the suppliers were able to create quotes.

What was great, though, was that we continued to be able to get checks from people who were interested which helped fuel development. We made a few mistakes on the hiring side, though. We hired a friend of one of the founders who, although experienced, was a jerk to the other more junior developers.

This was the first firing I had to do, and I'm glad I did it. Creating an enjoyable work environment is much more important than technical prowess, because at the end no one wants to work in a bad environment for long.

Having people stick around for the long run in a startup environment is crucial for the company's success. I believe it is one of the reasons our startup is still alive.

As development was chugging along we realized that we had to structure the company a bit more than what we were doing. Thanks to being next to so many startups and successful companies at Centech, we could learn from each other.

During that year, we focused on getting financing going (this is a super important part of business and should be prioritized). We also focused on getting some sort of marketing going, making actual designs that made sense instead of winging it, and making sure our team was staffed by full-time people instead of only interns.

We also moved from the basement of Centech to an office space with windows on the second floor which was actually pretty nice! We maxed out the capacity pretty quickly, though, and the founders had to start working in the dining area of the building so that the employees had more room.

This was way too crowded in retrospect, but at least the view was nice

What I Learned From My First Launch

I learned a great many lessons after our first launch:

Don't do an official launch. It's useless. We put so much pressure upon ourselves to impress the paying customer with a pompous launch, and we were afraid that they would be mad at us if we didn't deliver.

The truth is they didn't really care. When we sent an apology email saying that we had to delay the launch no one complained. I'm pretty sure they were actually amazed that we were able to get something up and running so quickly.

Even if you have paying customers for your SaaS application, prioritize doing manual work over building an application. In retrospect, I would have made a simple form where the buyer could upload a Zip file containing the request for a quote which would be sent to the founders' email address.

We would then send out this request manually to the manufacturers we knew would be interested in this type of work. That would have delivered value way faster to our users and released the pressure on development.

It would also have validated a lot of hypothesis we had that would have accelerated the development work.

Stay focused on very few things and make sure that this focus is explicitly written down somewhere. At some point I was building a blockchain-powered smart request for quote because it was hyped up by one of the co-founders who knew someone working with blockchain technology. That was a solid waste of time and I'm glad I killed that project soon after.

We were starting to pick up steam and we finally had something that we could show the world. It still wasn't pretty, however customers saw the value in what we were building and we knew better what was creating value and what was not.

We were ready to open our beta to increase the amount of users in our application!

How We Opened Up Our Product to More Users

After tweaking the platform using feedback from our early users, we now had a better understanding of what exactly we needed to build. We were now ready to increase the amount of people using our platform and start to increase the output of the sales (which the founders did).

This put more pressure on our application and we started to experience downtime. We knew that we had to improve the way we were building this product if we wanted to scale to more users.

We asked an experienced software architect, now part of the team full time (thanks Karim!), to help us out. This really gave us a solid direction to follow. Here is what we changed:

• We moved to AWS to have more control over the cloud environment.
• We moved to Gitlab to have an easier-to-use CI/CD environment.
• We added automated testing to our application.
• We started to migrate toward Material-UI instead of Bootstrap.

After improving the way we worked, we now had a fully working CI/CD setup and a more robust application that was rigorously tested. The amount of downtime we experienced was drastically reduced and developers were more confident about the changes they were making. It was a more enjoyable development experience, too.

Gitlab is a very enjoyable work environment and reduces a lot of the complexities with lots of tooling. Credit: https://about.gitlab.com/

What I Learned From My First Open Beta

During that period, I learned that the minimal viable product (MVP) phase of the product is necessary. But when transitioning out of it you shouldn't hesitate to ask for expert help.

We now had sales giving us more clients (which were still a bit difficult to get, but coming along at a constant pace) and the application provided more value than before.

We were ready to ask for our first real investment!

How We Got Our First Real Investment

We applied for a funding from Front Row Ventures which is a venture capital fund entirely managed by students and which only invests in student-led startups across Canada.

We met with the people from Front Row, and explained what we were doing and where we were going with all of this.

We ended up having to do a 25 minute pitch in front of a full panel of students who were asking solid questions about the business and the technology.

This was great because we knew that if we got the funding we would not only have the cash, but also new connections that could be there to answer questions and make strategic introductions for us.

It was great, some of these people went to the same university as I did!

Well, we ended up getting the funding and the people at Front Row were very helpful in many aspects of the company!

What I Learned From Getting Our First Funding

This was another important lesson I learned during that time: when choosing a funding partner, it's not only about the funding. It's also about how much help they can provide.

Front Row ended up opening many more doors for us and ensured that their investment had all the possible tools to succeed.

What Our Day to Day Routine Looked Like

Everything was going pretty well for us on the business side. However, the pace we were following was a bit worrisome. We were an archetypal startup where employees would come at the office from 9 to 5 and where the founders worked 80 hours a week.

Meeting on the weekends at the office to plan stuff out and clear up more tasks was routine.

I wasn't too happy with this because this type of work isn't sustainable in the long run – and I started to see signs of burn out in the others. We also weren't very structured, the documentation was poor, and we had almost no processes clearly mapped.

It was at that time that I started to read more about how to structure a company properly in order to maximize our chances of success (see readings at the end).

Then, out of nowhere, we started to hear about the possibility of a pandemic hitting our Canadian shores...

How We Reorganized When COVID-19 Hit

Some employees were very afraid of the virus and of getting sick. There were no cases in Canada yet, but some of the employees had family abroad in areas more advanced in the pandemic's course.

We started to think about what we could do and we realized that we didn't absolutely need to have people come in the office to do their work. All of the work could be done remotely just fine – it was just the culture that we'd set up that required people to show up from 9 to 5 every day of the week.

This type of schedule was directly taken from what we were all familiar with, but we realized that we didn't have to do like all the other companies we'd worked for.

We decided that we would allow everyone that wasn't comfortable going into the office to stay home. I personally decided to not show up to the office and most of our employees followed suit.

_As long as people had a the tools they needed, they didn't need to go into the office: Photo by [Unsplash](https://unsplash.com/@xps?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">XPS / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

This was great because we soon realized that a lot of the shortcomings of our company's structure were hidden by the fact that all employees were available in the office every day. Everyone was always trying to setup a Zoom meeting at random hours or calling at any time of the day to ask for operational tasks status.

We also realized that people had a hard time finding where all the information was, and many different people asked the same thing many times.

I decided to read a bit more about how to structure remote work efficiently so we read the remote playbook from Gitlab and implemented some changes:

• We removed the silos between the different teams by making all communication public and via written messages.
• We organized the documentation so that people would put their files in a shared drive instead of sending them on the instant messaging app.
• We instated a Kanban methodology for all departments, not just the people working on the technology since tasks weren't properly tracked.
• We reduced synchronous meetings by only scheduling those that were necessary and by having the results of the meetings communicated in one form or another.

This helped a lot! However, it took time before it really took hold. People were still having private messaging discussions when everyone could benefit from what was said. Synchronous meetings were still the default for a lot of people to share information.

Here are the co-founders trying to keep 2m distance in our first pandemic meetup (and photo shoot)

But it got better. By putting a lot of effort into making remote-work work, we were drastically improving our company's productivity to a level way above that pre-pandemic.

In a sense it was helpful that we were forced to experience remote work (as we were in full lockdown for a while) because it gave us the necessary buy-in from people that were skeptical that this was possible.

There was no other choice but to go all-in to remote work, otherwise the company would've just ground to a halt. We had employees to pay, so waiting the pandemic out wasn't an option.

In the business sense, we were very fortunate as our platform was useful for the manufacturing industry which couldn't do business in person anymore.

Some startups that we knew of weren't so lucky and their whole business was now impossible to operate within a very short time frame. Most of them had to close shop or do some radical pivot.

What I Learned From Pivoting to a Remote Company Structure

The first few months of the pandemic taught me some very important lessons:

Starting a startup is very, very, very risky. If you had started a ridesharing startup in 2019 and things were going fantastic for you, you would still have had to stop that business once the pandemic hit in 2020.

No matter how prepared you are, there are always risks and unforeseen events happening on a daily basis.

Working on the company is more valuable than working for the company as a founder. What I mean by that is spending time structuring the company and making adjustments to how people work in order to increase productivity is invaluable.

You can't expect employees to do that on top of doing their regular work. It's up to the founders to set up a structure that make sense and to always be improving it.

Remote work will improve your team's productivity compared to in person work (when possible) only if you take the time to make it work. Trying to reproduce an in-office way of working remotely will lead to an obvious decrease in productivity. Drastic changes needs to be made in order for this type of work to be useful and it requires a leap of faith.

We were still growing during that time as we were hiring more people to sustain our rapid pace. We also made a major pivot in how we were generating revenue by ditching our subscription-based model to a transaction fee model. This allowed our sales team to rapidly increase the amount of companies we enrolled in our application.

Our first version of the application started to show signs of not being optimally adapted given all the new information we'd collected from our customers. So we were working on revamping it with an improved design and user experience with a dedicated UI/UX team.

The Improved Version of the Application

We launched the revamped version of our app (this time without a hard deadline) and the reception was great. This is when I started to feel like we actually launched a real product and not a MVP to validate a need.

You could now see the part directly on the platform (we've used xeogl for that)!

The sales of our product increased dramatically as the user interface was great and the experience made sense to prospective users. We went on to do some more major refactoring and clearing up technical debt.

We knew that the added load on our platform meant that we needed to have something cleaner to work with. This was important as technical debt will always creep up and you can't just always build features.

We were slowly emerging from the bootstrapping phase of the company to more serious territory and it felt great. We made some more hires in the customer care and the marketing side. We improved month after month how the company operated.

Around that time, we decided to implement two systems that would improve our productivity:

Objective and Key Result system: This really switched our whole mindset from working long hours to working on objective attainment. By having concrete goals that would improve how the company was doing, it allowed everyone to focus on what really mattered.

It also allowed us to stop tracking when people were working or when they were taking vacations. As long as the objectives were worked on, it didn't really matter what the employees' workflows were (as long as they were not overworking).

EOS System from Traction: This system was a very good foundational system to ensure that everyone stayed aligned. It really improved how our meetings were structured and laid the foundations for the vision of the company.

I used to scoff at the thought of having a vision or core values. But after reading the book and implementing it, I cannot understand how we got as far as we got without one.

This aligned everyone to a level that we didn't think possible and allowed us founders to make better decisions for the company.

It now felt that we were really running at a solid pace. Every month we had major improvements or good news in the company. The whole startup thing felt easier and was more enjoyable.

What I Learned From My Second Product Launch

I learned another good set of lessons during the time of the launch:

Your job as a founder is to "elevate and delegate". At a certain point, if you are still working on the minutiae of the work you are wasting resources.

It is usually way more cost effective to hire someone else that is more competent than you to do the operational work and to move on to another position that doesn't have staffing.

By de-risking and laying the groundwork for a section of the company that is weak you are ensuring that it's worthwhile to hire someone and that this person has something to start with. This is priceless.

No one can work 80 hours a week on different job types effectively. We realized this when we were looking at what the weakest points of the company were. It was always the spot where someone that had 3 different hats was working because there wasn't enough time to do quality work.

If you are working on 3 different positions as a founder and you work 80 hours per week, it is the equivalent of working as a tired part time worker. The documentation will be poor, the process will be non-existent, and mistakes will start to show up.

As soon as we saw someone work more than 40h a week it was a big red flag that we needed to distribute the load onto someone else.

Part-time and volunteer workers are usually a waste of time. Once we were picking up more speed, we found ourselves constantly waiting for the part-time worker or the volunteer to finish their part of the work. This was holding us back so we made it a policy to not hire part time workers again.

It's different for interns though, as they have a well contained work arrangement. For instance, we currently have 3 interns working on various machine learning projects as part of their PhD. This is perfect because the work that is given to them is well balanced and we know what to expect.

Around the time of the new platform release, we started our first accelerator programs.

The NEXT AI and EcoFuel Accelerators

I didn't really know what an accelerator was at that time. However by being in two I quickly understood the difference between an accelerator and an incubator.

An accelerator's job is to give tools to an already up and running startup to accelerate their growth. On the other hand, an incubator is where startups usually begin.

One thing that is very useful in accelerators is that they provide startups they select with funding. By doing the NEXTAI and EcoFuel accelerators we were able to get $100,000 in total funding!

It was way more fast-paced than the incubator we'd been in. We had virtual classes with incredible entrepreneurs and got technical classes with researchers in machine learning such as Yoshua Bengio.

We also got to meet other amazing tech entrepreneurs living similar challenges in trying to get a startup to scale during a pandemic.

Here we are keeping the 2m distance for a photo shoot.

It's at that time that we officially founded the more "research-y" side of the company that dealt with making AI models and working on the data we collected. We staffed that section of the company with PhD students and graduate master's students (and me!).

It's also at that time that we decided to raise our seed round of venture capital (VC) funding. We made this decision because we knew that we had something great, however we were in the type of business where we needed to scale fast to deliver the most value to our customers.

The more people use the platform, the more valuable it is for the people using it. Therefore, getting funding to crank up the sales and marketing is a must. We put our CEO on that full time as it is indeed a full-time job.

Around the time when NEXT AI was ending, we had one of our first major financial drawbacks that would forever change the way we saw failure in our company.

We thought that, just like at Centech, we were in a very good position to get the financing that comes at the very end of the program. However, we were in the finalists but not in the top 3 winner startup.

This was a major blow as we thought we were very solid during the whole program.

After gathering more information about why we weren't shortlisted, we realized that there was a major communication gap between what the organizers of the program thought we were doing and what we were doing.

They didn't realize how advanced our product was and were not aware of all the cool AI modules we were building to complement our offering.

What I Learned From Our First Startup Accelerator

This is where we realized a very, very important lesson:

Other people's perception of your startup is as (if not more) important than what you are actually doing. We couldn't blame the program organizer for having the wrong perception about our company when they weren't even aware of most of what was happening with our company in the first place.

There was so much cool stuff happening everyday, but the number of things we publicly showed was thin in comparison.

This was problematic and could seriously handicap ourselves in the future. This is when I made the decision to celebrate the wins of the company publicly.

Every release of the product, I would publicly acknowledge my team's work on our social media. If we were passing major sales milestones, I would make a statement out of that. A major advance in the AI research of the company would be public within the week that it happened.

I used to hate posting on social media as it felt like I was bragging, but it was one of the most important change we've made so far. By celebrating our wins publicly, we've increased by a lot the likelihood of good opportunities coming our way. This is now a vital part of the company that we leverage every day.

With our new understanding of how to best promote the company and improve our probability of success, we applied to two other bigger accelerators (Creative Destruction Lab and MaRS) and got accepted!

The Current State of the Company

This last week of February was the best week the company has had, by far. User activity is way up and the amount of people involved in our project hasn't stopped growing. We are also in the final stretch of closing our financing round, which will allow us to accelerate our growth by a large margin.

However, it's not like it's all good and there is nothing to do now. One of the curses of starting to learn about a topic and making improvements in the way you work is realizing how much there is still to improve.

My company-improvement list on Trello never gets any shorter. Every time I finish a book, I have twenty new improvement ideas and every time I talk to a mentor, I have a dozen more. Even when I finish the implementation of one improvement, I have three more that spawn.

It's very comforting, though, to know that all of the work you put to improve yourself and your startup pays off. Also, realizing that you have created a company that can provide for other human beings is amazing.

I've made a lot of efforts to shed our old prototypical startup way of thinking. This means the following:

There Are Unlimited Vacations for All Employees

This basically means that we don't track anyone's time off. The only time I'm talking to an employee regarding vacation is when I feel they don't take enough time off.

There Are No Working Hours.

If an employee wants to work early morning or late evening, I don't really care (because I do too). As long as the objectives are reasonably met, there is nothing worthwhile to track.

There is No Bragging about the Amount of Work Someone Piles Up Allowed.

It doesn't matter. Only objectives matter. If someone is working an unusual amount of hours, we flag that to the human relations department and we initiate a proposal to find more personnel.

We Invest in Our Employees

We invest in them by buying books, courses, conference tickets, certifications or finding them mentors. Learning is a crucial part of the company's culture and it is heavily promoted. It's also very great for me because I can buy all the books I want on Amazon!

In short, I'm trying to build a company which I would have enjoyed working for. This is one of the guiding principles behind the choices I've made along the way and it really created something that I'm proud of.

My Advice to Aspiring SaaS Entrepreneurs

So that's how I ended up becoming the CTO of my company that has 20+ employees, all from doing random hackathons. It's been a wild ride and still is, but I would not trade this for any other job.

I want to conclude this section with a list of advice and tips for tech entrepreneurs (SaaS in particular) that I've learned along the way. I broke it down into subsections for convenience.

General Product Advice

Your Product is Way Less Important Than You Think

The value the customer can get from your product is what matters. If you can deliver the same amount of value to your customer in a simpler way than having a full blown application, do it.

You will learn faster and you will be able to create more value for your customers in return. At some point though, the only way to keep increasing the value you can deliver is to have a good application. At that point you should have a very good idea about what is important to put in it.

Validate the Need for the Product Before Thinking About a Solution

Spending time and effort on an application that your customers don't care about is the biggest waste of time you can have.

Validate with them every step of the way to see whether or not what you are doing is useful. Even at the expense of development time.

The Tech Stack you Choose is Less Important Than you Think

The most important concern is if you have enough knowledge to build something with the tech you choose, and if you can safely hire people to work with it.

Spending time finding the most optimal stack to work with is oftentimes pointless.

Do not Overcomplicate Your Application at First

Start with a good old monolith and gradually refactor it when needed. The monolith architecture will work like a charm for longer than you think!

Put the Minimum Amount of Features in Your App to Generate the Maximum Amount of Values for Your Customers

The fewer features you have, the less maintenance, fewer bugs, and less technical debt you will accumulate. If a feature is not used by your users, kill it and scrub it from your code base.

Talk to Your Customers

Spend as much time as possible with them and really learn from them. The knowledge you will gain will be a major competitive edge and will allow you to always deliver value to them!

At Some Point CI/CD and a Good Suite of Tests is a Lifesaver.

Not having to fiddle around with deployment and not having to worry as much that you introduced a regression in your code is liberating.

It allows you to become more productive and have a better understanding of the whole code base when you have to read test errors.

Monitoring is Super Important and Should be Implemented as Soon as Possible

Being able to know what is being used, what is the state of the application, and if there are potential problems is a must.

Not having monitoring tools is like driving in a forest road at night with your sunglasses on. It's a bit weird and generally not a safe way to get wherever you want to go.

DO NOT OUTSOURCE YOUR CORE COMPETENCY.

This advice is in all caps because I'm yelling it. If the core of your business is making a web app, make sure that you have everything you need in-house to make a web app.

Relying on outsourcing firms that don't have direct access to your customers or your reality is a sure way to mess the whole thing up. It's therefore extra important that you define clearly what is your core competency in order to not outsource it.

Artificial Intelligence Advice

AI is Great, but Delivering Value to Your Customers is Better

If you don't need AI to deliver value to your customers, don't put AI in what you give them. It will slow you down big time. However, if you validated that you indeed need some sort of AI to provide value to your customers, make that a top priority for your company.

Ensure That You are Collecting the Right Data for Your AI

This is especially important if you are working with partnering organizations as they often have no idea what is good data for a given problem. You need to figure out if the data is great for the problem you are tackling before getting more of it.

Start With a Linear Regression and Work Your Way to That Deep Neural Network with Thousands of Layers

Even if you have tasks for which you have enough data to attempt larger models, start with the simple ones. It will allow for rapid feedback on your data and will help you secure some baseline performance that can be used as benchmarks for the larger models.

Iteratively Improve your AI system and Don't Wait Until Everything is Perfect to Launch.

It's fine to label an AI system as Beta and start experimenting at a larger scale with users. This applies to any product you build, but I feel like this is worth mentioning again in the AI context as it is often forgotten.

Company Advice

Join an Incubator

The amount of coaching you will get – even from the judges before being accepted – is very important. They've seen thousands of startup ideas and they will be able to give you some very valuable advice.

Incubators are oftentimes paid by the government for every startup that they get in their program, which means it's a win-win situation for everyone.

Join an Accelerator After Joining an Incubator

This gives you additional resources and allows you to get very good coaching on very specialized parts of your business (like machine learning or financing). It is also a very good way to network!

Setup Your Core Values and Your Vision for Your Company

Having a vision is like a superpower. As soon as someone throws in that blockchain idea for the nth time you can throw it right back by saying that it doesn't fit the vision.

If someone has a rotten attitude you can easily show your core values publicly and correct course. The hiring and firing is much easier when all of this is setup and understood by the whole company.

Document Your Company's Processes as Soon as Possible

You will be surprised by how much processes you have even at an early stage. You will also be surprised by how little everyone is aware of it (including yourself!).

By documenting these processes you will be in very good shape to start improving and refining them to increase everyone productivity.

You Most Likely Don't Need an Office

If you are building a SaaS product, your stuff will most likely live on the cloud and your offerings will be purely software-based. Learn about how to setup a remote work environment efficiently and save on the office cost early on!

Meetings are Less Important Than You Think

Face to face synchronous meetings are not that useful. I've found that most of the time, just having a Google document that says what problem you want to fix in the meeting and distributing it to people you want to meet with is 99% of the job.

You will get a few comments on what to change, 3-4 asynchronous back-and-forth discussions, and voilà! Another problem fixed.

Meetings are Sometimes Necessary

No meetings whatsoever are not possible, though (I'm a hardcore asynchronous guy and even I need to admit that). If after sending that document you have 30 comments and you get to a stalemate kind of situation, it's usually time to ring the meeting bell and address the point of contention synchronously.

Most of the time, it's a matter of miscommunication. Having this synchronous back and forth allows the issue(s) to be resolved more efficiently.

Make Most Stuff in Your Company Public to All Employees

If something that is work related doesn't have to be private to a specific set of people, it should be public. By having the opportunity to jump in someone else's operational discussion, you can provide much needed feedback that will save lots of time.

Also, by having this whole bank of general knowledge available to everyone, you ensure that people are all aware about what is going on in the other departments.

Make Sure that the Private Stuff Stays Private

This goes both for security-related sensitive material and for private employee matters. If an employee tells you something personal, do not break that trust.

Continuously Improve Your Company's Structure

A company is an ever-growing organism. The structure that is best for today won't necessarily be the best in a month's time. It needs to be continuously tweaked and improved in order to maximize the work that the people working on it can output.

Beware of Working with Large Entities Like Cities, Multinationals, or Governments

These are slow and could end up suffocating your company. They will book meetings upon meetings to move the project forward by inches. Even if they pay you a lot, the cycle of learning you can do with them is so long that you will not have improved by much.

Working with smaller entities allows for more direct feedback. And if you can gather enough of them you can have a much more robust business. Resting on a thousand small pillars is more stable than resting on two huge ones.

Employee Advice:

Don't Hire Jerks Just Because of their Technical Skills

It's a big no-no. If you think about it this way, a person will stifle the productivity of everyone by souring the cultural soup.

If people are dreading going to work because of that one person, you will end up with more problems than what this person can fix with their code.

Cultural Fit is not an Option

Clearly check if the person has the technical abilities that you are looking for. However, check just as rigorously if the person as the right personality for your company.

Having someone clash with the company or not upholding one of your core values will do more harm than good.

Team Fit is not an Option

Make the teams an integral part of the hiring process. You will be surprised by how picky the team is and how rigorous they are in the hiring process.

It happened quite often that the person we were interviewing passed the technical interview and the cultural one, but didn't pass the team interview.

The rationale for rejecting a participant from the team was always valid and we couldn't believe we didn't catch it earlier in the process.

Neurodiversity Increases Productivity

You have to resist the urge to hire people that think exactly like you if you want to have a truly productive company.

By having people from different backgrounds, you will increase the chance of finding creative ways out of problems and you will reduce your blind spots by a lot.

Don't Try to Fit a Good Profile in the Company, Find a Good Profile for a Need

Always start by assessing what is your most urgent need and then find the best person to fill that position. By starting the other way, you will bloat your company with people that don't truly create value.

You Will Have to Fire People and it's for the Best

I've had to let a few people in the company go, and every time it was better for all parties. However, do it with respect. If you did all the work to bring someone on your ship, you should do all the work to bring someone out of it.

This means ensuring that this person understands why it's not a fit, that you gave enough warning signs, and making sure that this person has the support they need once they are moving away from the company.

Make Sure That Your Employees are Genuinely Happy

If someone doesn't feel good, talk to them and help them out. Wish them a happy birthday. Say thank you when they do something great. Coach them when they want to grow. Debug them when they make a mistake.

Having happy employees is one of your most valuable currencies as a startup and what makes working in one such a great experience.

Personal Advice:

Make Sure that the Founders or Executives don't Kill Each Other – and the Company

What do you get when you have a toxic startup culture of working insane work hours coupled with financial stress and customer problems? A good recipe for company failure.

Make sure to always reserve at least one hour per week where you don't talk about the company, but just check on each other and try to mend personal issues in the open.

Repeat After me: It's 👏 a 👏 Marathon 👏 not 👏 a 👏 Sprint

Insane working conditions cannot last. It's not if you will burn out, it's when.

If you cannot envision keeping the pace of work you currently have for the rest of your life, change it before it's too late.

I've seen too many startups crumble suddenly because of people thinking they can sustain having no time off forever.

Leave Room for Your Personal Growth

Learn about that one topic that is completely left field for your startup and enjoy it. Go ahead and network with people for your own benefit, it's okay. The more you grow as a person the higher the potential growth for your company.

Leave Room to Just Chill Out

Even if you enjoy working on your startup don't neglect the other aspects of your life.

It's fine to have other friends outside of work and it's fine to just unplug for a while. If you can't do that you have serious issue to fix in your company.

Have Fun

It's genuinely fun to build a company from the ground up. Enjoy the time working on that nasty bug that put the whole EC2 instance down. Enjoy your time calling this one customer that has nothing good to say about what you do.

Enjoy all of the little problems that will pave the way of your company. Because a startup can only do two thing: Die, in which case you will look back at those days with fond memory. Grow, in which case it will start to become something bigger than you and gain a personality of its own!

Useful (SaaS) Entrepreneurship Reading

The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses:

This book is a very simple read and taught me that cycling through hypothesis/learning is way more important than doing the most perfect thing right off the bat.

As a technical person that loves technology, I couldn’t understand why the tech was not at the forefront of every business discussion.

This book, with the clear example of bold tests that were done with real users, showed me exactly why a focus on building a product before understanding what the users will think of the product is a bad idea.

Traction: Get a Grip on Your Business

This book helped me make sense of how to structure our company once it has scaled past the founders. I’m at something like the sixth read cover to cover.

There is a lot of useful information and practical guidelines to use in order to really get a solid structure that make sense for the next growth phase.

It also helped create a sense of calm when thinking about the future because it increases your awareness of what will come in the future.

Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs

I read this book before reading Traction, however there are a lot of similarities between the OKR goal structure and the Rock goal structure from Traction. The basic idea is that you have limited time to work on goals/projects, so work on the most impactful ones and ditch the rest.

The idea of simply not thinking about the low priority objectives really creates a sense of space in your head. Knowing exactly what to focus on and having the liberty to think about how to get there also helped create an ultra-collaborative structure.

I use the OKR system in my personal life too. It really helps me reassure myself that I’m on the right path and allow me to say no to opportunities that pop up throughout year that are not aligned with my objectives.

Peopleware: Productive Projects and Teams

This was a very enjoyable read. It talks about a facet of software engineering that is often not taken into consideration, which is the people factor. I absolutely love the straight to the point organic writing style that the authors use.

Lots of examples are given and there is a significant supplementation of statistics along their argumentation that really help gauge what non conventional changes to implement.

DRIVE: The surprising truth about what motivates us

Drive is very closely related to Peopleware in the subject it addresses. Both of them help in figuring out how to create a work environment that is purposeful and that drive people to give their fullest.

I’ve learned a great deal about how much “carrot and stick” kind of reward/punishment comes into play in the traditional workplace and how it's not the optimal way to increase motivation.

It also allowed me to understand how I can push myself to accomplish my goals in a purposeful manner without having to bribe and trick myself.

Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale

This book is an extensive introduction to DevOps culture and is a good handbook to keep to consult when you're unsure about a certain aspect or situation.

It was the book that introduced me in more depth to that way of thinking and got me to really understand it more than on the surface level. It had some very neat examples of how all of the DevOps concepts tie up in the real world.

However, it’s quite a lengthy book. It is meant to be consulted in a non-linear fashion. I recommend keeping a copy at hand if you manage a technological team to get some ideas about what to do in a given situation.

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

I read the Phoenix Project a while after having read Effective DevOps. Effective DevOps gave me a deeper understanding of the movement, but it’s the Phoenix Project that really made everything “click”.

It’s a novel, but explained in such an organic way that it could have been a biography. I read the whole thing in 2 days over the summer as I was very engaged with the protagonist's struggle with inefficient process and “impossible” goals to meet.

After reading it I felt way more confident that the changes I was making to my organization were the right ones.

If I had one book to give to a non-tech manager to make them understand how to make a tech department fail and how to make it thrive, it would be this one.

Designing Data-Intensive Applications

This book was so densely packed with information gained from working with very difficult problems that you probably need to re-read it from time to time while you also work on difficult problems.

I’ve learned a lot, both in the inner design of the behemoth of the internet and how much these behemoths were built by facing a constant stream of problems.

The sheer amount of tradeoffs, learning, and ambiguity that takes place in systems at huge scale was staggering. It helped me prepare and better react when I hit various problems in my tiny (in comparison) systems I’d been building.

Likewise, this is the kind of book that should be read periodically while building something that is in the process of scaling.

Forge Your Future with Open Source: Build Your Skills. Build Your Network. Build the Future of Technology

This book is one that really helped me better structure our remote company so we could hit our business objectives and help our employees feel productive and happy.

I drew a lot of inspiration from how open source projects were structured and made quite a lot of changes in that sense. It also helped me understand and appreciate a bit more about how open source projects work.

Principles by Ray Dalio

This is an incredible book with an insane amount of tips from a successful entrepreneur in the financial sector.

The amount of useful content in there is staggering and will require multiple reads in order to extract it all. If you are looking for new ideas to make your organization more efficient, better at problem solving, or stimulate growth, it's a must!

Delivering Happiness: A Path to Profits, Passion, and Purpose

A very beautiful book by the late CEO of Zappos. It's a humble book filled with good learning and takeaways by Tony Hsieh in his entrepreneurial journey.

The most important part here is the focus on making sure that the culture was right, as he had two main company successes in his career: One with LinkExchange that had no focus on the culture and another one with Zappos which was heavily invested in it.

The latter is arguably the stronger business.

Reaching Out

If you are interested in learning more about my company, you can check our website. If you have questions feel free to add me on LinkedIn or Twitter to chat :)

I hope this was helpful!

With not even a dollar to my name, it still didn’t feel like rock bottom.

When you tell someone you’re working for a startup, they’ll either think you’re gonna be really rich or crazy broke.

I remember telling my parents and friends about my decision to join Christina’s,

“I really like the company’s mission and they’re growing really fast. If they continue at this speed, I should be coming back with more than enough to start my own business once my stocks are fully vested”.

Yeah, that didn’t happen.

Just like an investor would do their due diligence before investing, so did I before I committed to Christina’s. When the co-founder & CEO, Thu, reached out to me, I had him on hold for almost a month while I investigated. I looked into the company, the mission, the team, and especially, him.

He’s the kind of guy who shares his thoughts earnestly, finds silver linings in his mistakes and failures, takes on random 30-day challenges, writes love letters to a girl he’s never met before, advocates for a culture that empowers people to do what they love, and reads books like Leaders Eat Last and then actually does something about it. Like making sure everyone in the company gets paid first before the leadership team does.

At the same time, he was a starry-eyed visionary that believed in not only changing the world but also how people viewed it. During this time, I had a competing job offer in New York but it was his persistence and vision that got me to pack my bags, say goodbye to my family and friends, and move across the world to Saigon.

What was the vision? To make Vietnam a model for other developing countries. He got me, then and there. He knew I wanted to be a part of something bigger, and he was right.

A part of me knew that working for a startup can either return 10x or nothing at all. The other part of me knew that even if all hell broke loose, I would have been met with a great adventure and even crazier story to tell.

After all, I’m only 26. I’m not supposed to know everything, but after this, I can say I know a hell of a lot more than I did about people, work, and life than I did before. It was a trade-off that I could afford to make at this stage in life.

June 2017

After wrapping up my goodbyes, I moved to Saigon, Vietnam to become Christina’s second product designer. There were less than 100 people working in the company at the time. Everyone knew each other’s name and during our bi-monthly town hall, we had enough time for every new member to strut to the front of the room and introduce themselves.

December 2017

It’s almost Christmas and we’ve received news of a potential big investment. I won’t disclose who or how much the investment would have been due to the Confidentiality Agreement but it was more than enough to get everyone worked up.

January 2018

We saw an increase in positive cash flow and were growing by 3x. From less than 100 members to now over 300, our family was growing bigger. It was now common to not know everyone’s name. Adjustments had to be made to our town hall format since we no longer had time for individual member introductions.

With talks of the big investment underway and months of positive cash flow, the company announced a 20% salary increase company-wide. Our Tết (Vietnamese New Year) bonus was also paid out early and the company could now afford to provide every full-time member with additional benefits & private health insurance. It was the most exciting time of our lives, and the company’s.

August 2018

8 months later and we barely missed the iceberg. Something happened and we struggled through our first month of financial setbacks. The company was unable to pay the team’s salary on time and it was delayed for several weeks.

After all the salaries were disbursed, we were optimistic that it wouldn’t happen again. Certainly, someone would have looked into the issue and fixed it. Besides, if we’d gotten through it once, surely we could get through it again.

January 2019

The next six months flew by with no visible issue and the company continued to grow as we took in more investments while waiting in anticipation of the even bigger investment.

By now, we’d grown 4x with over 450+ team members spanning across 8 locations in Vietnam. More promotions were announced including my promotion to Head of Product. Cutting it close with the Tết bonus this time, talks of slowing down started to surface.

April 2019

3 months later and our death sentence arrived in the form of an investment that never materialized.

With news of the investment falling through, the company was now in fight or flight mode as we scurried to figure out a plan to stay afloat and pay our team in the coming months.

New ideas to save the company sprung up and died out as quickly as they came up. More cost controls and salary delays were announced. Those who were in a position to loan money or part of their salary to the company did so and were promised a 10% interest in return.

July 2019

With the company’s four business lines not generating enough revenue to cover our accrued costs, intense pressure was placed on our technology team to launch our products and generate at least $50,000 USD in monthly revenue within the first 6 months.

It was an unrealistic goal given the state of our products, but I volunteered to head the initiative. Still, no salary had been paid. No salary was reduced and the leadership team was adamant about not laying off anyone.

August 2019

We managed to launch our technology, but not the way we wanted to. We went to market with bootstrap marketing and zero advertising budget.

It was like a plane taking off with no runway. We were hoping that we could get off the ground without crashing and burning. And we did, kind of. Our product showed signs of life and market-fit but we ran out of fuel, and time.

It was also around this time that I sent in my two months’ notice. It was time to look forward.

October 2019, The Final Dance

During my farewell lunch, my CTO, a quiet and incredibly talented engineer, said three words to me that silenced my inner critic and guilt:

“Thanks for everything.”

Looking at him, I knew he meant every word.

I came to Saigon as a wide-eyed and ambitious self-taught product designer looking to gain experience, get my hands dirty and make a name for myself.

In that, I found myself building out an entire product team with our own set of processes and principles that allowed us to redesign our technology and assist the company in scaling operationally. Our team was looked up to by everyone in the company. We were the team that got it together and we wore that badge with pride.

Takeaways

There were many nights where I laid in bed unable to sleep as I played through the events that unfolded while rotating through a cycle of emotions. Guilt. Shame. Embarrassment. Sadness. Repeat.

But not once have I ever felt angry at the company and trust me, there were many, many reasons to be.

I could have been angry at the reckless decisions that were made, the inability to keep our finances in check, or even the lack of communication and unity displayed by the leadership team when everyone was looking to them the most.

Even then, I couldn’t allow myself to invite that anger in. I knew if I did, it would have chewed me up and spit me out into the dark, covered in nothing but self-pity and insecurities.

I did question my calm demeanor those nights and wondered if I’d grown thicker skin over the years or had simply lost my sanity. I mean, where were the tears?

Looking back, I realized that after cycling through all those emotions, I always came back to feeling resolved. Resolved in knowing that I did what I could and gave my best.

In my high school business class, we were taught to have an emergency fund of at least $1,000 to prepare us for unexpected costs and rainy days. Little did I know that it was hardly enough to prepare me for 4 continuous months of unpaid salary.

The question that I continued to turn over and over in my head was how I was supposed to look my parents in the face and tell them that after so many years of working abroad, I was coming home with nothing except credit card debt?

And I don’t know yet, I’m still figuring that out. I’m still figuring out a lot of things. All I know is that it starts with an honest and vulnerable conversation and, no matter how I look at it, I can only feel blessed to be so young and boundless. I can only imagine how much more difficult this would have been if I had other people to take care of besides myself.

For someone who plans to become an entrepreneur themselves one day, the lessons and skills I’ve gained through this experience have been nothing short of invaluable. I’ve worn so many hats and witnessed so many red flags that came with growing a startup.

I’ve toyed with the idea that maybe this was how the captain of the unsinkable Titanic felt before they hit the iceberg, especially after being warned that they were sailing too fast in such icy conditions.

When did we start seeing the ice? Could we have switched course or slowed down enough to dodge the icebergs?

At the same time, I also saw firsthand all the things we did get right. Like scaling a company 4x with a 450+ team that were willing to give up their paychecks and loan money to the company for many consecutive months – all because they believed in the mission and culture we had worked so hard to build. I know I did.

You can start a business overnight, but to build a strong and resilient culture with hundreds of people believing in one collective goal, that took something else.

I can only hope that the experiences I’ve learned will be of use for when I have my own business where I will be faced with making decisions that won’t just affect me, but my team and their loved ones as well.

Edit: Epilogue

The initial draft of this article was written during my one-way flight back to the States. At the time, I had a million questions in my mind and less than a dollar in my checking account.

Several months later, I’ve moved on to land a job at my dream company (Evernote), I've co-founded an exciting new venture (Noted), and even more importantly, engaged my parents in that overdue vulnerable and honest conversation.

I confided in them about my setbacks, the lessons I learned, and how excited I am for the future. My mom cried, my dad beamed with pride as he looked away and asked what I wanted for dinner.

In my initial draft of this article, I concluded by saying there was no happily-ever-after ending to this story. It was never my intent to make this story inspirational either. My only goal was to wrap up this bittersweet journey by sharing my story, and writing was the only way I knew how to do that.

But after having lived it out and arriving at this point of clarity, I can say beyond a doubt:

There wasn’t meant to be a happily-ever-after ending to this story.

It wasn’t meant to be inspirational either.

Yes, I was left with nothing.

But at the same time, I was left with everything: myself, the lessons I’ve learned from this bittersweet adventure, and my dreams.

And to me, that was everything I could possibly need.

Besides, I’ve always been a believer that everything in life happens for a reason… as long as we give it one.

Let that reason be to learn, to grow, and to continue evolving into that person we want to become someday.

And remember,

“Tough times don’t last, tough people do. ”

— Robert Schuller

My partner Kevin and I have been working and talking about different side projects/startups for over 5 years. Two years ago we released our first product to the public, but it was one year ago that we decided to go full time on the indie hacker road. In this post, I’m going to explain our journey, our background and how we did it after many failed attempts.

This post is not about some magic product we launched in 2 days while getting 10k signups and reaching $20k MRR in one month while working 4 hours a week in Hawaï. This post is more about the small wins and loses we had during our first year in the Indie Hacker world, and the things we wish we knew before starting.

This post is about 3 products: one irrigation pivot, one startup pivot, and of course, some MRR.

(Disclaimer: ScrapingBee was initially launched as ScrapingNinja, but due to some copyright issues we had to quickly rebrand it. We'll talk about it in a future blog post.)

Background

It started when we were both employed in different startups as software developers. We had lots of ideas and we loved to build side-projects for fun.

Kevin and I were doing lots of Web Scraping in our jobs. Kevin worked at a Fintech startup called Fiduceo which was acquired by a big French bank, and they were doing bank account aggregation, like Mint.com in the US. He was leading a small team handling the web scraping code and infrastructure.

I worked in the US and then came back to France to work in the biggest French real-estate data provider as a data engineer. Part of my job was to find, gather, extract and load new data sets from the web.

So we both had experience with Web Scraping and data at scale.

Our first project: ShopToList

One of the first “mini-success” we had was Shoptolist.com, a B2C website/browser extension which is a universal wishlist that sends you alerts if it sees any price drop. It was really just a fun side project that was never meant to be more.

It allowed us to try many different things and to discover that acquisition is really, really, really hard. We quickly reached 1k users by just submitting our product on frugal/fashion subreddits. We were very happy about it because it was just an experiment.

Every day we had a script that scraped each product in our database to update its price, and we were sending an email in case of a price drop. The links in the email were affiliate links, so we took a small percentage if the user ended up buying the product.

In theory, this model works great, but in practice here is what happened:

• Out of 1000 emails sent, about 20–30% were opened
• 2% click on the product links that were on sale
• Out of this 2 %, 5–10% buy the product

The percentage we earned was very small, depending on the niche it was 0.5–5%, so this business model only works with millions of users.

And this is where we hit a wall, we did not manage to create sustainable growth. We tested many things, content marketing, affiliation, some paid advertising, but we just did not manage to create growth. And since it was just a little side project that only took us 2 weeks to build, we were ok with that.

For us, this was a very good experience, because this was the first project we really shipped to real users, and we learned a lot.

By digging into the database we noticed that a few users had thousands of products saved inside ShopToList. It seems strange unless they were crazy impulsive buyers, the majority of users had like 20 products saved on average…

So after a little “investigation”, we discovered that these users were E-commerce owners that were “spying” on their competitor…

Our first pivot: PricingBot

We assumed that those people were doing this to receive alerts when their competitor’s products were changing the price. There were many solutions on the web that allowed someone to do this, but ShopToList allowed them to monitor thousands of products for free when other solutions were quite expensive.

We did a small market research and discovered that many tools offered to monitor your competitor’s product, however, all those tools seemed either really difficult to use or really expensive.

Because we felt we could do better, the PricingBot idea was born. I quit my job and we both decided to commit full-time on this. Side project era was over ?.

We made a landing page explaining our value proposition, nothing fancy but something clear and nice enough so people could trust us. We got 60 signups from different E-commerce owners in different niches.

While technically challenging, extracting E-commerce product data was something we knew how to do thanks to ShopToList, so building the MVP was pretty quick.

We launched our beta on ProductHunt on November 2018 and it was a big success, followed by a big crash, the classic startup trough of sorrow.

ProductHunt launch

You had to upload a CSV file with your product catalog, and for each product match it with a competitor product URL.nIt’s ok for several dozens of products, but people had often hundreds or thousands of product in their online store.

So with this feedback, we created some integration with popular E-commerce platforms like Shopify and Woocommerce to let people import their catalog in one click.

Our activation tripled ? , we were very happy about how things were going. One thing to note, though, is that until this moment the product was completely free and we did not ask people for money.

At this point in time here are the few numbers we had that made use happy:

• We managed to have around 200 signups with $0 spent
• 20 users seemed to use the product and had their account fully set up

What could go wrong right?

We decide to close the beta and start asking our user to pay for our software with a classic SaaS model with three plans, $29/$99/$299 per month based on volume.

The first day was magic because literally several seconds after sending the email announcing the end of the beta we got our first customer for a $29 plan ?

We also managed to signup a $299 soon after, but for him, we had to manually set up his account and manually match 1000 products across 10 websites. It was long but we felt it was worth it. We were wrong! Just before renewing he churned telling us PricingBot was very good but not useful enough for him. We were sad and angry, mostly at ourselves, but decided to move forward and continue.

It seemed we were on a good path and that we just needed to go all-in on marketing. And that’s what we did. Content marketing, cold outreach, affiliation, SEO you name it!

But before diving into this, let’s talk again about our activation

Mistake #1: bad metrics leads to bad conclusion, bad conclusion leads to bad decisions (in Yoda’s voice)

When we first decided to monitor our activation rate we assumed that one user was activated when he did two things:

• Add at least one of his product, (or link his store with our built-in integration)
• Add at least one of his competitor’s product

And so, with that definition, we had around 10% of our users that were “activated”. Considering that at that time most of our users were coming from ProductHunt and that hunters are known to easily signup to products they don’t plan to use and just for the sake of it we were happy with these numbers.

But we were wrong.

This definition meant that someone who owns a Shopify store with 4000 products, and who adds only one competitor’s product, was activated. This was silly. Someone who only adds one competitor’s product out of 4000 of is own catalog won’t use PricingBot to do price monitoring and surely won’t pay for it. We learned this the hard way.

Because soon after we had this first paying customer, nobody followed, literally nobody. At first, we did not understand. Then it was obvious: out of 200 signups, we had 20 active users, out of 20 active users we had 1 paying customers, so the only solutions were to have more signups.

This was another mistake.

Mistake #2: Thinking our only problem was acquisition

We thought we only needed more users and just went full marketing. Because we did not know the e-commerce community very well we had some trouble starting. But we eventually managed to write some piece of content that was shared on relevant Facebook/Reddit/LinkedIn group that brought in a few leads.

We also did some paid advertising and cold outreach but it failed miserably.

One month later, we needed to see the obvious: we were not on the right path.

Our leads used the product but did not pay, and even if all the leads we brought in paid, it would have not been sustainable.

At this point in time we finally decide to understand better why users don’t use our product more and with feedback request and lots of analytics insight we discover two things:

• For most of our users, PricingBot was a nice to have, but it was not something worth paying for
• Most of our users didn't want to do the setup because it is too tedious, but they didn't want to pay us to do it for them.

Next thing we knew we revamped our whole onboarding process and try to automate as much as possible. But it was still not working.

When you want, as an e-commerce owner, to monitor your competitors, you first have to link your products with your competitors - and this was the hard part. This part alone meant approximately 1 hour of work per 100 products you want to match. This was way too much time for an e-commerce owner working alone with a 10k products catalog.

Fear, Uncertainty, and Doubt

To help you understand how we felt at that point in time let me just recap the timeline:

• January 2018: ? we launch ShopToList
• July 2018: ? I quit my job and we decide to build PricingBot
• October 2018: ? After a busy summer and 1 month of code we launch the MVP in beta
• January 2019: ? First paying customer
• February-March 2019: Acquisition, product dev

Back in May 2019 we kind of hit a wall. Nothing we did really worked and it was hard staying motivated. The only silver lining was that we managed to rank well on Google so we had, every day, around 3 new signups without any acquisition.

But we still did not manage to make them pay. And we still did not manage to make them configure their account.

This period of time was hard because it was full of negativity. My cofounder and I both knew that we were not moving forward. While this did not degrade our working relationship, it certainly degraded our working productivity.

We both felt that no matter what we did, we were not able to move any meaningful needle that could have boosted our business.

We improved the product a lot, managed to gather some signups along the way but it was not enough. Here is a look at our revenue.

One agricultural pivot to build, one startup pivot to make

Mid-June 2019 things are not looking good, we only have 3 months to launch a successful business. We both agreed in 2018 that we gave ourselves 1 year to launch something that worked, 1 year to reach “ramen profitability” ?.

We had a long talk beginning of June and we both agreed that we needed to step back. We currently had 3 options:

1. Continue with PricingBot hoping that some magic happens and that we cross 4k MRR in 3 months
2. Leaving the company and start going our own way
3. Building something else

Point 1 was hard because we were both fed up with the product. Everything we did seemed useless and it was not working. Point 2 needed to be addressed, but although it was not a success we felt that working together was working really well (in the human side of things). It would be a pity to give up.

But we chose option 3, and we are both very happy with the outcome of that talk and full of energy. We only needed one thing: to choose what we would build.

We also decide to do something we should have done earlier, we sold ShopToList. The whole deal was done in less than 1 month thanks to 1kprojects.com and it brought some welcomed money in our company bank account.

In the same time, my father in law, a farmer in the south of France called because he needed help assembling an irrigation pivot. The heatwave was supposed to be hard in June (and guess what, it was), and it was an urgent job. We both decided that this was a good opportunity to take a break, to think, each on our side, about the future product, and to come back full of ideas and motivation.

It was kind of ironic because this pivot kind of funded our pivot.

Disclaimer: If you ever need to buy an irrigation pivot I strongly suggest that you look into Valley pivot (PS: this post was not sponsored by Valley in any way)

ScrapingBee

Two weeks later, we both found ourselves with a bullet list of product ideas, some good, some bad, some crazy, some boring, some exciting, well, you get the idea. Both lists were diverse. However we quickly agreed on one idea, because it really stood out from the others. Let me explain.

While working on Shoptolist and Pricingbot, and also in our previous work experience, there were three things that we always needed to do for our web scraping infrastructure:

• Transforming websites into a structured API,
• Running headless browsers at scale,
• and managing a pool of proxies.

When you extract data from lots of different websites, you always have to deal with Javascript-heavy websites / Single Page application, and you don’t really have other choices than running headless browsers to render all this Javascript.

Running a headless browser like Chrome is really painful because the same thing happening on your desktop (high memory usage, poorly coded Single page application eating 100% of your CPU) will happen on your servers. So it is not only painful but very expensive to do this on your own when you don’t know what you are doing.

When doing web scraping at scale, you often have to use proxies for different reasons. The website you are visiting with your bot may show different information based on your location - for example, a price in Euro in the Euro-zone and a price in dollars in the US.

Dealing with proxies is painful too. There are lots of shady companies selling bad quality proxies so you either have to run your own proxies or test dozens of proxy companies to make sure your proxy pool is always up.

We used to solve all those problems using APIs that were either not really efficient or crazy expensive. These are problems that we solve multiple times in our projects so we thought about packaging it into an API and leveraging our experience to make all kinds of web scraping APIs.

We decided this time, to make things right and to try to avoid doing the mistakes we made with PricingBot while creating ScrapingBee.

Mistake avoided #1: creating a product you won’t use

One of the biggest problems we had with PricingBot was to find where our potential users gathered online. What group did they follow, what blog did they read, what influencers did they listen to. And the reason was simple, having never worked with or in the e-commerce industry except for some freelancing gigs, the whole landscape was unknown to us.

With ScrapingBee we would be our own users and it changed everything. I know this advice is not new, but often this advice is meant to build a better product. And sure, being one of your own users allows you to build a better product.

But for us, the game-changing fact was that being our own users meant that we knew exactly where to find and how to reach potentials leads.

Kevin and I also have our own blogs running for quite a bit of time and I wrote last year a book dedicated to web scraping in Java. This directly translated into 20k monthly visits that we could leverage to promote ScrapingBee.

And it worked. In about 2 months, we reached 150 beta signup, 4 times the amount of beta testers we had for PricingBot.

Mistake avoided #2: Spending too much money

While building PricingBot, we spent a lot of money on useless infrastructure, APIs and software without reaching Product-Market Fit.

We got to get our money back thanks to ShopToList sale and my agricultural skills before we launched ScrapingBee, but this time, we were way more careful about how we spent it.

I know spending several thousand dollars to bootstrap a project is not a lot of money but we weren’t comfortable with spending more. So we decided to be careful with how we would spend it with ScrapingBee.

We basically reduced our costs by only finding deals (❤ AWS Credits) like Secret which basically give you 6 months free for lots of SaaS or a huge discount.

We decided to do more with what we had, and so far we don’t regret it.

I’ll talk more about products and tools we used in a future blog post, this one is already long enough.

? Launch ? and mistake avoided #3: not asking for money from day one

One thing that did not work well with PricingBot is that for months, we built a product that was free to use. I know this is a classic mistake, but this is not the worst part. The worst part is that we knew it was a mistake. In the last 4 years, we’ve read tons of books, interview, blog posts about startup and everyone seems to agree that the sooner you ask for money the better.

But it was easier said than done and we did not dare ask for money while building PricingBo. We just did not think anyone would pay for an unfinished product.

We did for ScrapingBee. The pricing for ScrapingBee is again a classic three plan SaaS based on API call volume/feature starting at $9 / $29 / $99 per month and an Enterprise plan.

We “soft-launched” first to our mailing list and got our first few small paying customers. Again, we had the same experience with PricingBot but this time it was different. With PricingBot, every paying customer we had was really hard to get, we had sent them tons and tons of email and they took a long time to finally pay.

With ScrapingBee it was different. Our first 2 customers had never talked with us before.

We then started to blog and got tons of leads along with a few more paying customers including a big Enterprise plan as you can see in the MRR chart below.

Then it all went quickly, Kevin and I both having blogged about programming, creating insightful content about Web scraping is not a problem for us, and we knew how and where to promote it.

One particular piece of content we wrote, a web scraping guide completely exceed our expectations.

This post alone meant that in 2 months we had 3 times the traffic we had in one year of PricingBot. This post not only brought traffic but also customers with real $. It also allowed us to signup the first big enterprise plan that allowed us to reach and cross $1000 MRR.

The future

Of course, it’s really early to say if ScrapingBee will be a success or not.

This big enterprise customers thanks to the success of our first blog post could only be an outlier phenomenon that won’t reproduce in the future. Maybe it will. But one thing is certain, things are looking way better with ScrapingBee.

We have lots of engagement from our users and leads, the conversion rate from trial to paying customer being close to 5%.

We also love to talk with our potential customers (❤️ Zoom) and we have the feeling that ScrapingBee is really a must-have for them, instead of a “nice to have”. (small tips: we offer 10 000 free API credits for users that accept to have a small 15 minutes talk with us, this already allowed us to have 50 real conversations with real people about ScrapingBee)

In-app message to incentivize users to schedule a call with us.

In the months to come a big challenge will be to find profitable and scalable acquisition channels. We hope that content marketing will continue to work and that it will improve our SEO to get organic traffic. Writing a good piece of content may not be enough and we really have to discover other acquisition channels.

The other big challenge is to prioritize features in the API-store. Meaning figuring out what users need not blindly implementing what they want, and hopefully, manage to get them to pay before the feature is implemented.

We still don’t know what we want to do with PricingBot, we seriously think about selling it but are a bit afraid of all the paperwork involved (it was much easier with ShopToList because ShopToList did not bring any money in, so no bank account, Stripe account, etc…)

We also still have a lot to learn and a lot to prove before being able to say that we build a sustainable and profitable business but for the first time in our lives, we feel that it can be done, time will tell us if we’re right.

I really hope you liked our little story and that your learned some interesting bits along the way. We plan to do this kind of posts every 3 months at least, please tell me if you'd like to read the next one ;).

Pricing can be the life or death of a bootstrapped startup.

When I started the process of trying to price my startup I became overwhelmed with questions and doubts. Should we have usage-based or a tiered pricing model? How much storage can we offer at each tier? Should we offer a free plan? What should the base price be? What if no one wants to pay for this? What if Tueri is a failure?

I have spent countless hours trying to answer these questions and pricing has been the single most daunting part of launching Tueri. Tueri is a completely bootstrapped startup and ultimately, pricing can be the life or death of it. Investor money is non-existent, meaning the company needs to be profitable at every stage of growth.

It boils down to these two essential questions:

1. Can I provide exceptional value and service to my customers at this price?
2. At this price, can Tueri continue to grow and be on the leading-edge so I can continue to deliver exceptional value and service?

These two questions may seem at odds, but they are essential for building a long-term, customer-centric company.

What is Tueri?

The word Tueri is a Latin word that means: preserve. Tueri is an image management and optimization platform based on the idea of an immutable master image.

Tueri uses just-in-time image transformation, compression and conversion to deliver the perfect image to each one of your users in just milliseconds.

The idea for Tueri came during my work as an application developer. As a developer, I build customer-incentive applications for automotive parts companies. The basic premise for these sites is the more auto parts a customer (mechanic shop) buys, the more points they earn. Customers redeem points online for everything from golf clubs to TVs to vacations.

These websites receive daily file feeds from vendors with new, discontinued, and updated products. There are thousands of products and no standardization on image dimensions, file sizes or image hosting HTTP protocol. I built Tueri to solve these problems.

The first version of Tueri was a simple proxy server designed to fetch remote HTTP images and re-serve them over HTTPS, removing insecure-content warnings on our customer-incentive sites.

The next version was a simple one-page PHP script using GraphicsMagick. This script fetched a remote image, resized the image if it was over a predefined width, stored it on the server and served the image over HTTPS.

These iterations soon progressed in scope and features and somewhere along the way, I realized it was saving me obscene amounts of time.

I needed to share this with other developers.

After a lot of work converting a personal project into something I could host for others, I was ready to launch. The only problem was, I had no idea how to price it.

Should we offer a free plan?

Here are some reasons why a free plan makes sense:

• User Acquisition — Offering a free plan can help you acquire a ton of new users. This, in turn, should drive growth through word of mouth marketing.
• Upselling — A user on the free plan can be upsold to a paid plan.
• Supporting the Community — In my jobs as a developer, I have relied on countless free services and have benefited greatly from the open-source community.

My fear of not offering a free plan was that I would have a very hard time acquiring new users. I struggled with this question what seemed like hundreds of times, so I did some research.

I researched countless other startups. I wanted to know whether they offered a free plan, what features they included, what percentage of users were on it and if they were profitable.

I discovered the following:

• Free users will drive growth through word of mouth, but they will drive more free plan growth.
• A free plan will help you acquire more users, but only a very small percentage of those users will ever convert to a paid plan.
• A huge percentage of support is dedicated to free users.
• A free plan product is often inferior due to costs associated with back-end services.
• This inferior product is the product that people come to know your business by.

The Free Plan Decision

I have decided not to offer a free plan in order to dedicate 100% of our resources to our paying customers. This ensures both the quality of the product and exceptional customer service.

Should we have a usage-based or tiered pricing model?

Usage-Based Pricing

Pros:

• Only pay for what you use.
• Better for companies with seasonal usage fluctuations.
• Better for individual developers where low monthly spend is a priority.

Cons:

• Difficult to understand what your actual monthly bill will be.
• Potentially drastic monthly bill fluctuations.
• Harder for a developer to pitch to their company.
• Customer mentality is focused on limiting usage to keep costs down, thus decreasing the perceived value of the product.

Tiered Pricing

Pros:

• Easy to understand your monthly bill.
• No monthly bill fluctuations.
• A fixed monthly amount is an easy pitch for a developer to make to their company.
• Customer mentality is focused on getting the most value out of their plan, thus increasing the perceived value of the product.

Cons:

• Harder to appeal to all use cases.
• Not as ideal for seasonal use customers.
• Hard to appeal to individual developers with a minimal budget.

I scoured hundreds of pricing pages from different Software as a Service (Saas) companies; some simple, some complex. I continually gravitated toward tiered pricing models based on the fact that they were easier to understand. Many companies with usage-based pricing dedicate an entire page to explaining how to calculate your monthly bill. Even after following the examples I still could not say for certain what they would cost me.

Let's talk about an example of usage-based pricing for Tueri. Let's say its priced per image transformation. You have a simple responsive website with 10 pages and 10 images per page for a total of 100 images. You check Google Analytics for device usage: you have one desktop resolution, one laptop resolution, two tablet resolutions (portrait and landscape) and two mobile resolutions (portrait & landscape). If every image on every page gets viewed ten times by each resolution you have a total of 6,000 transformations.

Easy right? Not exactly.

In reality, you may have 10,000, 50,000, 100,000 or more page views a month. You could have 20+ different resolutions, HiDPI displays, pages with varying levels of views, and new images added regularly.

You can see how this gets complicated.

The Pricing Model Decision

While it was not an easy decision to make, I concluded that tiered pricing was right for Tueri due to its transparency and simplicity.

What should the base price be?

This has to be the single most difficult question to answer, at least it was for me. One that I will continue to ask and re-evaluate throughout the lifetime of Tueri.

I had to assess:

• Are we a premium or a value company?
• What type of users do we want to focus our service on?
• Do we want to serve millions of customers at a low price or thousands of customers at a higher price?
• Can we continue to provide exceptional service to our customers at this price?
• What is the time value we are providing to our customers?
• What is the monetary value we are providing to our customers?
• What does our competition charge, are they profitable, and is their business sustainable?

It boils down to defining priorities:

• I want to provide an exceptional level of service to fewer customers.
• I am in this for the long-haul and our pricing needs to be sustainable.

The Base Price Decision

Pricing should not be static, you should assess it over time based on feedback from customers, the added value from new features, and operating costs.

We are constantly evaluating our pricing and I would love to know your use case and if our pricing works for you.

Conclusion

I finally realized that I was never going to have it all figured out, so I made the best decisions I could with the available information and launched.

There is no definitive answer to pricing your startup, but keep these things in mind and you won't go wrong:

• Exceed your customer's expectations in the service and value you provide.
• Price your business for growth.
• Launch your startup.
• Reevaluate your pricing continually.

Do you have any tips or questions about pricing your startup? Get in touch at dane.stevens@tueri.io.

_Originally published at Tueri.io_

This is a story about building a product, what went wrong, and how it changed my career into Design.

For the past ten years, I’ve built many personal side projects. Some were small daily gigs, but there was one that took awhile to accomplish.

This story is about an iPhone app I was working on back in 2015–2016. The automotive startup should save drivers money on gas, reduce greenhouse gases, and make autonomous vehicles a little smarter.

After many brainstorm and research sessions, I assembled a team of developers to help me build an MVP (Minimum Viable Product). We chose to design the iOS app first due to a better audience fit.

During the mid-stage development, a landing page and social channels were launched. This accumulated the first 1,000 people for the wait list and future beta test.

Although we had some challenges down the road, the project was developing well. Frequent user tests confirmed we were working in the right direction.

Nonetheless, only days before releasing the MVP for a beta test, I decided to put the development on hold.

There were a few reasons why I made that decision, including personal things and funding. I still want to share the design process I went through, what lessons I learned, and how it reflected on my career.

It all started with a Personal Need

A few years ago I bought my first car and became obsessed with driving. The comfort, joy, and freedom overcame the cheapness of public transportation and traffic mess. But there were costs that came with owning a car — parking tickets, insurance, maintenance, and gas.

One thing that bothered me the most was the fuel price fluctuation on a daily basis. It could rise in the morning and drop at night. It could be a 10% difference around the corner, and you would know that right after leaving the pump.

So I started digging the web and found a brilliant ( I thought at that time) solution for my needs — GasBuddy. It’s an app that shows up-to-date fuel prices at the local gas stations. I was on heaven that day imagining saving hundreds per month on gas.

Me on that day

The next several years I spent using GasBuddy, I was thankful for the treasure they’ve built but frustrated with the app’s interface that drove me crazy. A confused interface and limited features are among those things I couldn’t handle any longer.

That’s why, in June 2015, I started my side project. I called it Fuelhunt.

The initial idea was to get GasBuddy’s data and to build a better user experience around it. But they are a large corporation and didn’t want to share any of their data even for a reasonable, startup price.

I tried hard to find another data provider, which turned out to be Waze. But they couldn’t help me either. Besides, the accuracy of their data even today is quite terrible.

Again me the other day

So I thought, well, I can do everything myself. Why not. And the journey of sleepless nights begun.

But first, let’s find out why it all matters.

What’s the deal?

1. People want to pay less for gas

I bet you’ve noticed that gas prices differ from station to station, from one brand to another, or from one area to the other. The reason can be a real estate or brand issue, or any other condition that influences the oil market, like politics or hurricanes.

Many of us don’t consider the price difference as savings. But it can run up to $100–200 of savings per year or more, depending on what, how and where you drive. You may argue — that’s not big money. But you can invest the savings on dining, shopping or even more gas.

The are three main components of any gas station:

• Convenience
  Close to work or home, has a corner store, or other convenience.
• Pricing
  Gas cost, store deals, or other saving.
• Quality
  Fuel or overall service.

If you know places that satisfy you with fuel, price, and location — that’s great. If you do not care and will purchase gas whenever you need it — well, that’s also fine.

Meanwhile, there are lots of people who are not aware of the gem locations, but want to use a convenient spot with lower prices.

However, saving a few bucks might not be the smartest idea. The bad gas is not a myth. The fuel itself can come from the same refinery in a region, but still be different at various retail points.

Some factors may include fuel filters that are not maintained properly, unusual additives, “old gas” on some stations, unfair employees who can mix it with oil or other stuff to make more profit, and so forth. All this may lead to expensive car repairs.

We use Yelp, Google Maps, local magazines and ask our friends for recommendations when looking for the right places to eat. So why don’t we care as much for our cars? A well-treated vehicle can run longer without unexpected maintenance.

2. Climate change is real and we need to be more concerned about it.

This is another area in which I wanted to make an impact.

In 2014 there were over 1.2 billion vehicles in the world, and this number is growing rapidly. They all produce an enormous amount of greenhouse pollution that causes:

• Rising temperatures as greenhouse gases trap more heat.
  Hello global warming!
• Melting of the polar ice caps that can lead to a rise in sea levels.
  Hello destructive flooding!
• Depletion of our ozone layer which causes harmful UV rays to enter the Earth. Hello skin cancer!

The question is — can we do something about it?

Well, we can’t cut the production of new vehicles as there is a growing demand for them. And we can’t recycle the existing cars as they usually get reused in third world countries. Can we switch to electric? Kind of.

Future is coming

Electric cars are the future. They are quiet, quick, and cheap to operate. They are more reliable with fewer parts to break. And most important, they don’t emit carbon dioxide.

But this is the future that many of us cannot afford today. Some cars are too high priced, where others can’t provide a proper value yet.

Everything might change with Tesla’s Model 3 (along with other manufacturers’ entry-level propositions), more extensive government support for EV’s, and other benefits. But we are not quite there yet.

So how can we make an impact on the environment with everything we have today — with all these vehicles with the internal combustion engines heating up the world we live in?

Am I the only one who cares?

The first questions I had were “How many people share the same problem and vision as I do?” and “Are there enough potential users that it’s worth building a product?”

I ran some surveys and talked to friends who also happen to be drivers. I wanted to figure out the needs and wants of a target audience.

Here are some insights:

• The target audience includes most vehicle owners — casual drivers, regular commuters, taxi drivers, truckers.

When choosing a gas station,

• Most critical factors are convenience and lower fuel prices for drivers in the North American market. The fuel quality adds up in some Eastern European countries.
• The brand loyalty program doesn’t seem like a factor at all among respondents in the North American market. It’s a significant factor in the Eastern European market.
• Other things like a convenience store, car wash, and 24 hours operation don’t matter much among all respondents.
• People are willing to share either good or bad experiences at the pump.
  They want to encourage or redirect other drivers to fill up at the particular place if there is one.
• Most drivers don’t track their gas expenses, because it’s time-consuming or they’re not aware of easy tools to do so. The majority are willing to track the costs and mileage in some “automatic” way.
• Almost a half of respondents said they do care about the environment in some way, like garbage sorting and recycling. They’re interested in progressing with the reduction of the carbon footprint.

I also wanted to know what people do while they fill up their cars.
I wanted to know if I can fit a product into this 5-minute activity and make this time more entertaining.

Among some activities were:

• Watching the gas counter
• Staring at the nozzle
• Observing the neighbors
• Looking for new scratches and dents on the car

What options do drivers have today?

Apart from personal awareness of gas stations and word of mouth, there are many players on this field to find a gas pump. In reality, none of the solutions matched the product my target users and myself would enjoy using.

I’ll start with the minor competition first, then move along to the more major.

1. Built-in infotainment systems

Today, even the low-end vehicles come with pre-installed infotainment systems. Drivers can get most of the information they need while driving. They can consume media content, see vehicle’s stats, navigate through the city and more. Unfortunately, this cannot be said about real-time gas prices. There are only a few systems that provide it.

In theory, infotainment systems should be safer than peering at a mobile device while driving. But due to a poor design, most of them are actually very distracting and dangerous. You cannot replace the car’s head unit and you cannot switch the OS. Besides, modern smartphones provide a better navigation experience.

Why do the top automakers ignore the modern tech and UX?

2. Apple Maps

Apple Maps is a first navigation option for millions of users on iPhone. Yet it’s limited in many features and provides only basic information such as contacts and directions.

Apple Maps in 2015 — nothing but basic info.

Also, it doesn’t show gas prices and has a weak map coverage for many areas of the world. These two components are critical for the driver.

3. Google Maps

Google has more experience in building maps than Apple. This is by far the best global cartography mobile app on any platform.

Along with the basic info, it has consumer reviews, user images, street view and they started to pull fuel data from Waze in December 2015!

Found this in Time Machine :)

When you’re building a startup, such an update from a market leader feels like a knockout! But, it only proved to me that this feature is in demand, or at least Google’s engineers think so. Which is, apparently, true.

They kept this feature simple. There was no filtering, user contributions, or other social engagements.

4. Venue discovery apps

The venue discovery apps include Foursquare, Yelp, and Yellow Pages. They provide a variety of details like reviews and deals. Yet the surveyed drivers responded that this is not their go-to solution to find a gas pump.

Foursquare and Yelp. Based on research, drivers don’t use them to find a gas station.

5. Gas station locators

Here is an exciting thing — almost every country has a source to get fuel prices. Certain countries have a single price for the gas because it is government controlled. But in general — it’s all different by brand, place, and time.

I won’t go deep into the analysis here, but in short:

• Some websites are only for desktop use and are not responsive to the mobile world. They also tend to have a terrible UX.
• The vast majority of apps are not global. They may cover one or sometimes two countries for the bigger “local market,” like the United States and Canada.
• Some apps are not informative enough. Additional apps need to be installed to complement the “driver’s experience.”

Fuelzee, TransportApp, Spritradar — apps with no soul.

• There are cases when apps are not localized to other languages and territories. Why do you need another account to download an app?

Frequent travelers aren’t happy.

• In the end, having a bunch of apps for various locations is not a solution.
  They all will have a different UI, multiple accounts, and take storage on the device.

6. Big Oil branded apps

At first, I thought that Top Tier brands can invest a ton of money to develop their own apps and make them great. Nope.

Petro-Canada, Esso and Shell. The Top Tier approach.

Some took an approach of squeezing a mobile website into the app. Others thought that tiny buttons with unreadable text are good options for drivers.

But, most of them contain gas pricing info and it’s very accurate where it’s applied.

7. Waze

Waze, which is owned by Google today, is my favorite navigation tool. It’s a crowdsourcing network of 90 million of drivers worldwide. It shows traffic, road conditions, accidents, and police traps.

Apart from a recent minor redesign, nothing has changed since 2015.

Waze also provides fuel prices for many locations. Unlike its excellent navigation experience, the fuel data is quite inaccurate.

I did a quick investigation to find out why drivers don’t use this feature. The assumptions are:

• The element to find a gas station is hidden deep in the menu and is not intuitive to use.
• Waze displays the label when the fuel price was last updated. It’s good to know. Yet, when you see “updated a few days ago” on any location — it’s almost certainly a signal of weak community contribution. If people don’t contribute enough to make it usable, why one would trust and use it?

8. GasBuddy

Here is a big one — GasBuddy. It was founded in 2000 and currently has 65 million users. It operates in the United States and Canada. It was recently launched in Australia.

When talking about the United States and Canadian markets, their data is quite phenomenal — especially since it’s gathered from a crowdsourcing community and other sources. Yet their app failed on usability and performance.

While conducting research and observing people performing usability tasks, I found out that:

• Many users, who were unfamiliar with the app, couldn’t complete a simple thing such as setting directions to a location. It required seven taps to accomplish that task.

GasBuddy list view 2015/2017. “Improvements” include more buttons, less readable text and colossal ad banners.

• The majority of drivers didn’t use the default list view and immediately switched over to a map view. The problem is that information on the list view is not that clear. It’s hard to understand in which direction the gas station is located. It can be close in distance, but may take longer to drive due to traffic, difficult intersections, U-turns, or a dozen stop signs.
• Overall, the UI is quite confusing and distracting. The information architecture lacks logic in some places. Annoying ads consume cellular data and screen real estate. Elements unreadable from a distance and tiny buttons make it hard to perform a task without giving too much attention to the smartphone.

Users complain about ads, but GasBuddy keeps pushing more of them.

• GasBuddy, as well as many other competitors, state that drivers can save money with their app — and it’s true. But it’s not clear how much the person saves at the pump, as there is no savings indicator.
  The app displays locations with lower prices but doesn’t show the value of using the app over a period of time.
• Users can win $100 of gas daily by exchanging in-app points earned for price submissions into the entries to win. Yet the chances to win are roughly 65 millions to 1.
  Nonetheless, it looks like it works for user engagement and retention.

9. Savings Trackers

There are many apps to gather vehicle’s stats and track various expenses. The majority of them require a significant effort to enter the data, whether it’s a manual operation with dozens of fields or scanning receipts with unreliable text and field recognition. The visual part of these apps is unpleasant and “scary” — as most drivers responded.

A typical UI for an average mileage tracker.

On the other hand, there are solutions for car monitoring, like Automatic. They carry their pros and cons, but the biggest issue with them is that a special adapter is required for their operation, which is an additional investment.

At that point, after the research and user testing sessions I’ve done, the picture was clear — there was a niche on the market and I could fill it with a new product.

Designing Fuelhunt

I wanted to create a product which embraces best practices in usability. At the same time it eliminates the pain points that users have with other apps in this segment.

I didn’t want to create “yet another app to find a gas station.” I wanted a product that will have a more significant impact on our lives in the future.

I’ll skip over the dozens of iterations, sketches, and wireframes right to the final MVP build that was successfully tested with potential users.

Here are some key improvements upon the competition:

1. A single app to cover global fuel prices

I’m talking a post-MVP phase. But the database architecture had to be developed beforehand for an easy expansion.

At first, it didn’t seem like a challenge.

I needed to solve the problem of any social network: no content=no users, no users=no content.

In this case, the content was pump locations with fuel types, current gas prices, and user reviews. To get that content fast, we collected everything we could find on the market and built — as we called it — a dirty database.

Even though there were lots of open data out there, it was all a complete mess. Some sources provided clear API’s, others only had Excel spreadsheets. Then we needed to find a way to pull the data and make it usable.

Another issue was a difference in brand lists and octane levels in various regions. North America and Europe calculate the octane rating in different ways. North America’s 87 is like Europe’s 95, where NA’s 91 is more like E’s 98, and so forth.

To be honest, it took a while to bring everything under one roof.

Finally we had the data, but it was inaccurate. Fortunately, fuel prices are changing so fast, that it actually didn’t matter if the price is a day old or a week old — it was still wrong. So, we were pretty close to Waze and Google Maps accuracy.

2. Clear UI and simple app navigation

It doesn’t matter how unsafe it is to use a smartphone in the car or how high the tickets are for the handheld devices. People still use their phones while driving. They are either holding them or the phone is mounted on the dashboard.

Our job as designers is to build well organized and easy-to-use features and to think through all possible ways of using our product. We have to make sure that ergonomics minimize distraction and don’t harm the end user.

Large text, bigger touch points, clear screen flow, smart notifications, no ads. These are only a few of the criteria I kept in mind.

Speaking of navigation, the Fuelhunt app consists of 4 screens:

• Main screen
  to find gas stations
• Add screen
  to add content
• Activity
  to see user’s and friend’s public activities
• Profile
  to see all user’s activities and stats

3. Super fast pump search

The primary app’s role is to find an optimal gas station and set directions for that station. The flow was optimized to complete this task under 10 seconds.

Main screen

Upon launching the app, it displays the map view with pump locations and — using a combination of distance, user’s moving direction, price, and review score, it preselects the best option to fill up. No intermediate screens or additional taps needed.

The bottom banners contain all info the driver needs at the moment: brand, gas price, an indication how “current” that price is, and the rating emoji.

Instead of showing the distance to the location, the time of driving is provided. Traffic and road conditions may play a bigger role.

The button to get directions is always visible, making it faster to set the route. This decreased GasBuddy’s seven taps to one.

All location pins are color-coded by the time relevancy:

• Green if they were updated today — It’s the most accurate.
• Orange if they were updated yesterday — It’s somewhat relevant.
• Grey if they were estimated — Everything that’s older and everything collected from 3rd party sources.

In case of inaccurate pricing data, this approach is more effective. It focuses the user on data accuracy.

Waze marks locations by a pricing scale, with green for low and red for high. This green-cheap gas station may have the old price and may be more expensive than a red, but has a currently updated price.

Choosing Google Maps as a map provider instead of native Apple Maps adds a better world coverage and one finger zoom. This is quite handy in the car.

Search filters

Filters are a rarely used but useful feature. They are hidden under the search functions. This not only makes the overall UI cleaner, but gives the user the power to create a personalized map, and display the brands and fuel types the user needs.

4. Bad locations avoidance

The research demonstrated that almost no one reads a review upfront when heading to the pump. This is something we do spontaneously. We drive, feel the need, see a gas station and fill up.

Bad station alert

People still keep writing reviews. Many drivers share their negative feedback if something is wrong. In this scenario, the driver won’t know anything beforehand, but he may feel consequences of bad fuel the next day or in a month.

To solve this problem, a notification system was designed to alert the driver if there is a problem at the location.

5. Easy content submission for user contribution

There is a button to make it easy for drivers to make a new submission. They can provide a price update, fill up data or a new review. It’s always visible on the tab bar no matter which screen the user is on.

Submitting fuel prices

It the fuel price was updated, the app asks the driver to enter the fill up data. In the same way, it asks for a price update after the fill up data had been added.

Submitting fill up info

Unlike competitors that only say that users save with their app, Fuelhunt demonstrates right away the amount saved at the pump. After each fill-up, Fuelhunt instantly calculates the price difference between local stations and provides clear value to the user.

Submitting a review

Sometimes it takes a lot of effort for the user to submit a review. I made it simple with a fuel quality and overall experience evaluation along with an optional description.

6. Activity and stats tracker

The Activity screen displays user’s and friends’ public activities, like points earned, money saved and reviews written.

After testing, we debated whether to include this feature in the app. Nonetheless, I wanted to see how the audience would react to it. I also wanted to make Fuelhunt a little more social. So it made it to the MVP build.

Activity and profile screens

The Profile screen contains a user’s content only. The user can see various stats broken down into time periods:

• Money spent on gas and the amount of fuel burnt
• Money saved with its equivalent of mileage saved
• Vehicle’s mileage itself and fuel consumption

Statistics tracker

This tracker can serve many purposes from knowing the state of your car and wallet to easing the calculation of business trips and filling tax forms. But the main idea has been kept for future releases.

7. Gamification mechanics for user engagement and monetization

Gamification is used in many products, but sometimes it’s not done right. Often, it benefits the top users where beginners struggle to get on top, no matter how good they are. Top users usually get more attention, likes, and benefits.

Fuelhunt’s gamification was designed to eliminate the barrier for new users and make everyone equal to compete.

For every price report and written review, the user earns points. Those who are active for a certain number of consequent days earn enough points to redeem premium features for free. Once they become inactive users, they lose that benefit and need to start over.

8. Post-MVP growth

Enough about what’s been done. The app’s roadmap looked pretty interesting at that time with a number of cool features, but I would identify two large milestones:

First, Global expansion — it is a key element to build a big data company. Why is that important?

I had the vision that someday, with such data, self-driving cars would be able to drive from point A to point B and be smart enough to make decisions for themselves.

They could set the most optimal route and take into account traffic, road conditions, fuel level, and where to fill up most efficiently. That is the future.

And second, I started all this to try to decrease the carbon footprint with technologies we have today. Without the need for drivers of extra investments and extra gadgets to install.

To do that, I wanted to extend Fuelhunt’s database with all vehicle models released to date and their city, highway, and combined fuel consumption. Then compare it with real data from my users to determine the driving inefficiency. And if more gas is burnt than it needs to be, update the user with suggestions to improve their driving habits.

The outcome

What went wrong?

1. The team is everything
   It’s vital to have the right partners and team members involved. But it’s also important to have developers as a core team in the same room to being able to iterate and execute fast.
   I ended up building this project with developers overseas, which brought many obstacles to the whole process. Before I realized some team members were not a good fit in the culture, it was too late and the price we had to pay to replace them was too high already.
2. The issue of adding value
   Despite all the research and user validation that showed there is a product and market fit, I still had doubts.
   I spent too much time trying to perfect the experience from day one instead of releasing MVP, getting the feedback, and moving on to iteration.
3. I ran out of cash
   From the beginning, I didn’t want to use crowdfunding or any other investment opportunity to raise funds. I wanted to stick to my own cash to feel more responsibility for the project. Like, if I fail I’ll lose my own money.
   And I did. Would I do something different next time? Definitely yes.
4. Personal issues
   Sometimes that happens, when you need to choose a personal life or a business. I tried to balance both.
   I lost focus on the project and let distractions to get control over me. It was too late when I realized it.

What did I learn?

Startups are considered intense experiences that result in rapid learning. I gained a lot of experience designing Fuelhunt, filling more roles than I could possibly fill as a full-time employee.

The exciting part was getting the knowledge that helped me roll into a Product Design career from my previous Marketing background. This is an experience that I can look back on to build something more meaningful.

Closing a startup is often seen as a bad and sad thing. For me, it’s only a chapter before the next adventure.

I’m currently open for career opportunities in Toronto to contribute as a UX/Product Designer. Feel free to contact me.