Have a burning desire to become a founder and a great idea for a software company? If you’re like me, building and leading a software or SaaS company has always been the ultimate dream.

It was always something that seemed to have a great ring to it—a low-overhead business (no tangible cost of goods), a recurring revenue model that would bring in monthly subscriptions every single month, and, of course, there was the added draw of a big possible exit. It’s typically in software where you see some huge revenue multiples when companies sell. That’s pretty dang attractive, right?

Maybe you’ve looked at the covers of the Forbes and Fast Company magazines, seen the software legends and listened to interviews with amazing startup founders who seemed to build something out of nothing. I sure did. It’s incredible, and some of these guys aren’t so different from you and I.

“Anyone can create software,” I thought, “with a little learning curve.”

And so, like many entrepreneurs before me, I ventured into the process of creating a software company, both naive and optimistic about the future. Of course, we all know it’s a much more complicated story than it seems. Well, here’s mine, complete with everything I learned along the way.

Are You Starting a Software Company?

I want to make it clear up from that this isn’t one of those warning posts to scare anyone off, but merely a compilation of the hard-fought battles and lessons I learned as a first-time founder starting a software company.

But I can give you one big piece of advice up front that might save you some time: You’ll need to develop a “why,” and a passion outside of just making money. Not having one is typically one of the fastest ways to fail. You’ll simply hit too many roadblocks to continue and eventually just quit.

If you do have the idea and the passion, however, learn from these lessons and let nothing stand in your way.

Previous to Demio.com, I had created and launched multiple smaller softwares that taught me a few important lessons. I’ll talk about those in the post below, but the lessons I learned as an actual SaaS founder magnified those mistakes. The size of the project, the effect it has on our customers’ businesses, and the overall investment were about 10 times anything I had ever worked on, and with that, so were the problems.

You may still have to learn these lessons as you learn how to start a software company, but at least take note of them here, as it may save your sanity and your company when the time comes to launch your own software company.

Lesson 1: Creating Software is a Long Game (5-7 years), So Be All In

There will always be the outlier stories of companies created to sell that turned around and sold for a 10x return. These are the exception and not the rule. In fact, we should probably consider these negative stories in our community. They create the mentality of short-term thinking, creating hyper growth for growth’s sake, and inflated valuations for funding and acquisitions.

Many of our early missteps can be traced back to an anxiety-driven rush to build a software product, to on board bajillions of customers, to design new ideas for building a “fun” office, and hiring boatloads of new employees, all of which we wanted done yesterday. We acted like there was a rush to get to these goals and that once we got “there,” the real work would begin.

The problem with this is that it’s typically the early days that set the real foundation for your company—culture, architecture, marketing, and features. By having a short-term mindset, you set yourself up to fail early. You limit the possibilities of what it takes to actually learn about your marketplace, the people you serve in it, and the lasting impact you want to make.

Critical strategic thinking, early on, for the long term, will be essential for you as a first-time software startup founder. But because this requires some work, you may be tempted to skip this step and jump forward past validation, past the MVP, past the failures, past the slow ramp of SaaS death, past that cold, cold winter, and jump right to the sustainability and scale phases.

Please don’t skip these important steps, though. The reward for your efforts will come and it will be worth it if you’re patient and focused.

 

As founders, here’s a mindset lesson you will be tested on continually: Staying macro-patient, but micro-focused.

This is especially true during development. You’ll have moments where things just take time to bring to light. These moments test your patience and challenge your sanity. Look around for other things you can do during this time, including getting on the phone with your prospective customers and learning about them. Not just if the software idea will work for them, but really learning about their pain, issues, and how you can solve them.

Remember, no one wants more software. They just want better solutions to their problems.

In the meantime, keep your attention focused on structured work segments. The fastest way to fail in your software startup is through burnout. This is definitely a marathon, not a sprint. Balance your life with time for physical fitness, eating well, maintaining relationships with your loved ones, leisure time for your mind, and giving yourself time away from the business. I’m not saying slack off. I’m talking about staying focused on a specific work period and doing deep, dedicated work during those periods. When you are off, keep your focus there (it’s going to be hard. Trust me, you’ll always want to think about business). Clarity will come when you get some distance from the internals (ya know, the whole “forest from the trees” analogy).

Both me and my co-founder have faced bouts of burnout (it sucks) from this type of short-term stress, and each one has cost us hundreds of thousands of dollars in mistakes. Even worse, they lost us valuable time in our business and our lives.

 

Lesson 2: Validate Early, Often, and Quickly

Now that we’ve established the mindset for starting a software company, we’ll need to go into your actual software project. Let’s take a look at some of the other tangible lessons we learned.

Know Your Market

When you develop your idea for a software product or SaaS, you’re basically creating a hypothesis of what the market wants. You’ll first want to make sure you know that market enough to even have a product that solves a pain point.

Your first step is to learn your customer avatar and your marketplace. Who are they? When do they have the pain you are solving? Why are they having this pain? Are there other solutions that solve this? What does it cost them (in time, money, hassle, or resources)? Are there specific segments (like B2B companies, companies over five employees, etc.).

 

Spend time navigating Facebook groups, forums, networking groups, reaching out to companies, and, one of my personal favorites, researching info from marketing/advertising teams that work for magazines and other resources already in the space.

A great example would be, if your niche is 35-to-44-year-old golfers who are looking for a tool to increase their drive, target Golf.com or Golf Digest and review their marketing/advertising links on the site footer to get access to their Media Kits (Kits designed to give statistics on the niche so you know if advertising there is good). You can also look at tools like Similar Web or Facebook Audience for insights.

Your goal when starting a software company is to educate yourself on your target market. If your product is being based on a pain you already feel, I encourage you to still do the research. You may already know some of these answers, but don’t make the mistake of thinking that everyone has the same problem just because you do. There’s often products or strategies you don’t know of yet.

Your goal through this process is to validate whether your hypothesis has any actual marketplace need. If nothing is proven during this time, great. You just saved yourself a boatload of time and energy on a project that probably would have been insanely hard to build and market.

The Next Phase

If you pass this phase, you’re going to want to move to validate the idea as a “Minimal Viable Product.” Basically asking the question, “Will people actually buy this thing?” I will discuss how to build a minimum viable product in the next section.

It’s one thing to create software that solves a problem, but a whole other thing to offer a product that people will actually pay for. Marketing will position your product so people will want to buy it, but a product that doesn’t solve a pain point that makes it worth a financial investment will sink you fast. That’s an uphill battle you don’t want to fight.

Again, here’s a great time to get in touch with your target market. You can combine this question in the research phase, if you already have enough validation that there’s a need in the market. You can start to ask not only what they would pay to have this solution implemented in their business, but also if they would pay monthly or annually and how much they would cough up.

You’re basically allowing your marketplace to confirm and dictate what the value of your product will be, which is a huge help in pricing. If you are building a product in a space that already has competitors, you can price validate in the market, but it’s a bit harder being new in a space. This is a great way to find a starting point.

Validate Your Idea With a Minimal Viable Product

Whew! We’ve now validated that the product has a market that needs it and that people are willing to pay for it. Awesome, that means we have some legs to stand on and our hypothesis is so far correct. And if not, that’s awesome, too! You just saved yourself from creating a failed product.

 

Validation has been all positive so far in this scenario. But I can tell you that we learned the hard way, you can run into a lot of problems by not validating thoroughly enough in the marketplace. We thought our own pain in the market was proof that people needed a product. We learned a lot more once we started marketing, which was a real eye-opener.

Once you have validated that your product has a need and people are willing to pay for it, it’s time to start building your MVP, or Minimal Viable Product (this is the very base level product or system you can create to bring your product to early adopters).

If you haven’t realized already, the point of validation when starting a software company is to save you time, money, and energy (read Chad Boyda’s story on his startups that failed because he didn’t validate). Nothing will drain those things faster than creating software that isn’t validated by customers. To learn quickly and validate quickly (mitigating financial risk), we first create a lightweight version of our software.

Often, you can even create an MVP without a single line of code by just selling your MVP and fulfilling the product or service in a manual way behind the scenes. For example, imagine software that takes a video and converts it to optimized slides with a custom theme. You can sell the basic premise of this (video to slides) by simply doing it manually for the first few customers. It might be a tedious process, but is there a better way to validate that a product is going to solve a need, people will pay for it, and that you’ve got customers out there than actually making sales?

The hardest part of this is understanding what needs to be in your MVP. This actually hit us hard for about the first year of Demio. We felt that every feature, ability, and idea had to be in our first version. Our mockups covered our entire office wall (why we had such a huge office with two people is another story all together lol) and looked like a team of 50 engineers was deep in the project.

 

That cost us. Big time.

When we recognized that our MVP was a simple version of a platform that was reliable in streaming, allowed attendees to connect to webinars, allowed for mic/webcam/screensharing, and some lightweight marketing automation, we were able to move much faster.

What is your MVP? Write it out.

Then go through it again and start removing things.

Try to focus on the basic hypothesis or solution you are creating.

That’s what you start with. That’s the MVP you want to launch with. Remember, this whole validation stage is about proving you have a product that people want, need, and will pay for. What’s the point of a bunch of shiny features when the core isn’t even proven?

Lesson 3: Learn from the Market and Pivot Fast

Now your MVP is ready to go. This is a huge step in your journey, when the magic happens. At this point, you have some early stage validation, but you haven’t really produced much more than the bare bones.

And this is perfect.

Now is the time to start talking to and learning from your first users. And the question you’re probably going to ask is, “How do I get those users?” This post isn’t meant to go too deep in the marketing strategies you can run for your business, but we used three main approaches:

1. We created early market buzz by creating video advertisements of the product (that we hadn’t built yet) and talked about the pain we were solving that we had validated with our user base. We ran those video ads on Facebook to target audiences of our customer demographic and used Cost Per Video View ads. We linked to a landing page website with some of our marketing lingo and an opt-in to learn more about the product.

 

2. We opened a free beta period to the list of people who opted in, which had grown to 1,600+ people. From that email list, we brought in users to what had become our MVP (again, our first version of Demio was a huge behemoth of a software and we had to cut it down significantly when we recognized our mistakes). When users came in, we invited them to fill out a questionnaire that saved the data into Intercom.

We asked about each user’s company type, company size, webinar types they were going to run, and webinar size. This gave us some good early customer data.

 

3. At this point, we had beta, and customers were starting to actually use the product. On all the “thank you” pages, post-webinar pages, and emails, we added text about the beta being free and linking people to a page where they, too, could sign up for a free account. This was a great little viral growth strategy that started to expand our beta customer list.

But the real key win here is that we added an automated message on every account when users joined, and invited them each to take part in a one-on-one demo with a founder via Calendly.

This is where we were able to learn about their companies, usage, and experiences with Demio. We could find out what we could do to help provide a better experience or product items they wanted to see.

 

Once we had these demos going, we were able to actually get real feedback on what real users would like to see in the software. That’s the advantage with the lean MVP software: you can build and add what people actually want, not just what you are “guessing” people want to use. This helps you avoid feature clutter.

To keep track of everything going on with these conversations, we set up a Trello board with feature requests from customers, different product ideas, and development ideas:

 

As each request came in, we added an Intercom ticket to the board, or noted their name from a demo so we could keep track of how many people were requesting that specific feature. We were also able to follow up directly with them after the update went live:

 

When starting a software company, the goal for you is not to build everything.

Build what will move you forward fastest with the right customer (your desired customer avatar). Only make an addition once you’ve seen enough desire that you can be sure it isn’t a situational problem for one customer, but something that will truly add value to the software.

If you get into this stage and you also find that some of your MVP isn’t resonating that well with your users, this is the time to pivot or change the direction of the software.

Is there another problem that you can solve easily with a similar platform? Is there a different way that people could use the software to get the desired results?

Then it’s time to pivot over and make a quick change of your market plan. It should be easy with that lightweight MVP, right? 

Lesson 4: Hire Slow, Fire Fast

We faced a lot of roadblocks on our journey to build Demio, and learned a ton as a result. Lessons that I, for one, will never, ever forget. But one of the most valuable is related to bringing on the right team.

As two non-technical co-founders, we really had our work cut out for us to build such a complex platform. We hired an agency to start, which turned around and screwed us, basically burning over six figures and six months.

We rushed to catch up on the progress we felt like we had lost during those six months, and quickly hired eight people, which blew up our monthly budget along with adding the fun of managing eight contractors who we hadn’t truly vetted enough to see if they would be a cultural and technical fit for the team.

We were all over the place, but at least making progress.

Until we realized the product wasn’t going to cut it. We were using an outdated streaming technology, had a disorganized code base, and totally lacked the simplicity we were going for. It was frustrating.

We had already reached $2,200 in monthly recurring revenue from our first Beta version, but realized that we would have to change things or die. Slowly, over time, but truly die.

So we cut off our revenue and refunded everyone. It was in those moments that we were able to clearly see where the problem was.

 

We hired too fast. We didn’t take the time to organize the development, have a technical lead to guide us through the process, or get the right people to work together seamlessly and achieve a common goal.

If we could go back to day one of starting our software company, both Wyatt and I would agree that our first step would be hiring a technical co-founder or technical lead to take us through the process. Then, slowly, we’d begin hiring talented people around that leader.

No rushing. No quick hires because we felt we needed them. We would be strategic and smart, even if it took longer.

I offer you that same advice. Even if it takes longer, always hire someone who will be driven by your mission, believes in your values, has experience in your technology, and actively wants to grow with the company.

You’ll still make some mistakes. So make sure you learn to recognize when people are not going to fit and be quick to let them go. Again, I didn’t say replace them, because it may take some time to find other A-players who are a good match.

As a fully remote company, we’ve had a great deal of success finding talented engineers at WeWorkRemotely.com, Linkedin Recruiter, and Upwork.

We’ve really been lucky to find some amazing talent who have helped bring our vision into reality. But you’ll first want to make sure your company has laid the groundwork for attracting talent by:

1. Setting up a solid Strategic Identity Document that outlines your company values and what the company goal is (here’s an example of how to start this process)
2. Creating clarity on exactly what that position would do on a daily, weekly, and monthly basis and is responsible for
3. Crafting a compelling job post that articulates the mission of the company, your big goals, what their skills needs to be, and their day-to-day
4. Having a filtering device in the job application to make sure you only engage with candidates who are actively reading your post
5. Run two to three interviews with the candidate, only moving qualified people into the next interview. If you have a technical founder on board, bring them and other engineers on the calls to help interview. You can also have them submit a technical test or test job.
6. Create a scaling job position that grows as they help the company succeed. This can be done in terms of bonuses, raises, vesting equity, or even some type of position growth. Great people want to grow and advance, so make sure you give them that ability

 

Lesson 5: Aim for Progress, Not Hyper-Growth

This advice may contradict what others say, but in our case, we wanted to really focus on the progress of our product, our market fit, and how smooth our company was running, rather than just profit.

Because we were bootstrapped, we didn’t have any outside pressure to grow. We could focus on profitability. We could focus on our users. We could focus on our product.

This approach is not to be confused with complacency in marketing; obviously we placed a priority on increasing monthly revenue and adding users. But we wanted to reject growing fast for growth’s sake, as if it were some rite of passage or ego boost.

Don’t get sucked into exerting all your effort into early stage hyper-growth if you are putting the company, product, or team at risk of going out of business. You’ll be surprised at what profitability can do for you in the long term. It gives you flexibility in your decision-making, and allows you to make mistakes.

When starting a software company, particularly a SaaS, you will experience what Gail Goodman, CEO of Constant Contact, describes as the long, slow ramp of death, or the “cold, cold winter” (watch Gail’s full TedX presentation here). The goal of a SaaS is to create powerful, recurring payments that come in every month, which are then offset by customers leaving (churn) and new customers coming in (new revenue).

The problem is that as you grow, you’ll start to incur new costs like server expansion or new engineers to help offset bugs and new development. Or, as you grow your MVP and onboard new customers, you’ll need customer support and marketing help.

Expenses begin to increase as revenues grow, and you will constantly fight your Zero Cash Date (the day any saved/stored revenue in the bank dries up) against the new revenue coming in and any cash you have. It looks exactly like Gail said, a long, slow ramp of death.

The reason you don’t want to go into hyper-growth until you’ve made it through this process is because this is actually a crucial learning time.

Understanding your customer, knowing your market, making sure your product provides real value, learning average revenue per user (ARPU), customer acquisition costs (CAC), and churn numbers is key.

Churn is actually your real enemy here. This is the number of users or revenue you lose each month divided by the number of new users or amount of new revenue. Here’s an example of how churn can lead you to your demise:

Say you bring on 10 new users a month at $10 month, and two leave each month. You would have a 20% revenue churn ($20 from $100 new revenue) in your first month, and 20% user churn.

In your second month, you’d have 18 users with $180 in revenue. If you lost two users again, you would have 11% revenue churn and 11% user churn. That means in your first month, you would have about five months until all your customers are gone (roughly).

First month – 20% User Churn = 1/5 of your customers are gone.

These numbers fluctuate based on your plan costs and user churn from those plans.

Many hyper-growth companies can flaunt high acquisition numbers, but they churn huge numbers of users since they haven’t adequately addressed the onboarding process or why people are leaving. So they chuck more cash at the problem and spin their wheels until acquisition or merger or a new funding opportunity comes along.

This time should be used to patch these problems up and advance your product so it has a longer-term impact on the marketplace that isn’t based on vanity metrics. Even cooler than fast growth is the amount of time you can survive as a company!

Churn is always an enemy and one we consistently are trying to solve. We’re also still in our own cold winter, but it’s a great opportunity for us to learn, grow, and make a better product.

This will be the hardest time and, again, that long-term mindset will be crucial here.

Don’t give up.

 

So Now What?

I know this was a lot to think about if you’re looking to create software. But it’s full of lessons I wish I had known prior to getting started. Not to stop me from getting started, but to educate me on what to expect moving forward.

And I hope I could do the same for you.

Remember: Keep your mindset focused on your long-term goals, but also zoned in on the day-to-day. Focus on validation early, moving quickly, listening to users, and learning from real metrics.

And finally, make sure you build a strong culture that can be the foundation for hiring great people. They are, in the end, what truly makes or breaks your company.

5 Lessons I Wish I Had Known About Before Starting A Software Company was originally published on Foundr.