Creating a successful software as a service (SaaS) product is the dream for many entrepreneurial-minded programmers. In the process of launching my own SaaS I discovered that sharing and comparing experiences with other founders is an essential part of this journey, and without this, I probably would never have created it at all.

对于许多具有创业精神的程序员来说，创建成功的软件即服务(SaaS)产品是梦想。 在启动自己的SaaS的过程中，我发现与其他创始人共享和比较经验是此旅程的重要组成部分，如果没有这一点，我可能根本不会创建它。

In this article, I’ll share the mental and practical processes that led me to create a SaaS product from scratch, and how I gained my first paying customers. Whether you are thinking about creating a new product or you have already launched, this article can help you compare your own strategies and methods with the ones that worked for me, and possibly adapt them for yourself.

在本文中，我将分享促使我从头开始创建SaaS产品的思维和实践过程，以及如何获得第一批付费客户。 无论您是考虑创建新产品还是已经发布，本文都可以帮助您将自己的策略和方法与对我有用的策略和方法进行比较，并可能针对自己进行调整。

I personally dedicate up to five hours per week researching the experiences of other founders. I’m always looking for new ideas, ways to avoid mistakes, and evaluating new strategies that could help me to obtain concrete results (that is, improve the product and increase customers’ happiness).

我个人每周最多花费五个小时来研究其他创始人的经验。 我一直在寻找新的想法，避免错误的方法，并评估可以帮助我获得具体成果(即改进产品并增加客户满意度)的新策略。

For this reason, I decided to work in a completely frank and transparent way and share everything about my path — including what has been working and what has not — with the aim of helping one another through direct and rational discussion.

出于这个原因，我决定以一种完全坦率和透明的方式工作，并分享我的发展道路上的一切内容，包括正在行之有效的内容和没有行之有效的一切，目的是通过直接和理性的讨论互相帮助。

文章组织 (Article Organisation)

The article is divided into seven chronological sections, following every phase of the work I have done:

在我完成工作的每个阶段之后，本文按时间顺序分为七个部分：

• Detecting the problem

  检测问题

• Quantifying the problem

  量化问题

• Evaluating competitors and their approach to the problem

  评估竞争对手及其解决方法

• Developing the first prototype

  开发第一个原型

• Throwing everything away and starting again

  扔掉一切然后重新开始

• Getting the first subscription

  获得第一个订阅

• How to move forward

  如何前进

The SaaS product I built is Inspector, a real-time monitoring tool that helps software developers to avoid losing customers and money due to technical problems in their applications.

我构建的SaaS产品是Inspector ，这是一种实时监视工具，可帮助软件开发人员避免由于其应用程序中的技术问题而流失客户和金钱。

检测问题 (Detecting the problem)

Spending the last 10 years working with software development teams made me realize how complicated it is for developers to handle technical problems that affect applications every day. Development teams have close relationships with their customers, and this is a high risk for companies that produce software because with problems you realize how fragile this bond really is.

在过去的10年中，与软件开发团队一起工作使我意识到开发人员每天处理影响应用程序的技术问题有多么复杂。 开发团队与客户之间有着密切的关系，这对于生产软件的公司来说是很高的风险，因为遇到问题后，您就会意识到这种联系的脆弱性。

Users do not like problems! It seems obvious, but this aspect is constantly underestimated. This is an uncomfortable truth. No one likes to be in trouble, and it is instinctive to minimize the problem. But by denying this reality you could annoy the customer even more, to the point where they may even reconsider whether or not they “should” even pay you.

用户不喜欢问题！ 似乎很明显，但是这一方面经常被低估。 这是一个令人不安的事实。 没有人喜欢遇到麻烦，将问题最小化是本能。 但是，通过否认这种现实，您可能会更让客户烦恼，以至于他们甚至可能重新考虑他们是否“应该”向您付款。

Customers do not spend their time reporting problems and application errors. No one cares about helping us resolve bugs. They just leave our application, and it may be years before we see them again. Despite this, every team I have worked with used the best-known method of figuring out whether applications were working properly or not:

客户不会花时间报告问题和应用程序错误。 没有人关心帮助我们解决错误。 他们只是离开了我们的应用程序，可能要过好几年我们才能再次看到它们。 尽管如此，与我合作的每个团队都使用最著名的方法来确定应用程序是否正常运行：

“If an angry customers calls you, the software is not working.”

“如果生气的客户打电话给您，则该软件无法正常工作。”

It is not exactly a technological solution…

这不完全是一种技术解决方案……

Maybe it seems ridiculous, but beyond the perception tycoons of technology project on our jobs, insiders know that urgency, limited budget, pressing customers, managers, forcing developers to constantly work under pressure, and adopting Band-Aid solutions (to temporarily fix a problem), are survival strategies. Working this approach for 10 years helped me realize there is clearly a problem here.

也许这看起来很荒谬，但除了对我们的工作进行技术项目的认知大亨以外，内部人士还知道紧迫性，有限的预算，紧迫的客户，管理人员，迫使开发人员在压力下不断工作，并采用创可贴解决方案(以临时解决问题) )，是生存策略。 使用这种方法10年使我意识到这里显然存在问题。

量化问题 (Quantifying the problem)

At the beginning of 2019, I had just finished some important projects and was expecting to enjoy a little period of calmness. During the last few years, I have used such moments to look for business opportunities which allow me to put my technical skills to good use with the hope of finding the right conditions to launch my own business idea.

在2019年初，我刚刚完成了一些重要的项目，并希望能享受一点平静。 在过去的几年中，我利用这些机会寻找商机，这使我能够充分利用自己的技术技能，并希望找到合适的条件来发动自己的商业想法。

I knew from my experience as a developer that an easy and immediate monitoring instrument would be enough to help development teams to stay up-to-date about the performance of applications, instead of relying on customer calls to know when the software was creating problems. On the other hand, I did not need a tool to monitor everything, as everything often means nothing. And I didn’t want it to be complicated — I did not want to spend a month learning how it worked or need to hire expert engineers just for this job. My life had to be made easier than before. It was necessary to have a ready-to-go developer tool.

从我作为开发人员的经验中我知道，简单而即时的监视工具足以帮助开发团队保持有关应用程序性能的最新信息，而不必依靠客户的电话来了解软件何时会产生问题。 另一方面，我不需要监视所有内容的工具，因为所有内容通常都毫无意义。 而且我不希望它变得复杂-我不想花一个月的时间来学习它的工作方式，或者不想为此工作而聘请专家工程师。 我的生活必须比以前更轻松。 必须有一个随时可用的开发人员工具。

The first step was to understand if there already were solutions trying to solve this problem, so I googled “application monitoring” and 941,000,000 results appeared:

第一步是了解是否已经有解决此问题的解决方案，因此我在“ 应用程序监视 ”中进行了搜索，结果出现了941,000,000个结果：

Wow. That’s a very huge amount of content for a problem that probably is huge. But how huge, exactly?

哇。 对于一个可能很大的问题，这是非常大量的内容。 但是到底有多大？

Software development team inefficiency is a problem I have always faced directly, but there is a big difference between estimating a job task and quantifying the economic impact of a problem. It is even more difficult on a large scale. This tweet captured my attention:

软件开发团队效率低下是我一直直接面临的问题，但是估计工作任务与量化问题的经济影响之间存在很大差异。 在大规模上甚至更加困难。 此推文吸引了我的注意：

50% of developers admit to spending up to 50% of their time verifying that applications are working.

50％的开发人员承认花费多达50％的时间来验证应用程序是否正常运行。

Software development is work mostly paid by the time technicians spend working on a project, and if there are periods in which developers spend 50 percent of their time checking that everything is okay, a tool whichcompletely automates this job could be useful enough to buy.

软件开发工作主要是由技术人员花费在项目上的时间来支付的，并且如果在某些时期内开发人员花费50％的时间检查一切正常，那么一种可以完全自动化这项工作的工具可能会足够有用。

So why aren’t they so common to so many developers?

那么为什么它们对这么多开发人员不那么普遍？

评估竞争对手及其解决方法 (Evaluating competitors and their approach to the problem)

I thought about the two main parameters a company looks at when it has to decide which tools to use to increase productivity:

我考虑了公司在决定必须使用哪些工具来提高生产率时要考虑的两个主要参数：

1. Simplicity (ease of installation and use)

   简单 (易于安装和使用)

2. Efficacy (I spend x to solve a problem which is worth x+10, so I gain the +10)

   功效 (我花x来解决值得x + 10的问题，所以我获得+10)

Using these parameters, I spent about a week creating an evaluation sheet of the most well-known monitoring instruments and I placed them in a graphic:

使用这些参数，我花了大约一周的时间创建了最著名的监测工具的评估表，并将它们放置在图形中：

After days of putting information together, a look at the graphic was enough to realize where the problem was. Easy instruments do not provide enough value to the majority of developers. More complete instruments, instead, are thought of as being for big organizations and requiring skilled staff who dedicate themselves to their installation, configuration, and use, which ends up complicating team operations rather than simplifying them.

经过数天的整理后，查看图形足以识别问题出在哪里。 简单的工具无法为大多数开发人员提供足够的价值。 相反，更完整的工具被认为是针对大型组织的，需要熟练的人员致力于其安装，配置和使用，这最终使团队的操作复杂而不是简化它们。

In my vision, the problem is not the monitoring itself but the development of team efficiency.

在我看来，问题不是监控本身，而是团队效率的发展。

For a massive adoption, it would be necessary to have a product that requires a minute for the installation, no configurations, and, at the same time, that provides complete and easy information to consult that would allow even medium-sized development teams to fix the real-time monitoring problem.

对于大规模采用而言，必须有一种产品，该产品需要一分钟的安装时间，无需任何配置，同时还需要提供完整，容易的信息以供参考，甚至允许中型开发团队进行修复。实时监控问题。

And of course, it has to be cool.

当然，它必须很酷。

开发第一个原型 (Developing the first prototype)

Finally, I decided to try it. The last work experience had gone well and I thought that it would not be impossible for me to create this tool. So, I immediately informed my partners that I wanted to build an MVP for the following two or three months. When I explained it to them, it was hard to make them understand the problem because they are not technicians involved at the same level I am. They gave me the okay based 90 percent on trust, and I thank them for this.

最后，我决定尝试一下。 上次的工作经历进展顺利，我认为创建该工具并不是没有可能。 因此，我立即通知我的合作伙伴，我想在接下来的两三个月内建立一个MVP。 当我向他们解释时，很难让他们理解问题，因为他们不是我所从事的技术人员。 他们给了我90％的信任度，我对此表示感谢。

Over the course of three months I was able to create this prototype:

在三个月的过程中，我能够创建此原型：

While working on the implementation, I gradually understood the problems of realizing this kind of tool and even problems users would encounter during its use. From a technical point of view, a monitoring product has to be designed to work with huge quantities of data and I also wanted to deal with these data in real-time.

在实施过程中，我逐渐了解了实现这种工具的问题，甚至用户在使用过程中会遇到的问题。 从技术角度来看，监控产品必须设计为可处理大量数据，我还想实时处理这些数据。

I had to spend longer than I predicted for the backend part — in other words, the part which cannot be seen, or the backstage of an in-cloud software — leaving out the graphic interface (as you can see above), which is the part users see and use.

对于后端部分(换句话说，看不见的部分，或者在云中软件的后台)，我不得不花费比预期更长的时间，而忽略了图形界面(如您在上面看到的)，这是部分用户查看和使用。

扔掉一切然后重新开始 (Throwing everything away and starting again)

In the last few years, the dream of launching a product on the market pushed me to constantly study and apply marketing strategies that are particularly adept for SaaS software, to different projects (even the failed ones). I started to write articles for my blog with the aim of publishing them on different websites and social media to collect the first feedback.

在过去的几年中，在市场上推出产品的梦想促使我不断研究并将适用于SaaS软件的营销策略应用于不同的项目(甚至失败的项目)。 我开始为自己的博客写文章，旨在将其发布在不同的网站和社交媒体上，以收集第一批反馈。

Although I wrote horrible content in English with writing mistakes because English is not my mother tongue, I started to receive feedback on my idea which included:

尽管由于英语不是我的母语，所以我用英语写了可怕的内容，但写错了，但我开始收到有关我的想法的反馈，包括：

• I don’t understand what I can do with it.我不明白该怎么办。
• How can I install it?如何安装？
• Why use it rather than XXX?为什么使用它而不是XXX？
• And so on…等等…

It was not easy to be objective while looking at developers’ responses and comments. The emotional reaction could always take over and it was really hard for me to understand where the mistakes were because I am not a sales agent or a seller, but I am a damn good technician.

在查看开发人员的反馈和意见时，要做到客观是不容易的。 情感上 React总是可以接手，对于我来说，真的很难理解错误的出处，因为我不是销售代理人也不是卖方，但我是该死的优秀技术人员。

这是我沿途学到的教训 (Here are the lessons I learned along the way)

第1课-卖烂 (Lesson 1 — Selling sucks)

Thanks to my technical skills on the matter, I did not need to sell. Rather, I just needed to learn how to communicate the problems I faced every day and how I fixed them with my tools.

由于我在这件事上的技术能力，我不需要出售。 相反，我只需要学习如何交流每天遇到的问题以及如何使用工具解决它们。

I spent an entire month writing the most important things I knew about the monitoring and application scalability problems and the reasons why I decided to start this project, the difficulties I had been encountering during the development of a product, how I fixed them and moved forward,code examples, technical guides, my best practices, and more.

我花了整整一个月的时间来撰写关于监控和应用程序可伸缩性问题的最重要的知识，以及决定启动该项目的原因，产品开发过程中遇到的困难，如何解决这些问题以及如何向前发展，代码示例，技术指南，我的最佳做法等。

Then I gave everything to Robin, a Canadian copywriter found on Fiverr, who corrected all the content, including the website text, and polished the writing into native-level English.

然后，我将一切都交给了在Fiverr上找到的加拿大文案撰稿人Robin ，他更正了所有内容，包括网站文字，并将文字写成母语。

第2课-产品不足 (Lesson 2 — Insufficient product)

The fear of leaving out the user interface turned out to be a well-founded fear. What I did was not enough to create the kind of experience I had in my head, so I had to start again. The advantage of this was that I fixed the majority of the technical problems. It is not easy for an engineer to put themselves in a designer’s shoes.

担心会遗漏用户界面是一种有充分根据的恐惧。 我所做的不足以创造出我脑海中的那种体验，因此我不得不重新开始。 这样做的好处是我解决了大多数技术问题。 工程师要穿上设计师的鞋并不容易。

To improve my design sense I attended two courses about the development of graphic interfaces, read three books on design and user experience, and made direct experiments using VueJs as frontend framework.

为了提高我的设计意识，我参加了两门有关图形界面开发的课程，阅读了三本有关设计和用户体验的书，并使用VueJs作为前端框架进行了直接实验。

第3课-尽管有任何疑问，请尝试一下 (Lesson 3 — Give it a try despite all doubts)

When we spend our time reading books and watching videos on marketing and business, we always learn common advice which, in practical situations, usually does not work. Consider, for example, the mantra: “If you wait until everything is ready, you will never start your business”. So true!

当我们花时间阅读有关营销和业务的书籍和视频时，我们总是会学习一些常见的建议，而这些建议在实际情况下通常是行不通的。 例如，考虑一句口头禅：“如果等到一切准备就绪，就永远不会开业。” 如此真实 ！

But first experiences push us to emotional reactions that can put us on the defensive. This is a very big mistake because creating a product that is worthy of being bought thanks to its utility is a process, not a single event. The word “launch” misleads us, so forget about it and concentrate on “creation,” the process which, step by step, helps you understand what you need to change and improve to achieve your aim, compared with the outside world.

但是，最初的经历使我们产生了情绪上的React，可以使我们处于防御状态。 这是一个非常大的错误，因为创建一种由于其实用性值得购买的产品是一个过程，而不是单个事件。 “启动”一词会误导我们，因此请别理它，而将注意力集中在“创造”上，与外界相比，该过程逐步帮助您了解为实现目标而需要进行更改和改进的内容。

检查员出生了！ (Inspector is born!)

It took me another two months of working on the project; during these months I decided to recreate the brand from scratch, trying to use the prototype experience not just in terms of product but also in terms of marketing and communication.

我又花了两个月的时间来从事该项目。 在这几个月中，我决定从头开始重新创建品牌，不仅尝试在产品方面，而且在营销和传播方面都使用原型体验。

Inspector — Identify issues in your code before users are aware of them, in less than one minute!

检查器 -在不到一分钟的时间内，让用户意识到代码中的问题，然后让他们意识到！

We endlessly repeated ourselves that the aim was not the monitoring itself, but to help developers automate their working processes:

我们无休止地重复自己，其目的不是监视本身，而是帮助开发人员使他们的工作流程自动化：

• Without any effort

  不费吹灰之力

• Without wasting time with manual procedures

  无需浪费时间进行手动操作

• Guaranteeing flexibility when it is necessary

  必要时保证灵活性

获得第一个订阅 (Getting the first subscription)

On July 14, 2019, one of my technical guides was approved to be published on Laravel News, one of the most important websites for the Laravel developers’ community, which got the word out about this tool to an extended audience. Within four days, more than 2,000 people visited the Inspector website, almost 100 companies signed up, and the two first users — from Holland and Switzerland — subscribed.

在2019年7月14日，我的技术指南之一被批准发布在Laravel News上，Laravel News是Laravel开发人员社区最重要的网站之一，它使更多的人知道这个工具。 在四天内，有2,000多人访问了Inspector网站，近100家公司签约，并且来自荷兰和瑞士的两个第一用户订阅了该软件。

I cannot describe the emotion I felt when I received my first notice from Stripe which informed me that I had just received my first payment. When it happened, it was late in the evening. It felt like I was carrying an elephant on my shoulders for seven months and, finally, it went away and let mebreathe.

当我收到Stripe的第一笔通知时，我无法描述自己的情绪，该通知告诉我我刚收到我的第一笔付款。 当它发生的时候，已经是深夜了。 感觉就像是我背着大象扛了七个月，最后，它消失了，让我呼吸。

A lot of problems cropped up during the following months, and they required time, effort, and money to be fixed. This included things like hacking attacks and overloaded infrastructures, problems that forced me to stay chained to the PC even on Christmas Eve. These are problems that send you crashing back to earth and make you realize things are even more difficult than before because you have something to lose now.

在接下来的几个月中出现了很多问题，这些问题需要时间，精力和金钱来解决。 其中包括黑客攻击和基础架构过载等问题，这些问题迫使我即使在圣诞节前夕也仍然束缚在PC上。 这些问题使您重蹈覆辙，并使您意识到事情比以前更加困难，因为您现在要失去一些东西。

With the first subscribers, I knew I had an interesting product and, thanks to the web and the cloud, I had the chance to make the product known to developers from all over the world. So I kept working hard, full-time, every day for months to create and publish technical articles from myexperience on as many channels as possible:

有了第一个订阅者，我知道我有一个有趣的产品，而且由于有了网络和云，我才有机会向全世界的开发人员宣传该产品。 因此，我几个月来每天都在全职工作，以尽可能多的渠道根据我的经验创建和发布技术文章：

• https://medium.com/inspector

  https://medium.com/inspector

• https://dev.to/inspector

  https://dev.to/inspector

• https://valerio.hashnode.dev/

  https://valerio.hashnode.dev/

• https://www.facebook.com/inspector.realtime

  https://www.facebook.com/inspector.realtime

• https://www.linkedin.com/company/14054676

  https://www.linkedin.com/company/14054676

• https://twitter.com/Inspector_rt

  https://twitter.com/Inspector_rt

• https://www.indiehackers.com/product/inspector

  https://www.indiehackers.com/product/inspector

• https://www.reddit.com/r/InspectorFans/

  https://www.reddit.com/r/InspectorFans/

• https://www.producthunt.com/posts/inspector

  https://www.producthunt.com/posts/inspector

Now, more than 800 companies and business people have tried Inspector and we have more than 20 active subscriptions now from Singapore, Germany, NewYork, France, Hong Kong, Holland, and more.

现在，已有800多家公司和商人尝试了Inspector，并且我们现在有20多个活跃的订阅用户，它们来自新加坡，德国，纽约，法国，香港，荷兰等。

如何前进 (How to move forward)

Sharing and comparing with others has been fundamental in my journey to get here, so I plan to keep going this way. After all, I’m aware there are still a lot of things we need to improve and, even worse, problems that at the moment we’re ignoring entirely. This is why we started to tell this story during the most important Italian events where the topic is innovation.

与他人共享和比较一直是我到达这里的必经之路，因此我计划继续这样做。 毕竟，我知道我们还有很多事情需要改进，更糟糕的是，我们目前完全忽略了这些问题。 这就是为什么我们在最重要的以创新为主题的意大利活动中开始讲这个故事的原因。

Now we are part of the Hubble program, the Italian startup accelerator made by Paolo Barberis, Jacopo Marello, and Alessandro Sordi; three of Dada’s founders who spent 20 years of their lives collaborating to finance and support more than 30 Italian and foreign companies in growth.

现在，我们加入了Hubble计划，该计划是由Paolo Barberis，Jacopo Marello和Alessandro Sordi制造的意大利启动加速器； 达达(Dada)的三位创始人在过去的20年中共同为30多家意大利和外国公司的发展提供融资和支持。

Our aim is to introduce ourselves to other managers, business people, and marketing and technology experts in order to elevate the product to the next level and test new instruments and strategies to get Inspector known all over the world. We would like to help software developers to work in a more productive and fun way thanks to smart tools which give them more free time to spend on more valuable activities instead of boring, repetitive, manual checks.

我们的目的是向其他经理，商人以及市场和技术专家介绍自己，以将产品提升到一个新的水平，并测试新的工具和策略，以使Inspector在全球范围内广为人知。 借助智能工具，我们希望帮助软件开发人员以更有生产力和更有趣的方式工作，从而使他们有更多的空闲时间花在更有价值的活动上，而不必进行无聊的，重复的手动检查。

结论 (Conclusion)

In this article, I’ve shared the mental and practical process that led me to create and launch a SaaS product from scratch, and how I gained my first paying customers. Without sharing my journey I would never have created Inspector, so thank you for reading this article and I invite you to leave a comment below with any questions, curiosities, or just to tell me what you think about it. And if you think this article could be useful to others, please share it on your social media!

在本文中，我分享了引导我从头开始创建和发布SaaS产品的思想和实践过程，以及如何获得第一批付费客户。 如果没有分享我的旅程，我将永远不会创建Inspector ，因此，感谢您阅读本文，我邀请您在下面发表评论，以提出任何疑问，好奇心，或者只是告诉我您对此的看法。 如果您认为本文对其他人可能有用，请在您的社交媒体上分享！