2 articles tagged “startups” — software, engineering, and related writing by idmontie.

Startups blog posts - idmontie's Portfolio

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    h2: "h2",
    p: "p",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "In my projects list on this blog is a set of projects related to Clarity Hub. This was a startup I did with a group of friends where we aimed to create software to enable software product teams to gather customer feedback, and then action on it."
    }), "\n", _jsx(_components.p, {
      children: "I've been thinking about rebooting Clarity Hub for some time. When I was devoting my time to the Clarity Hub startup, the offering was split into two parts: 1. Interviewing software for product teams, and 2. an AI and NLP set of APIs for inference and predictions."
    }), "\n", _jsxs(_components.p, {
      children: ["We ended up open sourcing as much of our Clarity Hub code as we could: ", _jsx(_components.a, {
        href: "https://github.com/Clarityhub",
        children: "Clarity Hub on Github"
      }), ". This included all of our original code pivots as well. While interviewing with a few startups, a couple asked me for details on Clarity Hub and how we approached the problem domain, architectural decisions, and software design. All these notes ended up as part of the README: ", _jsx(_components.a, {
        href: "https://github.com/clarityhub/clarityhub-server-core",
        children: "Architecture notes on Github"
      }), "."]
    }), "\n", _jsx(_components.p, {
      children: "Looking at all these diagrams, seeing all the incredible work I did with my small team on Clarity Hub, I can see that a lot has changed since we tackled this problem."
    }), "\n", _jsx(_components.p, {
      children: "The first major change is that Notion has become a common name in note-taking. I consider myself an early adopter of Notion and have referred many friends over to it. Clarity Hub as a Notion for Product Teams seems very useless now, especially with the second change in consideration."
    }), "\n", _jsx(_components.p, {
      children: "The second major change being how far AI and NLP came within just a few years. Focusing on this as our differentiator is now irrelevant. Notion has released their API, new AI tools, and a plethora of other features. And while Notion doesn't provide an easy way to record, video call, automatically transcribe meetings, and pull topics from conversations, this seems pretty trivial to add as a Notion extension. I think Dovetail will be in the same boat. As OpenAI continues to provide more powerful models, and makes them easy to use, well-positioned apps like Notion will be able to continue to get better."
    }), "\n", _jsx(_components.p, {
      children: "But not is all lost, part of failing as a start-up is at least learning a lot."
    }), "\n", _jsx(_components.h2, {
      children: "Microservices, but not really"
    }), "\n", _jsx(_components.p, {
      children: "Looking back on our startup adventure, one thing I'd recommend for a new business just trying to start out is to think about microservices, but not fully committing to the complexity of microservices. We approached this by making the entire application in Serverless, using lambdas for each main endpoint that was needed as lambdas to handle asynchronous services. This let us share code, but move quickly."
    }), "\n", _jsx(_components.h2, {
      children: "Billing"
    }), "\n", _jsx(_components.p, {
      children: "Billing is one of those items that can easily become a time-sink – and it did. Looking back, I feel like we wasted so much time, effort, and thought on billing. If I had to do Clarity Hub over again, I'd ignore billing for just Free Trial and Contact Sales for custom billing."
    }), "\n", _jsx(_components.p, {
      children: "Without customers, there's no point in building a billing system, especially when you don't know what type of customers you will have."
    }), "\n", _jsx(_components.p, {
      children: "We definitely learned a lot about Stripe and how to build in eventing into our systems to help support billing cycles, upgrading, and more."
    }), "\n", _jsx(_components.p, {
      children: "We also spent very little time looking into alternative billing providers, since we were part of Stripe Atlas. One that has always interested me was Lago, since it is available as Open Source and a hosted solution."
    }), "\n", _jsx(_components.h2, {
      children: "Conflict-free replicated data types"
    }), "\n", _jsx(_components.p, {
      children: "We originally used Slate for our editor, and as is usual in programming, they went through a major version bump right after we finished our original implementation. I wish we had investigated Conflict-free replicated data types for this more and built-in real-time multi-user editing for notes early in the development stage."
    }), "\n", _jsx(_components.p, {
      children: "Implementing a basic solution for this would have been well worth it from a learning perspective, and from a code-reusability perspective. As is, a lot of the editor code is obsolete and tightly coupled with the specific version of slate that we used."
    }), "\n", _jsx(_components.h2, {
      children: "Conclusion"
    }), "\n", _jsx(_components.p, {
      children: "If I could do Clarity Hub all over again, I would. It was a great learning and growing experience for me, and I've often looked back on what we did and thought about rebooting Clarity Hub. But when I look around the current technology landscape, I think the scope of the product and its main differentiators would have to change dramatically."
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


In my projects list on this blog is a set of projects related to Clarity Hub. This was a startup I did with a group of friends where we aimed to create software to enable software product teams to gather customer feedback, and then action on it.
I&#x27;ve been thinking about rebooting Clarity Hub for some time. When I was devoting my time to the Clarity Hub startup, the offering was split into two parts: 1. Interviewing software for product teams, and 2. an AI and NLP set of APIs for inference and predictions.
We ended up open sourcing as much of our Clarity Hub code as we could: <a href="https://github.com/Clarityhub">Clarity Hub on Github</a>. This included all of our original code pivots as well. While interviewing with a few startups, a couple asked me for details on Clarity Hub and how we approached the problem domain, architectural decisions, and software design. All these notes ended up as part of the README: <a href="https://github.com/clarityhub/clarityhub-server-core">Architecture notes on Github</a>.
Looking at all these diagrams, seeing all the incredible work I did with my small team on Clarity Hub, I can see that a lot has changed since we tackled this problem.
The first major change is that Notion has become a common name in note-taking. I consider myself an early adopter of Notion and have referred many friends over to it. Clarity Hub as a Notion for Product Teams seems very useless now, especially with the second change in consideration.
The second major change being how far AI and NLP came within just a few years. Focusing on this as our differentiator is now irrelevant. Notion has released their API, new AI tools, and a plethora of other features. And while Notion doesn&#x27;t provide an easy way to record, video call, automatically transcribe meetings, and pull topics from conversations, this seems pretty trivial to add as a Notion extension. I think Dovetail will be in the same boat. As OpenAI continues to provide more powerful models, and makes them easy to use, well-positioned apps like Notion will be able to continue to get better.
But not is all lost, part of failing as a start-up is at least learning a lot.
<h2>Microservices, but not really</h2>
Looking back on our startup adventure, one thing I&#x27;d recommend for a new business just trying to start out is to think about microservices, but not fully committing to the complexity of microservices. We approached this by making the entire application in Serverless, using lambdas for each main endpoint that was needed as lambdas to handle asynchronous services. This let us share code, but move quickly.
<h2>Billing</h2>
Billing is one of those items that can easily become a time-sink – and it did. Looking back, I feel like we wasted so much time, effort, and thought on billing. If I had to do Clarity Hub over again, I&#x27;d ignore billing for just Free Trial and Contact Sales for custom billing.
Without customers, there&#x27;s no point in building a billing system, especially when you don&#x27;t know what type of customers you will have.
We definitely learned a lot about Stripe and how to build in eventing into our systems to help support billing cycles, upgrading, and more.
We also spent very little time looking into alternative billing providers, since we were part of Stripe Atlas. One that has always interested me was Lago, since it is available as Open Source and a hosted solution.
<h2>Conflict-free replicated data types</h2>
We originally used Slate for our editor, and as is usual in programming, they went through a major version bump right after we finished our original implementation. I wish we had investigated Conflict-free replicated data types for this more and built-in real-time multi-user editing for notes early in the development stage.
Implementing a basic solution for this would have been well worth it from a learning perspective, and from a code-reusability perspective. As is, a lot of the editor code is obsolete and tightly coupled with the specific version of slate that we used.
<h2>Conclusion</h2>
If I could do Clarity Hub all over again, I would. It was a great learning and growing experience for me, and I&#x27;ve often looked back on what we did and thought about rebooting Clarity Hub. But when I look around the current technology landscape, I think the scope of the product and its main differentiators would have to change dramatically.


In my projects list on this blog is a set of projects related to Clarity Hub. This was a startup I did with a group of friends where we aimed to create software to enable software product teams to gather customer feedback, and then action on it.

I've been thinking about rebooting Clarity Hub for some time. When I was devoting my time to the Clarity Hub startup, the offering was split into two parts: 1. Interviewing software for product teams, and 2. an AI and NLP set of APIs for inference and predictions.

We ended up open sourcing as much of our Clarity Hub code as we could: [Clarity Hub on Github](https://github.com/Clarityhub). This included all of our original code pivots as well. While interviewing with a few startups, a couple asked me for details on Clarity Hub and how we approached the problem domain, architectural decisions, and software design. All these notes ended up as part of the README: [Architecture notes on Github](https://github.com/clarityhub/clarityhub-server-core).

Looking at all these diagrams, seeing all the incredible work I did with my small team on Clarity Hub, I can see that a lot has changed since we tackled this problem.

The first major change is that Notion has become a common name in note-taking. I consider myself an early adopter of Notion and have referred many friends over to it. Clarity Hub as a Notion for Product Teams seems very useless now, especially with the second change in consideration.

The second major change being how far AI and NLP came within just a few years. Focusing on this as our differentiator is now irrelevant. Notion has released their API, new AI tools, and a plethora of other features. And while Notion doesn't provide an easy way to record, video call, automatically transcribe meetings, and pull topics from conversations, this seems pretty trivial to add as a Notion extension. I think Dovetail will be in the same boat. As OpenAI continues to provide more powerful models, and makes them easy to use, well-positioned apps like Notion will be able to continue to get better.

But not is all lost, part of failing as a start-up is at least learning a lot.

## Microservices, but not really

Looking back on our startup adventure, one thing I'd recommend for a new business just trying to start out is to think about microservices, but not fully committing to the complexity of microservices. We approached this by making the entire application in Serverless, using lambdas for each main endpoint that was needed as lambdas to handle asynchronous services. This let us share code, but move quickly.

## Billing

Billing is one of those items that can easily become a time-sink – and it did. Looking back, I feel like we wasted so much time, effort, and thought on billing. If I had to do Clarity Hub over again, I'd ignore billing for just Free Trial and Contact Sales for custom billing.

Without customers, there's no point in building a billing system, especially when you don't know what type of customers you will have.

We definitely learned a lot about Stripe and how to build in eventing into our systems to help support billing cycles, upgrading, and more.

We also spent very little time looking into alternative billing providers, since we were part of Stripe Atlas. One that has always interested me was Lago, since it is available as Open Source and a hosted solution.

## Conflict-free replicated data types

We originally used Slate for our editor, and as is usual in programming, they went through a major version bump right after we finished our original implementation. I wish we had investigated Conflict-free replicated data types for this more and built-in real-time multi-user editing for notes early in the development stage.

Implementing a basic solution for this would have been well worth it from a learning perspective, and from a code-reusability perspective. As is, a lot of the editor code is obsolete and tightly coupled with the specific version of slate that we used.

## Conclusion

If I could do Clarity Hub all over again, I would. It was a great learning and growing experience for me, and I've often looked back on what we did and thought about rebooting Clarity Hub. But when I look around the current technology landscape, I think the scope of the product and its main differentiators would have to change dramatically.


Looking back on Clarity Hub

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    blockquote: "blockquote",
    li: "li",
    p: "p",
    ul: "ul",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "We've all felt it at some point in our careers: that dreaded feeling of impostor syndrome kicking in as we find ourselves in over our heads. Questions like, \"Am I truly qualified for this?\" and \"Are my peers facing the same challenges?\" often plague our minds."
    }), "\n", _jsx(_components.p, {
      children: "Impostor syndrome is such a universal experience that countless articles, conference talks, and books have been dedicated to the topic."
    }), "\n", _jsx(_components.p, {
      children: "But is this just a human emotion? I think impostor syndrome also applies to startups and companies as well. While a lot less universal, some of us in the tech world have had the misfortune of working at such impostor syndrome companies. And that anxiety manifests itself into doubt in the employees, bringing everyone down."
    }), "\n", _jsxs(_components.blockquote, {
      children: ["\n", _jsx(_components.p, {
        children: "For example, many startups use Jira because large companies use Jira."
      }), "\n", _jsxs(_components.ul, {
        children: ["\n", _jsx(_components.li, {
          children: _jsx(_components.a, {
            href: "https://blog.johnqian.com/startup-spark",
            children: "https://blog.johnqian.com/startup-spark"
          })
        }), "\n"]
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "Whether or not you like JIRA, the startup impostor syndrome manifests itself in similar ways: pick safe tech that larger companies use. It must be good because the larger company we think is successful uses it. Emulate success and surely we will be successful."
    }), "\n", _jsx(_components.p, {
      children: "Or it may show up in processes. A manager comes into a startup from a large successful company and blindly imposes large corporate processes to the small company. Everything slows down, dampening the enthusiasm of the team. Emulate the processes of a large company and surely we will be successful."
    }), "\n", _jsxs(_components.p, {
      children: ["This mindset isn't new. The old adage \"", _jsx(_components.a, {
        href: "https://www.origina.com/blog/nobody-ever-got-fired-for-buying-ibm",
        children: "No one has ever been fired for buying IBM"
      }), "\" highlights the tendency to play it safe in the face of doubt. When we have doubt, even as a company, we like to play it safe; but, innovation and large payoffs don't happen from playing it safe. They come from risk and opportunity."]
    }), "\n", _jsx(_components.p, {
      children: "When we play it too safe, too cautiously, we are giving into that impostor syndrome and settling for good enough. In our personal lives and in business, emulating success is usually just a facade for fear of risk. It's difficult to go out there and create new processes when you are so used to an old process you learned at a larger company. It's difficult to go out there and pick a technology that no one is using compared to one that a large company is using. And it's difficult to go out there and solve problems you think are over your head."
    }), "\n", _jsx(_components.p, {
      children: "That feeling of impostor syndrome is good. It means you are pushing your limits and getting out of your comfort zone. You are tackling problems you haven't experienced before. And if you don't just try to emulate others, you might make mistakes, but they are your learning opportunities for growth. Then you can look back and see how far you've come, not by playing it safe and fearing impostor syndrome, but by embracing it."
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


We&#x27;ve all felt it at some point in our careers: that dreaded feeling of impostor syndrome kicking in as we find ourselves in over our heads. Questions like, &quot;Am I truly qualified for this?&quot; and &quot;Are my peers facing the same challenges?&quot; often plague our minds.
Impostor syndrome is such a universal experience that countless articles, conference talks, and books have been dedicated to the topic.
But is this just a human emotion? I think impostor syndrome also applies to startups and companies as well. While a lot less universal, some of us in the tech world have had the misfortune of working at such impostor syndrome companies. And that anxiety manifests itself into doubt in the employees, bringing everyone down.
<blockquote class="border-l-4 border-gray-300 pl-4">
For example, many startups use Jira because large companies use Jira.
<ul>
<li><a href="https://blog.johnqian.com/startup-spark">https://blog.johnqian.com/startup-spark</a></li>
</ul>
</blockquote>
Whether or not you like JIRA, the startup impostor syndrome manifests itself in similar ways: pick safe tech that larger companies use. It must be good because the larger company we think is successful uses it. Emulate success and surely we will be successful.
Or it may show up in processes. A manager comes into a startup from a large successful company and blindly imposes large corporate processes to the small company. Everything slows down, dampening the enthusiasm of the team. Emulate the processes of a large company and surely we will be successful.
This mindset isn&#x27;t new. The old adage &quot;<a href="https://www.origina.com/blog/nobody-ever-got-fired-for-buying-ibm">No one has ever been fired for buying IBM</a>&quot; highlights the tendency to play it safe in the face of doubt. When we have doubt, even as a company, we like to play it safe; but, innovation and large payoffs don&#x27;t happen from playing it safe. They come from risk and opportunity.
When we play it too safe, too cautiously, we are giving into that impostor syndrome and settling for good enough. In our personal lives and in business, emulating success is usually just a facade for fear of risk. It&#x27;s difficult to go out there and create new processes when you are so used to an old process you learned at a larger company. It&#x27;s difficult to go out there and pick a technology that no one is using compared to one that a large company is using. And it&#x27;s difficult to go out there and solve problems you think are over your head.
That feeling of impostor syndrome is good. It means you are pushing your limits and getting out of your comfort zone. You are tackling problems you haven&#x27;t experienced before. And if you don&#x27;t just try to emulate others, you might make mistakes, but they are your learning opportunities for growth. Then you can look back and see how far you&#x27;ve come, not by playing it safe and fearing impostor syndrome, but by embracing it.


We've all felt it at some point in our careers: that dreaded feeling of impostor syndrome kicking in as we find ourselves in over our heads. Questions like, "Am I truly qualified for this?" and "Are my peers facing the same challenges?" often plague our minds.

Impostor syndrome is such a universal experience that countless articles, conference talks, and books have been dedicated to the topic.

But is this just a human emotion? I think impostor syndrome also applies to startups and companies as well. While a lot less universal, some of us in the tech world have had the misfortune of working at such impostor syndrome companies. And that anxiety manifests itself into doubt in the employees, bringing everyone down.

> For example, many startups use Jira because large companies use Jira.
>
> - https://blog.johnqian.com/startup-spark

Whether or not you like JIRA, the startup impostor syndrome manifests itself in similar ways: pick safe tech that larger companies use. It must be good because the larger company we think is successful uses it. Emulate success and surely we will be successful.

Or it may show up in processes. A manager comes into a startup from a large successful company and blindly imposes large corporate processes to the small company. Everything slows down, dampening the enthusiasm of the team. Emulate the processes of a large company and surely we will be successful.

This mindset isn't new. The old adage "[No one has ever been fired for buying IBM](https://www.origina.com/blog/nobody-ever-got-fired-for-buying-ibm)" highlights the tendency to play it safe in the face of doubt. When we have doubt, even as a company, we like to play it safe; but, innovation and large payoffs don't happen from playing it safe. They come from risk and opportunity.

When we play it too safe, too cautiously, we are giving into that impostor syndrome and settling for good enough. In our personal lives and in business, emulating success is usually just a facade for fear of risk. It's difficult to go out there and create new processes when you are so used to an old process you learned at a larger company. It's difficult to go out there and pick a technology that no one is using compared to one that a large company is using. And it's difficult to go out there and solve problems you think are over your head.

That feeling of impostor syndrome is good. It means you are pushing your limits and getting out of your comfort zone. You are tackling problems you haven't experienced before. And if you don't just try to emulate others, you might make mistakes, but they are your learning opportunities for growth. Then you can look back and see how far you've come, not by playing it safe and fearing impostor syndrome, but by embracing it.


startups posts

Looking back on Clarity Hub

In Good Company, Impostor Syndrome